xpdf, new gcc?
This is on a multilib build, using the second gcc-4.1.2 release
candidate. I don't think the multilib part is relevant, so I'll
take the risk of asking here. Xpdf (3.01pl2) is failing to compile
with (lines wrapped)
g++ -m32 -O2 -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi
-I./../splash -I. -I/usr/include/freetype2 -DHAVE_XPDFCORE
-c -o SecurityHandler.x.o \
SecurityHandler.cc
/usr/include/X11/VendorP.h:87: error: previous declaration of
‘VendorShellClassRec vendorShellClassRec’ with ‘C++’ linkage
/usr/include/Xm/VendorSP.h:58: error: conflicts with new declaration
with ‘C’ linkage
make[1]: *** [SecurityHandler.x.o] Error 1
make[1]: Leaving directory `/usr/src/xpdf-3.01/xpdf'
make: *** [all] Error 2
As far as I can see, the header hasn't changed since I last built
xpdf:
typedef struct _VendorShellClassRec {
CoreClassPart core_class;
CompositeClassPart composite_class;
ShellClassPart shell_class;
WMShellClassPart wm_shell_class;
VendorShellClassPart vendor_shell_class;
} VendorShellClassRec;
externalref VendorShellClassRec vendorShellClassRec;
line 87 is the 'externalref'.
Any suggestions, please, or should I just drop xpdf (I was thinking
about doing that anyway) ?
ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: xpdf, new gcc?
On 2/15/07, Ken Moffat [EMAIL PROTECTED] wrote:
This is on a multilib build, using the second gcc-4.1.2 release
candidate. I don't think the multilib part is relevant, so I'll
take the risk of asking here. Xpdf (3.01pl2) is failing to compile
with (lines wrapped)
g++ -m32 -O2 -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi
-I./../splash -I. -I/usr/include/freetype2 -DHAVE_XPDFCORE
-c -o SecurityHandler.x.o \
SecurityHandler.cc
/usr/include/X11/VendorP.h:87: error: previous declaration of
'VendorShellClassRec vendorShellClassRec' with 'C++' linkage
/usr/include/Xm/VendorSP.h:58: error: conflicts with new declaration
with 'C' linkage
make[1]: *** [SecurityHandler.x.o] Error 1
make[1]: Leaving directory `/usr/src/xpdf-3.01/xpdf'
make: *** [all] Error 2
As far as I can see, the header hasn't changed since I last built
xpdf:
typedef struct _VendorShellClassRec {
CoreClassPart core_class;
CompositeClassPart composite_class;
ShellClassPart shell_class;
WMShellClassPart wm_shell_class;
VendorShellClassPart vendor_shell_class;
} VendorShellClassRec;
externalref VendorShellClassRec vendorShellClassRec;
line 87 is the 'externalref'.
Any suggestions, please?
If VendorShellClassRec is defined twice, what happens if the local one
is commented out? The easiest way I can see if to comment out line 87
and see if that fixes things.
Note: I may not be understanding the whole thing here. I'm jsut
throwing out ideas.
-- Bruce
-- Bruce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: xpdf, new gcc?
On 2/15/07, Ken Moffat [EMAIL PROTECTED] wrote:
This is on a multilib build, using the second gcc-4.1.2 release
candidate. I don't think the multilib part is relevant, so I'll
take the risk of asking here. Xpdf (3.01pl2) is failing to compile
with (lines wrapped)
g++ -m32 -O2 -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi
-I./../splash -I. -I/usr/include/freetype2 -DHAVE_XPDFCORE
-c -o SecurityHandler.x.o \
SecurityHandler.cc
/usr/include/X11/VendorP.h:87: error: previous declaration of
'VendorShellClassRec vendorShellClassRec' with 'C++' linkage
/usr/include/Xm/VendorSP.h:58: error: conflicts with new declaration
with 'C' linkage
make[1]: *** [SecurityHandler.x.o] Error 1
make[1]: Leaving directory `/usr/src/xpdf-3.01/xpdf'
make: *** [all] Error 2
As far as I can see, the header hasn't changed since I last built
xpdf:
typedef struct _VendorShellClassRec {
CoreClassPart core_class;
CompositeClassPart composite_class;
ShellClassPart shell_class;
WMShellClassPart wm_shell_class;
VendorShellClassPart vendor_shell_class;
} VendorShellClassRec;
externalref VendorShellClassRec vendorShellClassRec;
line 87 is the 'externalref'.
I think the issue is with the header from lesstif, Xm/VendorSP.h, not
playing nice with the one from libXt, X11/VendorP.h when compiled in
C++ mode. Now I found a patch on arch for lesstif (it's for 0.95.0,
but maybe it'll work).
http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/lib/lesstif/c%2B%2Bfix.patch?rev=1.1cvsroot=Currentonly_with_tag=CURRENTcontent-type=text/vnd.viewcvs-markup
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: xpdf, new gcc?
On 2/15/07, Ken Moffat [EMAIL PROTECTED] wrote: Any suggestions, please, or should I just drop xpdf (I was thinking about doing that anyway) ? Do it! Poppler + evince/kpdf/okular should be a much more pleasant experience, IMO. I'm always shocked when I see Motif on a modern desktop. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: xpdf, new gcc?
On Thu, Feb 15, at 06:56 Ken Moffat wrote: Any suggestions, please, or should I just drop xpdf (I was thinking about doing that anyway) ? ĸen Hi Ken, It's probably a freetype issue,if I remember correctly the error (I dropped xpdf for poppler and epdfview since November). I have submitted a patch about the issue in mid October (check the patches mailing list). -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: xpdf, new gcc?
On Thu, Feb 15, 2007 at 01:17:16PM -0600, Bruce Dubbs wrote:
As far as I can see, the header hasn't changed since I last built
xpdf:
typedef struct _VendorShellClassRec {
CoreClassPart core_class;
CompositeClassPart composite_class;
ShellClassPart shell_class;
WMShellClassPart wm_shell_class;
VendorShellClassPart vendor_shell_class;
} VendorShellClassRec;
externalref VendorShellClassRec vendorShellClassRec;
line 87 is the 'externalref'.
Any suggestions, please?
If VendorShellClassRec is defined twice, what happens if the local one
is commented out? The easiest way I can see if to comment out line 87
and see if that fixes things.
I didn't make clear that this header comes from libXt. I'm
reluctant to go changing X's own headers when everything else seems
to be working, but I'll bear this in mind. Thanks for the
suggestion. I've already built non-multilib with the same packages
and gcc-4.1.1, which was why I assumed gcc was the probable cause.
ĸen
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: xpdf, new gcc?
On 2/15/07, Dan Nicholson [EMAIL PROTECTED] wrote: http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/lib/lesstif/c%2B%2Bfix.patch?rev=1.1cvsroot=Currentonly_with_tag=CURRENTcontent-type=text/vnd.viewcvs-markup Did you try this patch to lesstif? -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: xpdf, new gcc?
On Thu, Feb 15, 2007 at 11:22:16AM -0800, Dan Nicholson wrote: On 2/15/07, Ken Moffat [EMAIL PROTECTED] wrote: Any suggestions, please, or should I just drop xpdf (I was thinking about doing that anyway) ? Do it! Poppler + evince/kpdf/okular should be a much more pleasant experience, IMO. I'm always shocked when I see Motif on a modern desktop. Modern, moi ? I'll have you know I still use the default X background pattern that Keith Packard hates so much. But yes, lesstif is a bit of a shock to the eyes. I've added okular to the list of things to try, evince was already there (can't make up my mind between kpdf and kghostview at the moment). Thanks. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: xpdf, new gcc?
On Thu, Feb 15, 2007 at 02:04:58PM -0800, Dan Nicholson wrote: On 2/15/07, Dan Nicholson [EMAIL PROTECTED] wrote: http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/lib/lesstif/c%2B%2Bfix.patch?rev=1.1cvsroot=Currentonly_with_tag=CURRENTcontent-type=text/vnd.viewcvs-markup Did you try this patch to lesstif? Will do as soon as I've un-html'd what I downloaded (I managed to get 'gt;' on the end of some of the lines) ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: xpdf, new gcc?
On 2/15/07, Ken Moffat [EMAIL PROTECTED] wrote: On Thu, Feb 15, 2007 at 02:04:58PM -0800, Dan Nicholson wrote: On 2/15/07, Dan Nicholson [EMAIL PROTECTED] wrote: http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/lib/lesstif/c%2B%2Bfix.patch?rev=1.1cvsroot=Currentonly_with_tag=CURRENTcontent-type=text/vnd.viewcvs-markup Did you try this patch to lesstif? Will do as soon as I've un-html'd what I downloaded (I managed to get 'gt;' on the end of some of the lines) Sorry. You can use the checkout version instead without the html markup. http://cvs.archlinux.org/cgi-bin/viewcvs.cgi/*checkout*/lib/lesstif/c%2B%2Bfix.patch?rev=HEADcvsroot=Currentonly_with_tag=CURRENTcontent-type=text/plain -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: xpdf, new gcc?
On Thu, Feb 15, 2007 at 10:16:42PM +, Ken Moffat wrote: Did you try this patch to lesstif? Will do as soon as I've un-html'd what I downloaded (I managed to get 'gt;' on the end of some of the lines) Seems to do the job (rebuilt lesstif, installed the updated header, xpdf now seems happy). Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: xpdf, new gcc?
On 2/15/07, Ken Moffat [EMAIL PROTECTED] wrote: Modern, moi ? I'll have you know I still use the default X background pattern that Keith Packard hates so much. I hate that ugly hatch pattern :) Fedora used to have a patch for the server called die-ugly-pattern-die-die.patch and changed the default background to black. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: xpdf, new gcc?
On Thu, Feb 15, at 10:01 Ken Moffat wrote: I've added epdfview to my list of things to investigate. Are you planing to build one of the 2 D.E monsters? In that case maybe it's better to use one of the native kde/gnome pdf frontends to poppler. I heard some good things about evince and I know that a lot of patches from the kpdf maintainer found their way into poppler. You see,there is nothing but basic functionality in epdfview (viewing and printing).Comparing with xpdf is slow and you can't even copy from the pdf document. However poppler development is open,active and promising and I really wanted to get rid of Motif. Not,that I am working with pdf documents that much,besides the ones I am getting from my bank,so epdfview is -almost- good enough for my needs at least for now.Let's hope the epdfview development continues because I hate to build the half universe of software just to have a decent pdf viewer in 2007. -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: xpdf, new gcc?
On Fri, 2007-02-16 at 08:09 +0200, Ag. Hatzimanikas wrote: In that case maybe it's better to use one of the native kde/gnome pdf frontends to poppler. I heard some good things about evince and I know that a lot of patches from the kpdf maintainer found their way into poppler. Yeah, the collaboration there is good - I believe the Evince and kpdf developers spend quite a lot of their time improving the base library. And while I've not used kpdf, I've found Evince to be supurb at dealing with PDF files, suggesting that both groups have done a good job. Simon. signature.asc Description: This is a digitally signed message part -- http://linuxfromscratch.org/mailman/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
