Re: libtool - building both 32 and 64-bit members for archives in one "pass"

[Michael Felt]

Hi Michael :)

On 20-Jan-16 10:18, Michael Haubenwallner wrote:
> Hi Michael,
>
> On 01/19/2016 09:44 PM, Michael Felt wrote:
> > L.S.,
> >
> > If I understand the documentation correctly libtool places non-shareable 
> > members (.o files) in the src directory
> > and "shareable aka PIC objects in src/.libs". However, libtool makes only one 
> > size of objects - either 32-bit or 64-bit.
> >
> > As "aixtools" I am trying to package (common) opensource projects - and mainly 
> > I have done so as as 32-bit only and was not bothered by the lack
> > of 64-bit build issues. Recently there are packages that may only work well in 
> > 64-bit mode (e.g., R language) and I have started to package
> > in 64-bit as well.
> >
> > As part of my research I see that Linux distros seem to use 
> > .../lib/libsomething* and .../lib64/libsomething* for 32 and 64-bit 
> > (respectively) library
> > packaging. The AIX convention - as you may, or may not know, is not to have 
> > multiple .so files in two directories but to have one .../lib/libsomething.a
> > with multiple members as static and/or shareable objects. The same object name 
> > may be used multiple times, although the legacy convention is to
> > use shr.o as a shared object of multiple .o members and shr64.o for the same .o 
> > files - but compiled in 64-bit mode).
> >
> > I am wondering - and willing to work on - with assistence - an addition to the 
> > .lo target such that both 32 and 64 bit (shared) objects are made
> > for inclusion in a single .a archive - to be compareable with a library as it 
> > would be released by IBM AIX developers/labs.
> IMO, there is no point in having multilib support within libtool for AIX only.
> If ever, multilib support inside libtool should be implemented in some generic
> way - to allow for porting to Linux and others eventually.
Agreed - and the two key words for me are "generic" and "eventually".
I would hope to come up with a way for it to be generic aka portable - 
as that is the whole point of autotools - at least I assume that.
And, I am "arrogant" enough to think I could come up with a generic way 
- but not arrogant enough to think, by definition, it would be the most 
elegant way.  So, hopefully, the "community" would help with making it 
both generic and elegant.
> Instead, for the time being even on AIX, it is up to the package manager to
> separately compile the package in 32-bit and 64-bit mode, and then merge the
> members of both the 32-bit Archive Library and the 64-bit Archive Library into
> one single Archive Library. Agreed this is a little tricky, but possible.
Agreed, possible, but error prone. As an outsider it seems that RPM land 
- knowing different directories are used -
just creates a second package and installs "parallel" to the other-bit - 
and I suspect GNU/LINUX automagically searches both .../lib and 
.../lib64 when looking for libraries - while AIX, by default, is not 
modifying it's LIB search path.
To me, this is simply an acknowledgement that they are different - just 
as libtool, from it's start recognized that different platforms aka 
flavors of ice-cream (aka vanilla UNIX as generic UNIX) have their 
idioscrancies. What they are is not the problem as these differences is 
what gives libtool it's central (as least critical) position in packaging.
> However, this works as long as you have libtool to create Archive Libraries
> at all - which is the default when LDFLAGS does not contain "-brtl".
I am assuming that this means, strictly, that an exported LDFLAGS does 
not contain -brtl as I am suspecting that libtool is adding that flag 
during it's processing. It is a magical flag in any case!

> My 2 cents,
> /haubi/
>
> PS: Probably worth a note: Since libtool-2.4.4 there is the "--with-aix-soname"
> configure option for optional filename-based shared library versioning on AIX,
> which is designed to work with above multilib merging strategy as well.
I looked at this yesterday - comparing both and svr4 (or srv4 - I made a 
typo several times) and I am not thrilled with the contents. Actually I 
was looking for the virsioning support in the filename that the CHANGES 
document discusses (said to look in the manual - but I never found, 
exactly, what I was to find - or it is magical already - e.g., - 
libltdl.so.7 as the archive member name.