On 07/10/10 12:03, Wookey wrote:
gcc has the multilib feature, but the way it is implemented means it
works well for about 2 or 3 options, but you rapidly get combinatorial
explosion of libgcc instances if you try to do more things than that.
(i.e if you ask for v5, v6, v7, vfp, and neon options you get 25
versions of libgcc1, most of which are silly combinations)
It's not really the implementation that gives the "combinatorial
explosion", so much as the problem.
E.g. Say you want enough libraries to be able to build for:
* ARM mode or Thumb mode,
* with FP, or without, and
* both big endian and little endian.
That's 8 different libraries:
1. ARM FP LE
2. ARM FP BE
3. ARM noFP LE
4. ARM noFP BE
5. Thumb FP LE
6. Thumb FP BE
7. Thumb noFP LE
8. Thumb noFP BE
Joseph Myers of Codesourcery has been looking at making this into a
more flexible mechanism where you just choose the combinations you
actually cared about, not every possible one. I hope that the output
of that work would mean we (or someone else like Debian) could choose
to support a couple of other useful options, and maybe even a nice
runtime way of selecting them.
SuperH already has this. When you build the toolchain you can choose
exactly what multilibs will be available with a few configuration
options. Other architectures only let you choose what the default will
be, and whether to build all the multilibs or not.
CodeSourcery limits the number of multilibs in our product builds by
adding our own custom configuration files into the GCC sources, but
these are hardly flexible.
All these solutions still require pre-baking the decision into the
toolchain.
A possible solution to the problem would be to include the sources to
libgcc.a in the installation, and teach gcc to compile it on-the-fly, as
necessary. Obviously, you'd still want to pre-bake the most commonly
used configuration, for performance reasons. This wouldn't work for
libgcc.so, but you probably wouldn't want it to ...
Andrew
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
