[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU Libtool 1.5.8 released.

From: Ralf Corsepius
Subject: Re: GNU Libtool 1.5.8 released.
Date: Fri, 13 Aug 2004 08:40:56 +0200

On Fri, 2004-08-13 at 04:15, Bob Friesenhahn wrote:
> On Fri, 13 Aug 2004, Ralf Corsepius wrote:
> >>
> >> 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
> If I wrap gcc up in a script which provides secret -m options, then 
> you can't see what I am doing.  Neener, neener, neener! :-)
> 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.
What for?

If you have a look at RH's patch, the actual problems they are trying to
solve are:

* Setting up sys_lib_search_path_spec, i.e. to retrieve gcc's internal
library search path, which, due to the impact of multilibs does not
match with the traditional library search path.

* Setting up sys_lib_dlsearch_path_spec, i.e. to merge the compilers
settings with those of the dynamical linker.

"file" doesn't help much here, in general, because multilibs don't
necessarily produce different output in "file".
RH is able to apply it, because in their particular case, both multilib
variants can be distinguished by using "file". In other case this won't

[Consider soft-float/fpu multilib variants (very common on embedded
targets), same ABI, same instruction sets (soft-float using a subset of
the "fpu" instruction set)]

>   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.
Exactly. However, in case of GCC this should be doable (cf. gcc


reply via email to

[Prev in Thread] Current Thread [Next in Thread]