Re: GNU Libtool 1.5.8 released.

[Ralf Corsepius]

On Thu, 2004-08-12 at 18:12, Peter O'Gorman wrote:
> Bob Friesenhahn wrote:
> 
> > On Thu, 12 Aug 2004, Tim Mooney wrote:
> > 
> >> Why just Linux?  Isn't this essentially the same issue that the multi-ABI
> >> commercial UNIXes have?
> > 
> > 
> > Seems like it to me.
I am not sure. Solaris-gcc applies traditional multilibs, i.e. it is
using multilib subdirs (A subdir of PREFIX/lib).

I don't know how "multiarchs" are implemented in RH's ix86_64 gcc.
/usr/lib64 is not a subdir of PREFIX/lib

>   For example, Solaris puts 64-bit libraries in a 
> > 'sparcv9' subdirectory. The 'sparcv7' directory is used for libraries 
> > built for older SPARC processor types.  Libraries optimized for 32-bit 
> > Ultrasparc are put in the traditional location.
> 
> Well, the difference, in my little mind at least, is that the commercial 
> unixes can all be identified in libtool using $host,
Right, you can identify $host and in case of Solaris even the OS version
as part of $host (solaris2.8).

However, you can not identify the multilib-variant and the multilib
subdir being used from $host, because it is chosen depending upon the
flags being passed to gcc:
sparc-sun-solaris2.8-gcc .. -> . (sparcv7)
sparc-sun-solaris2.8-gcc -m64 .. -> sparcv9

=> There is no fixed "host" to multilib subdir mapping.
IMO, RH's multilib-patch is just a "band-aid" (read: hack) to help them
keep libtool going on their systems, but is not a generalizable
approach.

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.

Ralf