Re: libtool and AIX

[Dan Stromberg]

Hi.  Sorry it took me a while to get back to you.  We had a baby, and
things just got really hectic after that.  :)

Anyway, please see below:

On Fri, 2005-06-24 at 09:00 +0200, Ralf Wildenhues wrote:
> Hi Dan,
> 
> * Dan Stromberg wrote on Thu, Jun 23, 2005 at 11:38:33PM CEST:
> > 
> > Anyway, I'm writing about the possibility of getting libtool working
> > better on AIX.
> 
> Cool!

:)

> > The primary reason AIX is an exception to the general rules, is that it
> > appears that when you compile an AIX binary defining a library path for
> > the executable at runtime, the first file/directory listed in that path
> > has a special meaning - sometimes.
> 
> All of your explanations pertain to the non-brtl case, right?
> (I.e., the case where LDFLAGS=-Wl,-brtl was not given)

I'm not really certain if the -brtl case is different or not - it
appears to be about not optimizing away libraries that don't seem to be
getting used.  Are you familiar enough with AIX shared libraries to say
one way or the other?  Or is this generic across a bunch of *ix's (but
then AIX seems to be quite an oddball).

> > More specifically, if that first directory component really is a
> > directory, then it'll be searched as one would expect on just about any
> > other *ix.
> > 
> > However, if that first directory component in the : separated list isn't a
> > directory, then it's interpreted as a "loader domain", which is more or
> > less a namespace for libraries.
> > 
> > Why does AIX need library namespaces?  Because AIX's default behavior is
> > to load one version, and one version only, of a given library.  Yes, if
> > you want libfoo-2.0 and libfoo-1.0 loaded into core concurrently, then
> > tuff nuggies, you only get the first one that was loaded, unless:
> > 
> > 1) You slibclean away the library
> > 2) You put one or both of those programs into non-default loader domains
> > 
> > So to recap, AIX really wants to place a special interpretation on the
> > first directory in a runtime library load path, sometimes.
> > 
> > It appears that libtool, however, sometimes likes to insert directory
> > paths ahead of the directory paths that are specified by the programmer
> > (true?).
> > 
> > So if libtool could have some sort of way of specifying something like one
> > fo the following, that might really help matters on AIX:
> > 
> > 1) Preserve library search path, taking new dirs on the end
> > 2) Optionally specify a special path that will Always end up first in the
> > library search path
> > 3) Have a general way of specifying what must go ahead of what
> > 
> > Any thoughts on how to go about this?
> 
> Yes.  The first best thing to do is to write a test case which exposes
> this, preferably for CVS HEAD or branch-2-0.  Something like this:
> 
> # create old
> $LIBTOOL --mode=compile $CC $CFLAGS -c a.c
> $LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o liba.la a.lo \
>     -rpath $prefix1/lib -version-info ...
> $LIBTOOL --mode=install ...
> # create new
>   ... $prefix1
>  ...
> # link against it
> 
> (which is most conveniently achieved in the Autotest framework of HEAD.
> For a version in the old-testsuite style see a recent patch by Sven.)
> 
> A test (or several) makes it easy to see which part you want changed,
> and we might be in a better position to decide which change is the best.
> 
> Can you be bothered to write such a test?

Yes, I likely could.

Unfortunately, it'll probably mean something like:

1) Create a shared library, libbig-unique-name.a, with a function:

        int f()
                {
                return 1;
                }

2) Create another shared library, libbig-unique-name2.a, with another
function:

        int f()
                {
                return 2;
                }

3) Compile a program tst.c, with something like:

        main()
                {
                if (f() == 1)
                        {
                        printf("original result\n");
                        }
                else
                        {
                        printf("new result\n");
                        }
                }

...and link tst.c against libbig-unique-name.a, and run it.  Discard the
output.

3) Compile another program, tst2.c, which is identical to tst.c (could
we just use the same program name?  Not sure), linking it against
libbig-unique-name2.a, and run it.

4) If we have weird AIX libraries, then very nearly 100% of the time,
tst2 should output "original result", just like tst did.

Broken?  Yes, it sure seems that way to me.

A yet stronger indication, is if the system has an "slibclean" command,
that will make tst2 output what one would expect.

They seem to be more like windows and os/2 libraries than *ix libraries.

I wonder if it would be possible to use the same code for AIX and
windows and OS/2?  I don't seem to see an slibclean program on a windows
2000 pro system though.

Thanks!

signature.asc
Description: This is a digitally signed message part