RE: better support for AIX 5.1

[Boehne, Robert]

Dan,

>From past changes (IRIX adding +1 to version #) it's been
decided that any change to versioning is not done unless
it fixes some problem that would be so bad, the version schism would
be the least of your problems.

Robert


-----Original Message-----
From: address@hidden [mailto:address@hidden
Sent: Thursday, June 05, 2003 5:08 PM
To: address@hidden; address@hidden; Boehne, Robert
Cc: address@hidden
Subject: RE: better support for AIX 5.1


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
>