[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
libtool - building both 32 and 64-bit members for archives in one "pass"
From: |
Michael Felt |
Subject: |
libtool - building both 32 and 64-bit members for archives in one "pass" |
Date: |
Tue, 19 Jan 2016 21:44:49 +0100 |
User-agent: |
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 |
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.
So, question: who is willing to be a mentor to me so that I
a) make progress
b) do not make a total mess of the current state
as I would like what I do to be
a) acceptable
b) fit in the current model
regards,
Michael
- libtool - building both 32 and 64-bit members for archives in one "pass",
Michael Felt <=