On Tue, Sep 20, 2011 at 03:08:18PM -0500, Bollinger, John C wrote:
> Hello All,
Hi,
>
> I am attempting to build PDFedit v 0.4.5 on CentOS 5, using the
> distro's provided GCC 4.1.2 toolchain. I am encountering a cluster
> of related compilation errors that appear the same as, or at least
> closely related to, the one discussed in this previous thread:
>
> http://sourceforge.net/mailarchive/forum.php?thread_name=20100521074048.GG4000%40tiehlicka.suse.cz&forum_name=pdfedit-support
>
> I encounter exactly the same compiler error that the OP in that thread reported, plus a few more:
>
> g++ -c -g -O2 -fmessage-length=0 -D_FORTIFY_SOURCE=2 -fno-strict-aliasing -fexceptions -fstack-protector -pipe -posix -ansi -std=c++98 -pedantic -I. -I/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src -I/home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/xpdf/ -I/usr/include -I/usr/include/freetype2 -I/usr/include -o cpagecontents.o cpagecontents.cc
> cpagecontents.cc: In member function 'void pdfobjects::CPageContents::addInlineImage(const std::vector<char, std::allocator<char> >&, const libs::Point&, const libs::Point&)':
> cpagecontents.cc:543: warning: passing 'const double' for argument 1 to 'pdfobjects::CObjectSimple<Tp>::CObjectSimple(const typename pdfobjects::PropertyTraitSimple<Tp>::value&) [with pdfobjects::PropertyType Tp = pInt]'
> /usr/include/boost/noncopyable.hpp: In copy constructor 'pdfobjects::CObjectSimple<pInt>::CObjectSimple(const pdfobjects::CObjectSimple<pInt>&)':
> /usr/include/boost/noncopyable.hpp:27: error: 'boost::noncopyable_::noncopyable::noncopyable(const boost::noncopyable_::noncopyable&)' is private
> /home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/kernel/cobjectsimple.h:104: error: within this context
> cpagecontents.cc: In member function 'void pdfobjects::CPageContents::addInlineImage(const std::vector<char, std::allocator<char> >&, const libs::Point&, const libs::Point&)':
> cpagecontents.cc:543: note: synthesized method 'pdfobjects::CObjectSimple<pInt>::CObjectSimple(const pdfobjects::CObjectSimple<pInt>&)' first required here
> cpagecontents.cc:544: warning: passing 'const double' for argument 1 to 'pdfobjects::CObjectSimple<Tp>::CObjectSimple(const typename pdfobjects::PropertyTraitSimple<Tp>::value&) [with pdfobjects::PropertyType Tp = pInt]'
> /usr/include/boost/noncopyable.hpp: In copy constructor 'pdfobjects::CObjectSimple<pName>::CObjectSimple(const pdfobjects::CObjectSimple<pName>&)':
> /usr/include/boost/noncopyable.hpp:27: error: 'boost::noncopyable_::noncopyable::noncopyable(const boost::noncopyable_::noncopyable&)' is private
> /home/jbolling/rpm/BUILD/pdfedit-0.4.5/src/kernel/cobjectsimple.h:104: error: within this context
> cpagecontents.cc: In member function 'void pdfobjects::CPageContents::addInlineImage(const std::vector<char, std::allocator<char> >&, const libs::Point&, const libs::Point&)':
> cpagecontents.cc:545: note: synthesized method 'pdfobjects::CObjectSimple<pName>::CObjectSimple(const pdfobjects::CObjectSimple<pName>&)' first required here
>
>
> I will address the warnings in a separate message. Right now, observe
> that g++ complains not just about line 545, where attention focused
> during the previous discussion, but also about line 544. In fact, in
> my experiments I found that the compiler will make the same complaint
> about an inaccessible copy constructor for each of these lines:
>
> image_dict.addProperty ("W", CInt (image_size.x));
> image_dict.addProperty ("H", CInt (image_size.y));
> image_dict.addProperty ("CS", CName ("RGB"));
> image_dict.addProperty ("BPC", CInt (8));
Yes the problem is already fixed in CVS. The issue is that this
particular gcc version doesn't like r-value (constructor) for a const
reference parameter without a copy constructor. There is no reason to
use the copy constructor here because the object is for the single use
without any external aliases.
Strictly speaking C++ standard enables such a behavior so we have
addressed the issue simply by creating a temporal object.
CInt W (image_size.x);
image_dict.addProperty ("W", W);
>
> It appears, then, that g++ decides it must make copies of the CInt and
> CName arguments, even though the method prototype specifies that the
> arguments are references. Perhaps g++ wants to copy the arguments
> and then pass references to the copies.
Exactly.
> That could be a GCC bug,
Not a bug as I said above. C++ standard enables that. I would rather
call it suboptimality.
> but it draws attention to a PDFEdit bug here: the program is
> attempting to store references to local CInt and CName objects in a
> CDict whose lifetime exceeds theirs.
No. Arguments are deep copied (we are using clone method). Have a look
at CDict::addProperty method.
>
> That is, to the best of my understanding, the lifetime of local
> objects instantiated in an argument list is limited to the function
> call to which they are arguments (i.e. each addProperty() call),
> whereas image_dict lives until the end of the method.
>
> Even if that were not so, it appears that the method also leaks
> references to these local CInt and CName objects when it subsequently
> uses the constructed image_dict to initialize a CInlineImage allocated
> on the heap (thus using longer-lived local objects would not solve the
> problem).
>
> In any event, the compiler is satisfied if I change the above four lines like so:
>
> image_dict.addProperty ("W", *(new CInt (image_size.x)));
> image_dict.addProperty ("H", *(new CInt (image_size.y)));
> image_dict.addProperty ("CS", *(new CName ("RGB")));
> image_dict.addProperty ("BPC", *(new CInt (8)));
>
> That obviously leaks memory, but it's better than the program
> accessing who-knows-what through dangling references. It also
> demonstrates to my satisfaction that the problem is not with the
> compiler being confused about types, but rather with its approach to
> handling the type locality issue, possibly in conjunction with some
> optimization it attempts to apply.
>
> To sum up, there appears to be a cluster of PDFedit bugs here, even
> when the original code compiles successfully. I don't see any simple
> fix that would be adequate, but perhaps those of you who are more
> familiar with
Does the deep copying answers your concern?
> Best,
>
> John Bollinger
>
>
> Email Disclaimer: http://www.stjude.org/emaildisclaimer
--
Michal Hocko
|