bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

versioning test on AIX (was: libtool-2.2.8 on AIX 6.1)


From: Ralf Wildenhues
Subject: versioning test on AIX (was: libtool-2.2.8 on AIX 6.1)
Date: Sat, 7 Aug 2010 00:30:01 +0200
User-agent: Mutt/1.5.20 (2010-04-22)

* Rainer Tammer wrote on Tue, Aug 03, 2010 at 09:40:23AM CEST:
> On 02.08.2010 20:40, Ralf Wildenhues wrote:
> > * Rainer Tammer wrote on Mon, Aug 02, 2010 at 05:40:13PM CEST:
> >> 56: versioning                                      FAILED
> >> (versioning.at:169)
> > This testsuite bug should (hopefully) be fixed in 2.2.10.  Testsuite
> > bugs are no need to worry.
> >
> Unfortunately no.

> ## -------------------------- ##
> ## libtool 2.2.10 test suite. ##
> ## -------------------------- ##

>  56: versioning                                      FAILED
> (versioning.at:172)

This particular test failure is a real failure but not a regression;
it is new because the tests is new.  Quoting the relevant bits from the
testsuite.log:

| ./versioning.at:237: $LIBTOOL --mode=clean rm -f liba.la
| stderr:
| stdout:
| libtool: clean: rm -f liba.la .libs/liba.a .libs/liba.a .libs/liba.so.2 
.libs/liba.la .libs/liba.lai
| libtool: clean: rmdir .libs >/dev/null 2>&1
| ./versioning.at:172: if "$lt_exe" ; then :; else lt_status=$?;             
test "X$host" != "X$build" && test -x "$lt_exe" && exit 77;     exit 
$lt_status; 
| --- /dev/null   2010-08-03 08:56:09.000000000 +0200
| +++ /daten/source/libtool-2.2.10/tests/testsuite.dir/at-groups/56/stderr      
  2010-08-03 08:56:09.000000000 +0200
| @@ -0,0 +1,3 @@
| +Could not load program 
/daten/source/libtool-2.2.10/tests/testsuite.dir/056/inst/bin/prog1:
| +       Dependent module 
/daten/source/libtool-2.2.10/tests/testsuite.dir/056/inst/lib/liba.a(liba.so.0) 
could not be loaded.
| +       Member liba.so.0 is not found in archive 
| ./versioning.at:172: exit code was 255, expected 0
| 56. versioning.at:24: 56. versioning (versioning.at:24): FAILED 
(versioning.at:172)

Oh well, hacking libtool wouldn't be half the fun without AIX. :-/

The test tries to ensure that with an incompatible library upgrade,
programs previously linked against the old library still work.  This
usually works on systems where different major versions of a library
have different file names.  Which isn't the case for AIX without
runtimelinking (liba.a is the same name whether it contains liba.so.2
or liba.so.0):

$ ls inst/lib
liba.a   liba.la  libb.a   libb.la

$ ar t inst/lib/liba.a
liba.so.2

Now, the part that really surprised me was that this doesn't even work
with runtimelinking (configure LDFLAGS=-Wl,-brtl), even though the file
names aren't the issue here:

$ ls -l inst/lib | sed 's/.*[0-9] \(lib.*\)/\1/'
total 45
liba.a
liba.la
liba.so -> liba.so.2.0.0
liba.so.0 -> liba.so.0.1.0
liba.so.0.0.1
liba.so.0.1.0
liba.so.2 -> liba.so.2.0.0
liba.so.2.0.0
libb.a
libb.la
libb.so -> libb.so.0.0.0
libb.so.0 -> libb.so.0.0.0
libb.so.0.0.0

The failure looks like this:
$ ./prog1
exec(): 0509-036 Cannot load program ./prog1 because of the following errors:
rtld: 0712-001 Symbol a was referenced
      from module prog1(), but a runtime definition
      of the symbol was not found.

The apparent reason for the failure is that it's not the versioned name
that is encoded:

$ dump -H inst/bin/prog1
[...]
                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER              
0      /tmp/build/tests/testsuite.dir/064/inst/lib:/usr/vac/lib:/usr/lib:/lib   
                                      
1                                    liba.so                                 
2                                    libc.a              shr.o               
3                                    librtl.a            shr.o               


(For reference here's also the respective output for non-rtl:

$ dump -H inst/bin/prog1
[...]
                        ***Import File Strings***
INDEX  PATH                          BASE                MEMBER              
0      /tmp/build/tests/testsuite.dir/064/inst/lib:/usr/vac/lib:/usr/lib:/lib   
                                      
1                                    libc.a              shr.o               
2                                    liba.a              liba.so.0           

)


So, while I'm not completely sure yet that there isn't another bug
lurking in libtool here, it seems that this is another AIX limitation.

One way out may be to use loader domains; see here for a description:
<http://stromberg.dnsalias.org/~strombrg/AIX-shared-libs.html>

I don't really see how to apply this concept in general, i.e., without
user intervention.  So, for now I propose the patch below to skip this
part of the part; I will leave time for comments before pushing it.

Cheers,
Ralf

    Skip part of versioning test on AIX.
    
    * tests/versioning.at (versioning): The AIX linker always
    records the unversioned library name, even with runtimelinking,
    so skip the execution test for the incompatibly upgraded
    library.
    Report by Rainer Tammer.

diff --git a/tests/versioning.at b/tests/versioning.at
index eef7c4a..1d75f62 100644
--- a/tests/versioning.at
+++ b/tests/versioning.at
@@ -24,7 +24,7 @@
 AT_SETUP([versioning])
 AT_KEYWORDS([libtool])
 
-eval "`$LIBTOOL --config | $EGREP '^(objdir)='`"
+eval "`$LIBTOOL --config | $EGREP '^(objdir|host_os)='`"
 
 # Setup some library and program sources:
 # a library (a1), a new revision (a2), a compatible update (a3),
@@ -227,6 +227,11 @@ AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o 
liba.la liba4.lo ]dnl
 # available, so test_uninstalled will not necessarily work here any more.
 AT_CHECK([$LIBTOOL --mode=install cp liba.la $libdir], [], [ignore], [ignore])
 AT_CHECK([$LIBTOOL --mode=clean rm -f liba.la], [], [ignore], [ignore])
+
+# This test does not work on AIX, not even with runtimelinking, because
+# the linker always records the unversioned name as dependency.
+AT_CHECK([:; case $host_os in aix*) exit 77;; esac])
+
 test_installed
 
 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]