Multilib question

[Ralf Corsepius]

Am Don, 2002-02-21 um 22.55 schrieb Bill Butler:

> All,
> 
> Could someone explain what multilib is for. 

[Some of this intersects with the responses others had given to this
question. I had written all this before these answers, but had forgotten
to send it. 
Anyway, ... ;)]

The short answer:

Building multilibs means to build a library several times using
different permutations of "machine-near-flags" of the compiler to allow
exploiting architecture/target-variant specific optimizations

The long answer:

Each target supports a variety of sub-targets, sub-architectures,
cpu-variants, special instructions etc. This reflects into compilers
typically providing a plethora of compilation and optimization flags.

If wanting to use cpu-optimized binaries, you will have to pick up a set
of compiler-flags suiteable for your particular cpu/architecture.
Problem: Your binaries will be binary incompatible to other
cpu/architecture-variants of your cpu-family 

Example: Using i686-compiled binaries on i386s without fpu will not
work.

In a "normal system environment", this problem normally is circumvented
either by using the "least common denominator" of optimizations which
comprises all "supported cpus" and to live with some kind of
sub-optimality.

Example: A Linux distributor shipping i586 compiled binaries 
=> Disregarding i486s, sub-optimality for users with cpus > i586.

Though this is applicable for "normal systems", the "sub-optimality" can
be permissive for embedded systems, because the range of
cpu-/architecture-variants is much wider than on the "mass-market" and
because the demand on specific cpu-/architecture-specific optimizations
is much larger.

The standard work-around would be to compile each binary with custom
flags fitted to suite your particular system's needs.
Problem: Inconvenient and error-prone for users, disallows distibutors
to distribute binaries.

Gcc's work-around: Multilibs.

Gcc contains a predefined set of flags it thinks to be important
cpu-/architecture-variants being worth to build libraries for.

Eg.
/opt/rtems/bin/m68k-rtems-gcc --print-multi-lib
.;
m68000;@m68000
m5200;@m5200
mcpu32;@mcpu32
msoft-float;@msoft-float

These flags are getting used when building the libraries contained
inside of gcc and newlib. gcc builds all libraries which support
multilibs each time new, once for each set of CFLAGS from gcc's set of
multilib flags. 

Eg: newlib (aka. RTEMS's libc.a)
# find /opt/rtems/m68k-rtems/lib/ -name libc.a
/opt/rtems/m68k-rtems/lib/libc.a
/opt/rtems/m68k-rtems/lib/mcpu32/libc.a
/opt/rtems/m68k-rtems/lib/m68000/libc.a
/opt/rtems/m68k-rtems/lib/m5200/libc.a
/opt/rtems/m68k-rtems/lib/msoft-float/libc.a

> I get the feeling it is
> Grand.. I just don't understand enough about it to know why.
> 
> But never wanting to be behind, today with 20020215 SS I installed with
> 
> ../rtems-ss-20020215/configure --enable-multilib --prefix=/opt/rtems
> --target=m68k-rtems>
> make RTEMS_BSP="" preinstall
> make RTEMS_BSP="" 
> 
> so now what.?
> So I tried 
> make RTEMS_BSP="<bsp>" preinstall  (working through a custom one )
> make RTEMS_BSP="<bsp>" 
> make install?

make RTEMS_BSP="<bsp>" install

[Otherwise all bsps for a cpu will be compiled and installed, something
you probably will not want]

> I have hunted around the past archive and online docs but have not found
> any reference to multilib that explains it.
I think gcc.info contains some remarks on it.

However, unless wanting to use several cpu-variants in parallel,
building RTEMS non-multilib'ed is sufficient for individuals.

Ralf