Hi Bob, Joe, libtoolers: Bob Friesenhahn wrote: > It seems that the only valid test to determine the default output architecture > is to compile code and then use 'file' or some other utility to determine the > architecture. In order to produce multilib output, libtool would need to know > the specific options necessary to obtain each desired variant. These options > are compiler and linker specific.
I agree. Much like the options to produce shared libraries at all involves
compiler and linker specific options :-) This is libtool's raison d'etre, and
we should aim to have support for multilib in our roadmap. It has been in our
TODO file for as long as I've been involved with libtool (pushing 7 years now).
Joe Orton wrote:
> On Fri, Aug 13, 2004 at 03:57:59AM +0200, Ralf Corsepius wrote:
> > Solaris-gcc applies traditional multilibs, i.e. it is
> > using multilib subdirs (A subdir of PREFIX/lib).
>
> There is precedent for doing it both ways: IRIX 6.2 and later have
> /usr/lib, /usr/lib32 and /usr/lib64 for the three supported ABIs (O32,
> N32 and N64 respectively).
>
>
> > How do other Linux vendors (Debian, SuSE etc.) handle this issue?
> > I would expect them to be facing the same problems as RH and to have
> > similar work-arounds applied to libtool.
>
> SuSE also ship biarch systems with separate 64-bit /usr/lib64 and 32-bit
> /usr/lib, I believe Mandrake do too, and I believe Debian haven't worked
> out how (or whether) to do biarch yet.
It seems like we can break the back of the problem with support for the two
common multilib approaches described here. I also think that by putting early
support in libtool before too many ad-hoc solutions develop (particularly from
various GNU/Linux vendors) we are probably well placed to help develop some
standardisation before we end up having to support the fragmentation that may
eventually arise if we waitp
However, it is definitely not a 1.5.x issue, and I don't want to delay 2.0 any
further. I think we should revisit the issue once the dust has settled on the
2.0 tree, and we start working on features again.
Cheers,
Gary.
--
Gary V. Vaughan ())_. [EMAIL PROTECTED],gnu.org}
Research Scientist ( '/ http://tkd.kicks-ass.net
GNU Hacker / )= http://www.gnu.org/software/libtool
Technical Author `(_~)_ http://sources.redhat.com/autobook
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
