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: www.stjude.org/emaildisclaimer -- Michal Hocko ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Pdfedit-support mailing list Pdfedit-support@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pdfedit-support
