Re: Install of libtool module on AIX 4.2 does not work.

[Gary Kumfert]

On Mon, 17 Jan 2005, Ralf Wildenhues wrote:

> Hi Gary,
>
> * Gary Kumfert wrote on Sat, Jan 15, 2005 at 02:04:55AM CET:
> >
> > There aren't two types of shared libraries... there's shared
> > and there's dynamic (or "run time linked" in AIX speak. hence -brtl.)
>
> This I can mostly agree with.
>
> > Even then, the switch doesn't *really* care about the type... just the
> > suffix in the filesystem. (Below is an exercise I just did
> > to confirm this.)
>
> This I must respectfully disagree with.  See below.
>
> > The bigger issue in Peter's question, I thought was:
> > why should he (or me, or my customers for that matter) have to know
> > to configure with "LDFLAGS=-brtl" in the first place?

> > The point of libtool is to hide such platform-specific details.
>
> I would love to simplify things here -- and in any way, I see the need
> to either do that or at least update Libtool documentation on the joys
> encountered on AIX, so the user knows what to do.
>
> > (I concede that its not easy since AIX has a unique mapping of
> >  the 3 linkage concepts [static, shared, dynamic] onto the two
> >  file suffices [*.a, *.so].  OTOH, I suppose IBM figures its a
> >  novel feature of ELF that all shared libraries can be dynamically
> >  loaded.)
> >
> > Requiring LDFLAGS=-brtl at configure time is IMHO a bit
> > heavy-handed.  In my own build, I don't want -brtl to show up
> > *everywhere*.... only certain places.
> > I'd much rather specify it my makefiles using a
> > platform-independent libtool option, and let libtool intuit
> > that its "-Wl,-brtl" on AIX, and "" elsewhere.
>
> When?  Under which circumstances would it make sense?
> What does portable software that does this on AIX do
> on other systems which do not allow so many choices?

I can give an example in my project which runs on Linux,
AIX, Solaris, & (hopefully soon) MacOSX.

I do static, shared, & dynamic linking in my regression tests.
There are drivers, caller libraries, and callee libraries.
The drivers and caller libraries are always in the same language,
but the caller and callee libraries are arbitrary pairs of
C, C++, F90, F77, Python, and Java.  Code in the caller libraries
has #ifdef PIC regions in it.  When I do static linking
throughout (for performance), the preprocessor symbol PIC must
not be defined.  When I do dynamic linking of the callee libraries
(useful for flexibility and supporting interpreted languages),
the caller libraries are from the same code, but compiled with -DPIC,
and given the .so suffix to avoid the .a suffixed libraries.

So a single test may be built several ways: here's a sketch of
how things are setup.

$(CXX) -static -o runCxx2C driver.lo libClient.la ../libC/libServer.la
$(CXX) -static -o runCxx2Cxx driver.lo libClient.la ../libCxx/libServer.la
$(CXX) -static -o runCxx2CF77 driver.lo libClient.la ../libF77/libServer.la
$(CXX) -static -o runCxx2CF90 driver.lo libClient.la ../libF90/libServer.la
$(CXX) -dynamic -o runAll driver.lo libClient.la

Now to run all these combinations

./runCxx2C "C++ to C (static)"
./runCxx2Cxx "C++ to C++ (static)"
./runCxx2F77 "C++ to F77 (static)"
./runCxx2F90 "C++ to F90 (static)"
LD_LIBRARY_FLAGS=../libC/libServer.la ./runAll "C++ to C (dynamic)"
LD_LIBRARY_FLAGS=../libCxx/libServer.la ./runAll "C++ to C++ (dynamic)"
LD_LIBRARY_FLAGS=../libF77/libServer.la ./runAll "C++ to F77 (dynamic)"
LD_LIBRARY_FLAGS=../libF90/libServer.la ./runAll "C++ to F90 (dynamic)"

Note that I really only need -brtl in linking the runAll executable,
not the static linked ones.  (Caution: don't get too  mired in other
details, I've been hacking on libtool a bit.)

> > P.S.  For all kinds of nitty-gritty's, I recommend
> >     http://www.ibm.com/developerworks/eserver/pdfs/aix_ll.pdf
>
> Thank you very much for this pointer.

You're welcome.  Its been indispensable for me.

> > P.P.S.  Now for the exercise which builds a lib*.a and then renames
> >     it lib*.so to indicate -brtl really is a filename thing,
> >     not a library-type issue.
> >
> > > cat foo1.c
> > #include <stdio.h>
> > foo() {
> >   printf("foo1\n");
> > }
> >
> > > cat foo2.c
> > #include <stdio.h>
> > foo() {
> >   printf("foo2\n");
> > }
> >
> > > cat main.c
> > int main() {
> >   foo();
> > }
> >
> > > xlc -g -c foo1.c
> > > ar cru libfoo.a foo1.o
> > > ranlib libfoo.a
> > > mv libfoo.a libfoo.so # if its a type thing, maybe this would upset it?
>
> This comment is misleading.
> It's not just the type.  It's also the fact that ..
>
> > > xlc -g -c foo2.c
> > > ar cru libfoo.a foo2.o
> > > ranlib libfoo.a
> > > xlc -brtl -o main1 main.c -L. -lfoo  # this picks up libfoo.so (foo1.o)
>
> ..at this point, foo is bound:
> $ dump -HTv main1 | grep foo
> $
>
> Just like how you use a static library, and very much unlike shared
> linking.

Excellent point!  I hadn't noticed this.

> > > xlc -o main2 main.c -L -lfoo         # this picks up libfoo.a (foo2.o)
> > > ./main1
> > foo1
> > > ./main2
> > foo2
> >
> > The AIX *convention* is to reserve the *.so suffix for dynamic loaded
> > libraries ("run time linkage" in AIX-speak.... which is probably the
> > reason for the flag's name -brtl).  It seems intended to apply shared
> > linkage to run-time linked libraries.  (Which makes sense since in AIX,
> > there's also a switch to apply static linkage to otherwise shared
> > libraries).  Note that if I build libfoo.so the usual way, this also works
> >
> > > xlc -G -o libfoo.so foo3.o  #assume this prints foo3, without me showing 
> > > code
> > > ./main1  # no need to relink main1
> > foo3
>
> $ cat >foo3.c
> #include <stdio.h>
> foo() {
>   printf("foo3\n");
> }
> int vfoo = 99;
> 
> $ xlc -g -c foo3.c
> $ xlc -G -o libfoo.so foo3.o
> $ ./main1
> foo1
>
> Unless you also build libfoo.so with -G resp. -brtl, you do not get the
> desired linking behavior.  Furthermore, if you create an archive but
> defer the linking, the linking above does not only involve the library
> name and the symbol, but also the archive member that contains the
> symbol.
>
> You have many choices on AIX.  Globally using -brtl is too expensive,
> else libtool should probably use that.
>
> Maybe all this is just me misunderstanding you.  I'd love to be
> corrected then.  In any case, ideas for improvement on how libtool
> handles all this are welcome.
>

Ralf, this is a helpful response.  Thanks! I'll have to
read/think about/experiment with this more.

Gary




> > I didn't bother trying to dlopen a library built with ar.
> > We all know what happens there on AIX.  ;)
>
> No, I don't.  But that doesn't matter much to me.
>
> Regards,
> Ralf
>
>
> _______________________________________________
> http://lists.gnu.org/mailman/listinfo/libtool
>