Re: better support for AIX 5.1

[Jim Edwards]

Here is the problem, or misunderstanding.  AIX does not build static 
libraries unless the -bstatic flag is explicitly used.  The objects foo.o 
bar.o etc are by definition shared objects. 

Looking at libcurses as you suggest we see different objects with versioning 
info but we don't see anything of the form lib<>.so 

bb0001en$  ar -X32_64 t /usr/lib/libcurses.a
shr42.o
shr4.o
shr.o
shr42_64.o 

I'll get you a reference for that tommorrow.  I appreciate your position 
Robert and I don't blame you for being very cautious, especially after I 
bungled the patchs. 

address@hidden writes: 

> I think libtool currently does something like this
> when building AIX style libraries: 
>
>   ld -bM:SRE -o lib<name>.so.<version> foo.o bar.o baz.o ...
>   ar cq lib<name>.a lib<name>.so.<version>
>   
> This is not exactly like most of the libraries that ship with
> the operating system, which do use shr.o (or shr_64.o for 64-bit
> objects) as Robert indicates below.  But there are some exceptions,
> just try running this command:
>   ar -X32_64 t /usr/lib/libcurses.a
> or 
>   ar -X32_64 t /usr/lib/libc.a 
>
> The libcurses example shows that it is sometimes desireable to
> have a version number in the shared object name.
>   
> Anyway, my point was that if you change the name of the shared object
> that gets archived into the lib<>.a, you break binary compatibility.
> If you rebuild package xyz with this new version of libtool, you will
> also have to rebuild any other packages that use libxyz.a, and so on,
> and so on... 
>
> I'm not sure if this would be a big problem or a little problem, but
> breaking binary compatibility is something that should be avoided
> whenever possible. 
>
> Dan
>    
>
>
> > From address@hidden Thu Jun  5 16:27:06 2003 
> >
> > Jim, 
> >
> > This is contrary to what I have understood to be the way
> > to build AIX-style libraries.  I was under the impression
> > that object files are made into an AIX library with two
> > commands.  As an example (flags may not be exactly correct):
> >   ld -bM:SRE -o shr.o foo.o bar.o baz.o ...
> >   ar cq libmine.a shr.o 
> >
> > If you leave out creation of shr.o and substitute the object
> > files that were used as input to it, you get a static library.
> > So if one were to skip making shr.o and archive the object files
> > into the lib, that would result in a static lib.
> > If you have AIX documentation that refutes this, post the link
> > because I think we'd all like to learn from this.
> >   IMHO, if you want to make all the libtool tests to pass when
> > making AIX libraries, figure out why they don't pass and post it.
> > I don't see much going on here but change for the sake of change. 
> >
> > Thanks, 
> >
> > Robert 
> >
> > -----Original Message-----
> > From: jedwards [mailto:address@hidden
> > Sent: Thursday, June 05, 2003 2:57 PM
> > To: address@hidden
> > Cc: address@hidden
> > Subject: Re: better support for AIX 5.1 
> >
> >
> > Dan, 
> >
> > I'm not sure if I understand your question.  But lets take the demo 
> > directory as an example. 
> >
> > The AIX style shared objects foo.o and hello.o are archived into 
> > libhello.a(foo.o) and libhello.a(hello.o)
> > They are also translated into SYSV style shared objects in libhello.so.  
> > It is a mistake to archive libhello.so in libhello.a.  
> >
> > Jim 
> >
> >  
> >
> > address@hidden wrote: 
> >
> > >Jim,
> > >
> > >One other thing I thought of.  When building an AIX style library,
> > >the name of the shared object that gets archived into the lib<>.a
> > >file should not change if you want to maintain binary compatibility.
> > >I can't quite tell if this would be a problem or not in your patch.
> > >
> > >Dan
> > >
> > >  
> > >
> > >>From: jedwards <address@hidden>
> > >>
> > >>Attached is a patch to the current cvs of libtool which I believe 
> > >>provides improved support for the AIX 5.1 OS and for AIX style shared 
> > >>libraries using native compilers.
> > >>    
> > >> 
> >
> >
> > --
> > Jim Edwards             address@hidden
> > IBM Applications Analyst
> > NCAR SCD
> > BOULDER CO  303-497-1842  
> >
> >  
> >
> >
> > _______________________________________________
> > Libtool-patches mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/libtool-patches 



Jim