Hello All,
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));
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. That could be a GCC bug, 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.
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
Best,
John Bollinger
Email Disclaimer: www.stjude.org/emaildisclaimer
------------------------------------------------------------------------------
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
