... just like libXaw in Bug 236545. The 'ltmain.sh' included with jpeg-8 causes IRIX to create libraries named 'libjpeg.so.9.0'. Luckily, this is trivial to fix by removing the increment from ltmain.sh. I notice that $EPREFIX/usr/share/libtool/config/ltmain.sh also has this stray increment - so I'd assume that this is a bug in libtool (which is perhaps trying to fix a deprecated behaviour of old IRIX versions?). Can anything be done about this universally?
Created attachment 216902 [details, diff] Remove increment which is causing mis-numbered IRIX DSOs
I'm not sure if this is a bug in itself, or just something be be expected - but when rebuilding media-libs/jpeg-8 with the fix for correct version numbering, all of the tools (cjpeg, djpeg, jpegtran) installed along with libjpeg.so.8 were linked against the existing (and incorrect) libjpeg.so.9...
this feels like this should be applied to every libtooled package, and hence is better solved by an ELT-patch, right?
Ok, I added your patch to libtool, and I made an ELT patch out of it. This patch is applied for you when using elibtoolize in the ebuild. If you find that your irix-ltmain patch fails to apply, you may need a different patch for different versions of libtool. In that case we can just add them to elcass/ELT-patches/irix-ltmain.
Oh dear - could we revert the ELT change, please? I'm now finding that packages which are linked against libsomething.so.1 are installing files named libsomething.so.0 to the filesystem :( The problem so far seems to affect libXaw and libjpeg, but not other packages (I've just noticed this with xz-utils, which worked before the ELT change) :(
Now I'm confused - I've removed the IRIX ltmain patches and rebuild xz-utils, and now I have a liblzma.so.1, but the xz binary is trying to link against liblzma.so.0! This is presumably related to what was on-disk when the latter was built, despite the libtool changes already having been reverted? Actually, looking at a Linux box with xz-utils installed, the file is liblzma.so.0.0.0 (vs. liblzma.so.1.0 on IRIX without the ltmain patch) - so it may be that the libtool patch is actually entirely correct and shouldn't be reverted, but that the entire installed system has off-by-one library versions(!) I'll keep checking things out...
Okay - *with* the ELT patches, libXaw-1.0.7 installs the following files: 795K 2010-01-26 14:43 /opt/gentoo/usr/lib32/libXaw6.a 1.2K 2010-01-26 14:43 /opt/gentoo/usr/lib32/libXaw6.la 14 2010-01-26 14:43 /opt/gentoo/usr/lib32/libXaw6.so -> libXaw6.so.7.1* 14 2010-01-26 14:43 /opt/gentoo/usr/lib32/libXaw6.so.7 -> libXaw6.so.7.1* 350K 2010-01-26 14:43 /opt/gentoo/usr/lib32/libXaw6.so.7.1* 1.1M 2010-01-26 14:43 /opt/gentoo/usr/lib32/libXaw7.a 1.3K 2010-01-26 14:43 /opt/gentoo/usr/lib32/libXaw7.la 14 2010-01-26 14:43 /opt/gentoo/usr/lib32/libXaw7.so -> libXaw7.so.8.0* 14 2010-01-26 14:43 /opt/gentoo/usr/lib32/libXaw7.so.8 -> libXaw7.so.8.0* 505K 2010-01-26 14:43 /opt/gentoo/usr/lib32/libXaw7.so.8.0* 10 2010-01-26 14:44 /opt/gentoo/usr/lib32/libXaw.so -> libXaw7.so* 12 2010-01-26 14:44 /opt/gentoo/usr/lib32/libXaw.so.6 -> libXaw6.so.6 12 2010-01-26 14:44 /opt/gentoo/usr/lib32/libXaw.so.7 -> libXaw7.so.7 ... however, with the ELT patches, jpeg-8 installs correct versions. libXaw-1.0.6, which was previously affected by the same problem before the ELT patches, does now work correctly: 795K 2010-01-26 15:34 /opt/gentoo/usr/lib32/libXaw6.a 1.3K 2010-01-26 15:34 /opt/gentoo/usr/lib32/libXaw6.la 14 2010-01-26 15:35 /opt/gentoo/usr/lib32/libXaw6.so -> libXaw6.so.6.1* 14 2010-01-26 15:35 /opt/gentoo/usr/lib32/libXaw6.so.6 -> libXaw6.so.6.1* 350K 2010-01-26 15:34 /opt/gentoo/usr/lib32/libXaw6.so.6.1* 1.1M 2010-01-26 15:34 /opt/gentoo/usr/lib32/libXaw7.a 1.4K 2010-01-26 15:34 /opt/gentoo/usr/lib32/libXaw7.la 14 2010-01-26 15:35 /opt/gentoo/usr/lib32/libXaw7.so -> libXaw7.so.7.0* 14 2010-01-26 15:35 /opt/gentoo/usr/lib32/libXaw7.so.7 -> libXaw7.so.7.0* 505K 2010-01-26 15:34 /opt/gentoo/usr/lib32/libXaw7.so.7.0* 10 2010-01-26 15:35 /opt/gentoo/usr/lib32/libXaw.so -> libXaw7.so* 12 2010-01-26 15:35 /opt/gentoo/usr/lib32/libXaw.so.6 -> libXaw6.so.6* 12 2010-01-26 15:35 /opt/gentoo/usr/lib32/libXaw.so.7 -> libXaw7.so.7* ... so the ELT patches do appear to be working. Does libXaw overwrite libtool with its own files at some point during the build? I don't really get how libXaw with the ELT fix has the same problems as all other affected packages without the ELT fix.
I think you get confused by behaviour caused by whatever's been build without the version fix provided by the ELT-patch. If you got pax-utils, try scanelf --soname and --needed on some of the built objects with and without the ELT-patch. Since you don't have a preserved-libs implementation going (I think you lack pax-utils) portage can't help you here when the ELT-patch is fixing stuff, but at the same time breaking your system. It breaks, because sonames that previously were off by one, are now correct, and hence off by one for everything that you had installed. I think the only way to judge whether the ELT patch is really doing what you had anticipated it to do (applying it just to a single package is wrong in this case IMO), if you rebuild from scratch or in isolation, such that you are not distracted by the breakage that your system must be in now.
No pax-utils on this platform, unfortunately. I'm going a complete from-scratch rebuild on one system, and a progressive rebuild on another to test this. So far, it looks as if version numbers were indeed universally off-by-one before, and look much better now. Still /possibly/ still some issues here, though... Whilst sqlite (for example) on Linux installs libsqlite.so.0.8.6, the IRIX build (now - with the ELT patch) installs a file named libsqlite.so.0.6. Having a two-number version isn't surprising - IRIX ignores any numberic suffix on the filename of a DSO (indeed, the documentation suggests avoiding versioned filenames entirely, and only using them where there will be multiple versions present), but gives the option to hard-code a two-value version identifier into the file. In this case, the binary contains the string "-set_version sgi0.5:sgi0.4:sgi0.3:sgi0.2:sgi0.1:sgi0.0:sgi0.6" - so in this case the name of the DSO definitely correctly matches the hard-coded internal version. The "-set_version" line above is superfluous, however, as any DSO with the same major number of considered to be compatible - so version 'sgi0.6' is implicitly binary-compatible with versions sgi0.0 to sgi0.5 inclusive. I just wonder whether the '6' in this case comes from this being the sixth installation on this machine of an updated library, or whether it relates to the '6' in sqlite's 3.6.22 package version? I'll update this bug once the rebuild has completed...
We are sorry to close this bug. We lack the man-power and devotion to support mips-irix in the tree.
