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