SGI: Development

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 ...



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

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.

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.

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 ....

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.

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

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.

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


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 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 :

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 !!

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