Building groff with USE="X" results in gxditview linked against libXaw.so.9 which doesn't exist, even with the latest x11-libs/libXaw installed (bug 211507). I've just been looking at the .la files installed with libXaw, and is it correct that libXaw6.la contains "dlname='libXaw.so.7'", libXaw7.la contains "dlname='libXaw.so.8'", and libXaw8.la contains "dlname='libXaw.so.9'" (which doesn't exist)? Indeed, after a clean install and test of libXaw, my filesystem contains: -rw-r--r-- 1 portage portage 794K 2008-09-02 17:50 /opt/portage/usr/lib/libXaw6.a -rw-r--r-- 1 portage portage 1.1K 2008-09-02 17:50 /opt/portage/usr/lib/libXaw6.la lrwxrwxrwx 1 portage portage 14 2008-09-02 17:50 /opt/portage/usr/lib/libXaw6.so -> libXaw6.so.7.1* lrwxrwxrwx 1 portage portage 14 2008-09-02 17:50 /opt/portage/usr/lib/libXaw6.so.7 -> libXaw6.so.7.1* -rwxr-xr-x 1 portage portage 350K 2008-09-02 17:50 /opt/portage/usr/lib/libXaw6.so.7.1* -rw-r--r-- 1 portage portage 1.1M 2008-09-02 17:50 /opt/portage/usr/lib/libXaw7.a -rw-r--r-- 1 portage portage 1.2K 2008-09-02 17:50 /opt/portage/usr/lib/libXaw7.la lrwxrwxrwx 1 portage portage 14 2008-09-02 17:50 /opt/portage/usr/lib/libXaw7.so -> libXaw7.so.8.0* lrwxrwxrwx 1 portage portage 14 2008-09-02 17:50 /opt/portage/usr/lib/libXaw7.so.8 -> libXaw7.so.8.0* -rwxr-xr-x 1 portage portage 505K 2008-09-02 17:50 /opt/portage/usr/lib/libXaw7.so.8.0* -rw-r--r-- 1 portage portage 1.1M 2008-09-02 17:50 /opt/portage/usr/lib/libXaw8.a -rw-r--r-- 1 portage portage 1.3K 2008-09-02 17:50 /opt/portage/usr/lib/libXaw8.la lrwxrwxrwx 1 portage portage 14 2008-09-02 17:50 /opt/portage/usr/lib/libXaw8.so -> libXaw8.so.9.0* lrwxrwxrwx 1 portage portage 14 2008-09-02 17:50 /opt/portage/usr/lib/libXaw8.so.9 -> libXaw8.so.9.0* -rwxr-xr-x 1 portage portage 507K 2008-09-02 17:50 /opt/portage/usr/lib/libXaw8.so.9.0* lrwxrwxrwx 1 portage portage 10 2008-09-02 17:50 /opt/portage/usr/lib/libXaw.so -> libXaw8.so* lrwxrwxrwx 1 portage portage 12 2008-09-02 17:50 /opt/portage/usr/lib/libXaw.so.6 -> libXaw6.so.6 lrwxrwxrwx 1 portage portage 12 2008-09-02 17:50 /opt/portage/usr/lib/libXaw.so.7 -> libXaw7.so.7 lrwxrwxrwx 1 portage portage 12 2008-09-02 17:50 /opt/portage/usr/lib/libXaw.so.8 -> libXaw8.so.8 ... with the last three being broken links! Is this an off-by-one error (as libXaw.so.6 links to libXaw6.so.6, whereas only libXaw6.so.7 exists on the filesystem, and the version number does seem to be incorrectly incremented in the .la files) - or am I missing a version 9 of libXaw?
I don't even have 8: /Library/Gentoo/usr/lib/libXaw6.6.0.1.dylib /Library/Gentoo/usr/lib/libXaw6.6.dylib /Library/Gentoo/usr/lib/libXaw6.a /Library/Gentoo/usr/lib/libXaw6.dylib /Library/Gentoo/usr/lib/libXaw6.la /Library/Gentoo/usr/lib/libXaw7.7.0.0.dylib /Library/Gentoo/usr/lib/libXaw7.7.dylib /Library/Gentoo/usr/lib/libXaw7.a /Library/Gentoo/usr/lib/libXaw7.dylib /Library/Gentoo/usr/lib/libXaw7.la /Library/Gentoo/usr/lib/pkgconfig/xaw6.pc /Library/Gentoo/usr/lib/pkgconfig/xaw7.pc /Library/Gentoo/usr/share/aclocal/xaw.m4 /Library/Gentoo/usr/share/doc/libXaw-1.0.4/ChangeLog.bz2 /Library/Gentoo/usr/share/man/man3/Xaw.3.bz2 /Library/Gentoo/usr/lib/libXaw.6.dylib /Library/Gentoo/usr/lib/libXaw.7.dylib /Library/Gentoo/usr/lib/libXaw.dylib
It's not so much which versions are installed, more that the versions numbers are completely wrong! From an x86/Gentoo box, the installed versions should be "libXaw6.so.6.0.1", "libXaw7.so.7.0.0", and "libXaw8.so.8.0.0". Instead I get "libXaw6.so.7.1", "libXaw7.so.8.0", and "libXaw8.so.9.0"! Additionally, the version numbers within the .la files are both mixed and wrong (although the current, age, and revision values are correct). Does this indicate a libtool breakage (specific to this package - libXaw doesn't seem to install its own?) or something wrong with the build itself? It looks as if a level of versioning has been dropped but then the prior version number incremented... weird. Also: $ ebuild ~/../usr/portage/sys-apps/groff/groff-1.19.2-r3.ebuild test Forcing test. >>> Existing ${T}/environment for 'groff-1.19.2-r3' will be sourced. Run >>> 'clean' to start with a fresh environment. * groff-1.19.2.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking groff-1.19.2.tar.gz ;-) ... [ ok ] >>> Checking groff-1.19.2.tar.gz's mtime... >>> Checking groff-1.19.2-japanese.patch.bz2's mtime... >>> WORKDIR is up-to-date, keeping... >>> It appears that 'groff-1.19.2-r3' is already prepared; skipping. >>> Remove '/usr/opt/portage/var/tmp/portage/sys-apps/groff-1.19.2-r3/.prepared' to force prepare. >>> It appears that 'groff-1.19.2-r3' is already configured; skipping. >>> Remove '/usr/opt/portage/var/tmp/portage/sys-apps/groff-1.19.2-r3/.configured' to force configuration. >>> It appears that 'groff-1.19.2-r3' is already compiled; skipping. >>> Remove '/usr/opt/portage/var/tmp/portage/sys-apps/groff-1.19.2-r3/.compiled' to force compilation. >>> Test phase [check]: sys-apps/groff-1.19.2-r3 Making a new site.exp file... if /opt/portage/bin/bash -c "runtest --version" > /dev/null 2>&1; then \ runtest; \ else \ echo "WARNING: could not find \`runtest'" 1>&2; \ fi WARNING: could not find `runtest' (I've renamed the libraries and edited the .la files to correct them, but I'm still getting: $ ldd `which gxditview` libSM.so.6 => /opt/portage/usr/lib/libSM.so.6 libICE.so.6 => /opt/portage/usr/lib/libICE.so.6 20438460: 16:04:32 /opt/portage/usr/bin/gxditview: rld: Fatal Error exit/longjmp: Cannot Successfully map soname 'libXaw.so.9' under any of the filenames /opt/portage/usr/lib/libXaw.so.9:/opt/portage/lib/libXaw.so.9:/usr/lib32/libXaw.so.9:/usr/lib32/internal/libXaw.so.9:/lib32/libXaw.so.9:/opt/lib32/libXaw.so.9:/opt/portage/usr/lib/libXaw.so.9.9:/opt/portage/lib/libXaw.so.9.9:/usr/lib32/libXaw.so.9.9:/usr/lib32/internal/libXaw.so.9.9:/lib32/libXaw.so.9.9:/opt/lib32/libXaw.so.9.9: 20438460:/opt/portage/usr/bin/gxditview: rld: Fatal Error: Cannot Successfully map soname 'libXaw.so.9' under any of the filenames /opt/portage/usr/lib/libXaw.so.9:/opt/portage/lib/libXaw.so.9:/usr/lib32/libXaw.so.9:/usr/lib32/internal/libXaw.so.9:/lib32/libXaw.so.9:/opt/lib32/libXaw.so.9:/opt/portage/usr/lib/libXaw.so.9.9:/opt/portage/lib/libXaw.so.9.9:/usr/lib32/libXaw.so.9.9:/usr/lib32/internal/libXaw.so.9.9:/lib32/libXaw.so.9.9:/opt/lib32/libXaw.so.9.9: ... even after cleaning and rebuilding groff. Where is the version 9 or 9.9 coming from?!)
hexediting the binary and replacing that "9" with an "8" works, though ;)
I fear some "we-know-best-for-your-platform" logic in the source :(
ltmain.sh does contain: # convert absolute version numbers to libtool ages # this retains compatibility with .la files and attempts # to make the code below a bit more comprehensible case $vinfo_number in yes) number_major="$2" number_minor="$3" number_revision="$4" # # There are really only two kinds -- those that # use the current revision as the major version # and those that subtract age and use age as # a minor version. But, then there is irix # which has an extra 1 added just for fun # case $version_type in darwin|linux|osf|windows|none) current=`expr $number_major + $number_minor` age="$number_minor" revision="$number_revision" ;; freebsd-aout|freebsd-elf|sunos) current="$number_major" revision="$number_minor" age="0" ;; irix|nonstopux) current=`expr $number_major + $number_minor` age="$number_minor" revision="$number_minor" lt_irix_increment=no ;; esac ;; no) current="$2" revision="$3" age="$4" ;; esac ... # Calculate the version variables. major= versuffix= verstring= case $version_type in ... irix | nonstopux) if test "X$lt_irix_increment" = "Xno"; then major=`expr $current - $age` else major=`expr $current - $age + 1` fi case $version_type in nonstopux) verstring_prefix=nonstopux ;; *) verstring_prefix=sgi ;; esac verstring="$verstring_prefix$major.$revision" # Add in all the interfaces that we are compatible with. loop=$revision while test "$loop" -ne 0; do iface=`expr $revision - $loop` loop=`expr $loop - 1` verstring="$verstring_prefix$major.$iface:$verstring" done # Before this point, $major must not contain `.'. major=.$major versuffix="$major.$revision" ;; ... so it doesn't look as if that increment will actually occur, although I'm suspicious of the last bit.
This happens with libXaw-1.0.5 too. I've had another look, and really can't see where this error is occurring - but right now it's preventing other packages from building properly and requires manual hex-editing of the resulting libraries to fix! Please could someone with a better idea of what is supposed to happen in this build look at the problem?
Reported upstream... they might have more of an idea of what's going on. https://bugs.freedesktop.org/show_bug.cgi?id=20883
This patch allows libXaw to build correctly on IRIX: --- ltmain.sh.dist +++ ltmain.sh @@ -6311,11 +6311,11 @@ func_mode_link () ;; irix | nonstopux) - if test "X$lt_irix_increment" = "Xno"; then + #if test "X$lt_irix_increment" = "Xno"; then func_arith $current - $age - else - func_arith $current - $age + 1 - fi + #else + #func_arith $current - $age + 1 + #fi major=$func_arith_result case $version_type in ... this must be applied within the build's src_compile(): --- libXaw-1.0.5.ebuild.dist +++ libXaw-1.0.5.ebuild @@ -8,7 +8,7 @@ inherit eutils x-modular autotools flag-o-matic DESCRIPTION="X.Org Xaw library" -KEYWORDS="~ppc-aix ~x64-freebsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris ~x86-winnt" +KEYWORDS="~mips-irix ~ppc-aix ~x64-freebsd ~x86-interix ~amd64-linux ~x86-linux ~ppc-macos ~x86-macos ~sparc-solaris ~sparc64-solaris ~x64-solaris ~x86-solaris ~x86-winnt" IUSE="" RDEPEND="x11-libs/libX11 @@ -47,5 +47,10 @@ src_unpack() { src_compile() { [[ ${CHOST} == *-winnt* ]] && append-flags -xc++ + if [[ ${CHOST} == *-irix* ]]; then + ewarn "Patching ltmain.sh to prevent IRIX mis-numbering..." + epatch "${FILESDIR}"/${P}-ltmain.sh.patch || die "ltmain.sh patch failed to apply" + fi + x-modular_src_compile }
libXaw-1.0.6 runs an eautoreconf, which should overwrite the ltmain.sh with a fresh one. Does the problem persist in that case? That means that somehow the libtool provided files contain this bug.
That's odd... libXaw-1.05 and libXaw-1.06 both build correctly with the same patch against ltmain.sh applied, whereas libXaw-1.0.7 currently doesn't work :( 1.0.7 has the same off-by-one error, but the 'ltmain.sh' which exists at the src_compile stage is sufficiently different that the previous patch cannot be directly used. Having created a new patch which does exactly the same thing as the old patch, the problem still exists. I won't attach the new patch separately, since it doesn't work, but for comparison with the working patch in Comment #8, the new broken patch reads: --- ltmain.sh.dist 2009-10-29 01:11:32.935637200 +0000 +++ ltmain.sh 2009-10-29 01:13:11.821581000 +0000 @@ -3362,11 +3362,11 @@ ;; irix | nonstopux) - if test "X$lt_irix_increment" = "Xno"; then + #if test "X$lt_irix_increment" = "Xno"; then major=`expr $current - $age` - else - major=`expr $current - $age + 1` - fi + #else + #major=`expr $current - $age + 1` + #fi case $version_type in nonstopux) verstring_prefix=nonstopux ;; *) verstring_prefix=sgi ;;
Since our ELT-patch, this should work fine out of the box now, since X-packages run elibtoolize by default.
