| Summary: | x11-libs/libXaw is created with incorrect version numbers | ||
|---|---|---|---|
| Product: | Gentoo/Alt | Reporter: | Stuart Shelton <srcshelton> |
| Component: | Prefix Support | Assignee: | Gentoo Prefix <prefix> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | IRIX | ||
| URL: | https://bugs.freedesktop.org/show_bug.cgi?id=20883 | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Stuart Shelton
2008-09-03 09:03:02 UTC
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. |
