Re: [PATCH] Allow custom flags passed to target-lib builds

[Michael Matz <matz at suse dot de>]

Hi,

On Thu, 24 Nov 2005, Ralf Corsepius wrote:

> > Thanks for the detailled information.  But it looks like this does
> > something slightly different than what I'm aiming at.  What I'm trying
> > to do is give ld.so a set of libraries which it can choose from at
> > dynamic link time based on the actual CPU capabilities.  So a binary
> > built with -march=i586 (lowest common dominator) will still use a fast
> > libgfortran if it runs on say a Pentium4 machine.
> > 
> > So while using the multilibbing infrastructure the library build
> > problem would be solved, the side-effects in the compiler are unwanted
> > (? I'm not sure).
>
> Which compiler side effects?

That the compiler knows about this multilibbing.  This is not what we 
wanted.

> Actually there are 3 separate issues:
> 1. building and installing multilib-variant compiled libs.

We only need this.  I.e. an efficient way of compiling a target library 
with different options and install them in parallel directories.  And only 
for selected libraries (libgfortran in this case), not for all libraries 
which are multilibbed (in GCC sense).

> 2. Link-time selection of multilib-variant compiled libs. I guess, this
> is what you are referring to as "compiler side-effect". 
> At least for us this is a good thing because it hides away all the
> nastiness of multilibs from users.

Right.  But we want a runtime selection (via ld.so, as you conjectured 
already), and not require the user to compile their program differently.  
The use-case would be to provide a libgfortran (or whatever libraries) 
optimized for a set of architectures as distributor, and make the system 
magically use the right one, without recompilation of binaries.

In a way that's multilibbing, but OTOH has nothing in common with GCC's 
way of multilibs.

For instance x86 isn't currently multilibbed at all by default (which I'm
thankful for).  But still one might like to have libgfortran optimized for
Pentium-M, Pentium-4, K7 and i586, and perhaps even based on different
cache sizes (once someone implements cache size aware algorithms).  I 
wouldn't want to have the compiler supporting ten different multilib 
configs (and compile libjava with them ;-) ).


Ciao,
Michael.