xpdf linker errors

IRIX/Nekoware development, porting and related topics.
Forum rules
Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.
User avatar
hamei
Posts: 10433
Joined: Tue Feb 24, 2004 4:10 pm
Location: over the rainbow

xpdf linker errors

Unread postby hamei » Wed Oct 26, 2011 7:36 pm

Small linking problem here - Pymble was kind enough to direct me to the volume Loaders and Linkers but for the moment, maybe someone smarter can see if they notice anything obviously wrong ?

There is a new version of xpdf out. 3.02 compiled nicely with one correction. 3.03 also needs one correction in XPDFView.cc but afterwards makes object files no problem.

Then ...

Code: Select all

cd xpdf; gmake all

gmake[1]: Entering directory `/usr/people/dev/xpdf-3.03/xpdf'

CC -mips4 -O3 -c99 -I/usr/nekoware/include -I/usr/nekoware/include/freetype2/ -I/usr/include  -DHAVE_CONFIG_H -I.. -I./../goo -I./../fofi -I./../splash  -I.           -v -mips4 -L/usr/nekoware/lib -L/usr/lib32 -Wl,-rpath -Wl,/usr/nekoware/lib -o xpdf Annot.o Array.o BuiltinFont.o BuiltinFontTables.o Catalog.o CharCodeToUnicode.o CMap.o CoreOutputDev.o Decrypt.o Dict.o Error.o FontEncodingTables.o Function.o Gfx.o GfxFont.o GfxState.o GlobalParams.o JArithmeticDecoder.o JBIG2Stream.o JPXStream.o Lexer.o Link.o NameToCharCode.o Object.o OptionalContent.o Outline.o OutputDev.o Page.o Parser.o PDFCore.o PDFDoc.o PDFDocEncoding.o PreScanOutputDev.o PSOutputDev.o PSTokenizer.o SecurityHandler.o SplashOutputDev.o Stream.o TextOutputDev.o UnicodeMap.o UnicodeTypeTable.o XPDFApp.o XPDFCore.o XPDFTree.o XPDFViewer.o XpdfPluginAPI.o XRef.o xpdf.o -L../goo -lGoo -L../splash -lsplash  -L/usr/nekoware/lib/ -lfreetype -lSgm -lXm -lXt  -lXext -lXpm  -lSM -lICE  -lX11  -L../fofi -lfofi -L../goo -lGoo -lm

MIPSpro Compilers: Version 7.4.4m

/usr/lib32/cmplrs/edg_prelink -Yu -fSGI -L/usr/nekoware/lib -L/usr/lib32 -L../goo -L../splash -L/usr/nekoware/lib/ -L../fofi -L../goo -L/usr/lib32/mips4/r10000 -L/usr/lib32/mips4 -L/usr/lib32 Annot.o Array.o BuiltinFont.o BuiltinFontTables.o Catalog.o CharCodeToUnicode.o CMap.o CoreOutputDev.o Decrypt.o Dict.o Error.o FontEncodingTables.o Function.o Gfx.o GfxFont.o GfxState.o GlobalParams.o JArithmeticDecoder.o JBIG2Stream.o JPXStream.o Lexer.o Link.o NameToCharCode.o Object.o OptionalContent.o Outline.o OutputDev.o Page.o Parser.o PDFCore.o PDFDoc.o PDFDocEncoding.o PreScanOutputDev.o PSOutputDev.o PSTokenizer.o SecurityHandler.o SplashOutputDev.o Stream.o TextOutputDev.o UnicodeMap.o UnicodeTypeTable.o XPDFApp.o XPDFCore.o XPDFTree.o XPDFViewer.o XpdfPluginAPI.o XRef.o xpdf.o -lGoo -lsplash -lfreetype -lSgm -lXm -lXt -lXext -lXpm -lSM -lICE -lX11 -lfofi -lGoo -lm -lCsup -lC -lCio
/usr/lib32/cmplrs/ld32 -call_shared -init _main -fini _fini -no_unresolved -transitive_link -demangle -elf -_SYSTYPE_SVR4 -LANG:std -show -mips4 -L/usr/nekoware/lib -L/usr/lib32 -rpath /usr/nekoware/lib -L../goo -L../splash -L/usr/nekoware/lib/ -L../fofi -L../goo -n32 -L/usr/lib32/mips4/r10000 -L/usr/lib32/mips4 -L/usr/lib32 -cxx -woff 134 /usr/lib32/crt1.o /usr/lib32/c++init.o -o xpdf Annot.o Array.o BuiltinFont.o BuiltinFontTables.o Catalog.o CharCodeToUnicode.o CMap.o CoreOutputDev.o Decrypt.o Dict.o Error.o FontEncodingTables.o Function.o Gfx.o GfxFont.o GfxState.o GlobalParams.o JArithmeticDecoder.o JBIG2Stream.o JPXStream.o Lexer.o Link.o NameToCharCode.o Object.o OptionalContent.o Outline.o OutputDev.o Page.o Parser.o PDFCore.o PDFDoc.o PDFDocEncoding.o PreScanOutputDev.o PSOutputDev.o PSTokenizer.o SecurityHandler.o SplashOutputDev.o Stream.o TextOutputDev.o UnicodeMap.o UnicodeTypeTable.o XPDFApp.o XPDFCore.o XPDFTree.o XPDFViewer.o XpdfPluginAPI.o XRef.o xpdf.o -lGoo -lsplash -lfreetype -lSgm -lXm -lXt -lXext -lXpm -lSM -lICE -lX11 -lfofi -lGoo -lm -dont_warn_unused -lCsup -lC -lCio -Bdynamic -lc /usr/lib32/crtn.o -warn_unused

ld32: WARNING 84 : /usr/lib32/libXext.so is not used for resolving any symbol.

ld32: WARNING 84 : ../goo/libGoo.a is not used for resolving any symbol.

ld32: ERROR   33 : Unresolved text symbol "std::__introsort_loop(SplashXPathSeg*,SplashXPathSeg*,SplashXPathSeg*,int,cmpXPathSegsFunctor)" -- 1st referenced by ../splash/libsplash.a(SplashXPath.o).
        Use linker option -v to see when and which objects, archives and dsos are loaded. 

ld32: ERROR   33 : Unresolved text symbol "std::__final_insertion_sort(SplashXPathSeg*,SplashXPathSeg*,cmpXPathSegsFunctor)" -- 1st referenced by ../splash/libsplash.a(SplashXPath.o).
        Use linker option -v to see when and which objects, archives and dsos are loaded. 

ld32: ERROR   33 : Unresolved text symbol "std::__introsort_loop(SplashIntersect*,SplashIntersect*,SplashIntersect*,int,cmpIntersectFunctor)" -- 1st referenced by ../splash/libsplash.a(SplashXPathScanner.o).
        Use linker option -v to see when and which objects, archives and dsos are loaded. 

ld32: ERROR   33 : Unresolved text symbol "std::__final_insertion_sort(SplashIntersect*,SplashIntersect*,cmpIntersectFunctor)" -- 1st referenced by ../splash/libsplash.a(SplashXPathScanner.o).
        Use linker option -v to see when and which objects, archives and dsos are loaded. 

ld32: ERROR   33 : Unresolved text symbol "std::__introsort_loop(SplashScreenPoint*,SplashScreenPoint*,SplashScreenPoint*,int,cmpDistancesFunctor)" -- 1st referenced by ../splash/libsplash.a(SplashScreen.o).
        Use linker option -v to see when and which objects, archives and dsos are loaded. 

ld32: ERROR   33 : Unresolved text symbol "std::__final_insertion_sort(SplashScreenPoint*,SplashScreenPoint*,cmpDistancesFunctor)" -- 1st referenced by ../splash/libsplash.a(SplashScreen.o).
        Use linker option -v to see when and which objects, archives and dsos are loaded. 

ld32: ERROR   33 : Unresolved text symbol "std::__introsort_loop(TrueTypeLoca*,TrueTypeLoca*,TrueTypeLoca*,int,cmpTrueTypeLocaOffsetFunctor)" -- 1st referenced by ../fofi/libfofi.a(FoFiTrueType.o).
        Use linker option -v to see when and which objects, archives and dsos are loaded. 

ld32: ERROR   33 : Unresolved text symbol "std::__final_insertion_sort(TrueTypeLoca*,TrueTypeLoca*,cmpTrueTypeLocaOffsetFunctor)" -- 1st referenced by ../fofi/libfofi.a(FoFiTrueType.o).
        Use linker option -v to see when and which objects, archives and dsos are loaded. 

ld32: ERROR   33 : Unresolved text symbol "std::__introsort_loop(TrueTypeLoca*,TrueTypeLoca*,TrueTypeLoca*,int,cmpTrueTypeLocaIdxFunctor)" -- 1st referenced by ../fofi/libfofi.a(FoFiTrueType.o).
        Use linker option -v to see when and which objects, archives and dsos are loaded. 

ld32: ERROR   33 : Unresolved text symbol "std::__final_insertion_sort(TrueTypeLoca*,TrueTypeLoca*,cmpTrueTypeLocaIdxFunctor)" -- 1st referenced by ../fofi/libfofi.a(FoFiTrueType.o).
        Use linker option -v to see when and which objects, archives and dsos are loaded. 

ld32: ERROR   33 : Unresolved text symbol "std::__introsort_loop(TrueTypeTable*,TrueTypeTable*,TrueTypeTable*,int,cmpTrueTypeTableTagFunctor)" -- 1st referenced by ../fofi/libfofi.a(FoFiTrueType.o).
        Use linker option -v to see when and which objects, archives and dsos are loaded. 

ld32: ERROR   33 : Unresolved text symbol "std::__final_insertion_sort(TrueTypeTable*,TrueTypeTable*,cmpTrueTypeTableTagFunctor)" -- 1st referenced by ../fofi/libfofi.a(FoFiTrueType.o).
        Use linker option -v to see when and which objects, archives and dsos are loaded. 

ld32: INFO    152: Output file removed because of error.
CC ERROR:  /usr/lib32/cmplrs/ld32 returned non-zero status 2
gmake[1]: *** [xpdf] Error 2
gmake[1]: Leaving directory `/usr/people/dev/xpdf-3.03/xpdf'
gmake: *** [all] Error 2


(I added a few spaces to make it more readable ... )

User avatar
PymbleSoftware
Posts: 1891
Joined: Tue Jul 15, 2008 5:48 pm
Location: P.O. Box 529, Gordon, Sydney, NSW 2072, Australia.
Contact:

Re: linkages

Unread postby PymbleSoftware » Wed Oct 26, 2011 7:46 pm

I said that linker errors like that are usually from one of two things...

1. library order when passed to the linker. Mutually dependant libraries can link if one is specified twice.
2. libraries or maybe object files not specified for the linker to resolve against.

You have to track down where "std::__introsort_loop" should come from and add the library to the linker flags.


R.
死の神はりんごだけ食べる

開いた括弧は必ず閉じる -- あるプログラマー

:Tezro: :Tezro: :Onyx2R: :Onyx2RE: :Onyx2: :O3x04R: :O3x0: :O200: :Octane: :Octane2: :O2: :O2: :Indigo2IMP: :PI: :PI: :1600SW: :1600SW: :Indy: :Indy: :Indy: :Indy: :Indy:
:hpserv: J5600, 2 x Mac, 3 x SUN, Alpha DS20E, Alpha 800 5/550, 3 x RS/6000, Amiga 4000 VideoToaster, Amiga4000 -030, 733MHz Sam440 AmigaOS 4.1 update 1.

HP C7000 BladeSever with 16 Blades 96Gb to 144Gb RAM per blade
HP C3000 Blade Server with 8 Blades 48Gb to 144Gb RAM per blade

Sold: :Indy: :Indy: :Indy: :Indigo: Tandem Himalaya S-Series Nonstop S72000 ServerNet.

Twitter @PymbleSoftware
Current Apps (iOS) -> https://itunes.apple.com/au/artist/pymb ... d553990081
(Android) https://play.google.com/store/apps/deve ... +Ltd&hl=en
(Onyx2) Cortex ---> http://www.facebook.com/pages/Cortex-th ... 11?sk=info
(0300s) Minnie ---> http://www.facebook.com/pages/Minnie-th ... 02?sk=info
Github ---> https://github.com/pymblesoftware

User avatar
canavan
Posts: 754
Joined: Mon Jul 21, 2003 6:19 am

Re: linkages

Unread postby canavan » Sat Oct 29, 2011 9:31 am

It's actually supposed to be std::sort(), I'm not sure why the compiler or linker fails to properly use it. A cheap workaround would be to sabotage the detection of HAVE_STD_SORT in configure (or the resulting config.h), so that xpdf 3.03 will fall back to the behaviour of 3.02 and just use qsort.

If you're going to make a nekoware package of 3.03, please include the attached desktop icon and rules. For the unlikely case that you don't know how to install them from the .idb, check my neko_nonpareil or neko_xclip packages, I think they have more or less the correct exitop() tag() and removeop() rules.
Attachments
xpdf_icons.tgz
(1.36 KiB) Downloaded 24 times

User avatar
hamei
Posts: 10433
Joined: Tue Feb 24, 2004 4:10 pm
Location: over the rainbow

Re: linkages

Unread postby hamei » Sat Oct 29, 2011 9:55 pm

canavan wrote:It's actually supposed to be std::sort(), I'm not sure why the compiler or linker fails to properly use it. A cheap workaround would be to sabotage the detection of HAVE_STD_SORT in configure (or the resulting config.h), so that xpdf 3.03 will fall back to the behaviour of 3.02 and just use qsort.

This is very timely, and disabling HAVE_STD_SORT 1 is what I ended up doing. Thank you.

Seems ugly, tho. There must be a problem that we should fix, right ?

That's the royal "we", by the way :)

If you're going to make a nekoware package of 3.03, please include the attached desktop icon and rules. For the unlikely case that you don't know how to install them from the .idb, check my neko_nonpareil or neko_xclip packages, I think they have more or less the correct exitop() tag() and removeop() rules.

It's not unlikely at all, I don't even pretend to be a programmer so thank you for the help. I am going to make a tardist but prefer to test things out for a while before I expose myself to ridicule. 3.03 seems to be a good release, lots of things fixed and improved.

I'm thinking maybe the desktop rules should be an option tho ? I quite like the Adobe icon set and it is well-integrated into Irix, so all I do here is replace the adobe executable with xpdf and everything runs as if I were using Acrobat. Then I rename acrobat to crapobat for emergency use. Normally your packages are extremely professional-looking because of your thoroughness, but in this case ..... Put something in the release notes and make it an option, do you s'pose ? Not that anyone ever reads the release notes ....

User avatar
canavan
Posts: 754
Joined: Mon Jul 21, 2003 6:19 am

Re: linkages

Unread postby canavan » Sun Oct 30, 2011 5:52 am

I already have two installations of usr/bin/acroread on my system, xpdf and gsview (the former actually won).. I don't think you can reliably rename previously installed files during the installation of packages. I would assume that you can override file type rules just by specifying new rules that match the same files later. the order should be given in /usr/lib/filetype/Makefile and is (in /usr/lib/filetype) local install system default. I files in local don't override the rules in install, default should work.

User avatar
hamei
Posts: 10433
Joined: Tue Feb 24, 2004 4:10 pm
Location: over the rainbow

Re: linkages

Unread postby hamei » Sun Oct 30, 2011 8:15 pm

canavan wrote:I already have two installations of usr/bin/acroread on my system, xpdf and gsview (the former actually won).. I don't think you can reliably rename previously installed files during the installation of packages.


You're right. I'll just do it straight-up, then if someone wants to replace acroread they can do that themselves.

Any ideas on the weird sorting problem ?

Thanks for your help :)

User avatar
canavan
Posts: 754
Joined: Mon Jul 21, 2003 6:19 am

Re: linkages

Unread postby canavan » Tue Nov 01, 2011 1:20 pm

I have no idea what exactly is going on regarding the sort problem, or how to solve it. C++ has a feature called mangling, where the compiler will encode the required types of parameters in the symbol name in the .o file. It looks to me like the mangled types are too specific, so that the linker doesn't find anything that matches (or maybe the compiler fails to generate a function stub with those types).. The missing symbols are internal helper functions for the sort(); function in <algorithm> fofi/FoFiTrueType.cc. This may just as well be some more modern C++ construct than MipsPro supports, or just plain a gcc-ism.

User avatar
hamei
Posts: 10433
Joined: Tue Feb 24, 2004 4:10 pm
Location: over the rainbow

Re: linkages

Unread postby hamei » Fri Jul 10, 2015 9:57 pm

Time to put a caboose on this thread ... maybe can help anyone coming along later who wants this.

Zo, xpdf is a necessity if you want to use Irix these days. No argument, Acroread 3 is fast, nice, clean, but there are too many pdf's which won't open with Acroread nowadays. And all the other pdf readers have died an ignominious death. Xpdf is still here, still maintained, still runs Motif with the SGI style, etc etc.

New version out recently, 3.04 There's a long list of changes and many seem worthwhile :

http://foolabs.com/xpdf/CHANGES

People here have built this thing before (there's versions in nekoware) but since 3.03 there has been this linking problem. With a very simple environment

Code: Select all

setenv CC cc
setenv CXX CC
setenv CFLAGS '-O3 -mips4'
setenv CXXFLAGS '-O3 -mips4'
setenv CPPFLAGS -I/usr/nekoware/include
setenv LDFLAGS -L/usr/nekoware/lib

xpdf refuses to link. At least for me, which isn't saying much, but there's maybe other novices out there.

SGI has the Standard Template Library. Did some research, in fact, STL was created by HP and adopted by SGI, who collaborated with HP later on on this. So SGI / Irix has the real STL. It's also still available for download.

http://www.sgi.com/tech/stl/download.html

Apparently the gnu std++ pseudo-STL has some problems involving nm. I found several references to this problem and, coincidentally, a longish thread explaining why the function (std::sort) Mr Noonan used in xpdf is no good :D But no real explanation of how to fix it, alas.

Previous hackysack solution was to run ./configure, then edit aconf.h to #undef the HAVE_STD_SORT directive. At 3.03 this worked for me but for some reason this time did not. The failures were probaly due to another library which I built without support for the kitchen sink, aka cups or some other fossy horseshit. Oh wait ! you don't want three gigabytes of crap to support ancient Tibetan script in your error messages ? What's wrong with youse, anyway !?

Anyway, looking back to another thread and thanks beaucoup to Mr Jimmer and Mr Canavan, I came across this environment :

Code: Select all

setenv CC c99
setenv CFLAGS '-O3 -mips4 -DIRIX -I. -I/usr/nekoware/include -I/usr/nekoware/include/freetype2'
setenv CXXFLAGS '-ptused -DIRIX -O3 -mips4 -I. -I/usr/nekoware/include -I/usr/nekoware/include/freetype2'
setenv LDFLAGS '-L/usr/nekoware/lib -L/usr/lib32'

Woo-hoo ! She'sa worka ! Built nicely even with the apparently not-good std::sort function.

Zo II, I'll go mess with this some more but if some person in the distant future has this linker problem, env 2 should make it work.

Any explanations of why would be appreciated, at least by me.

(Oh. Originally I put the freetype includes in the configure line, e.g. ./configure --prefix=/usr/nekoware --with-freetype=/usr/nekoware/include/freetype2 That seemed to work fine, freetype was found and included but that's another possibility to investigate for errors.)

In conclusion, ladies and germs, xpdf 3.04 seems okay. It's probably worth doing, since according to the release notes there were quite a few things fixed and improved. Yet it's no fatter and has no new worthless features and no new toolkit and the controls are all still in the same place and work the same way. No relearning how to do the same thing, just improved performance, Yay !! :D
I spent a fortune on booze, birds, and fast cars ... the rest I just squandered

User avatar
foetz
Moderator
Moderator
Posts: 6543
Joined: Mon Apr 14, 2003 4:34 am
Contact:

Re: linkages

Unread postby foetz » Fri Jul 10, 2015 11:36 pm

hamei wrote:env 2 should make it work.

Any explanations of why would be appreciated, at least by me.

as i wrote in my pm already, xpdf's crappy build system simply ignores CPPFLAGS. moving its content to CFLAGS and CXXFLAGS is one possible solution in this case


Return to “SGI: Development”

Who is online

Users browsing this forum: No registered users and 2 guests