On 07/10/10 12:54, arnd@arndb.de wrote:
On Thursday 07 October 2010 13:03:14 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)
If I understood Uli correctly, you can have one version of libgcc that is used as the fallback in a multilib setup, and most variants are backwards compatible.
Yes, with some carefully thought out custom configuration patches we can certainly do something like what you suggest.
You can tell GCC exactly what arches you want multilibs for, and what options (neon, vfp, etc) you want multilibs for, and it will automatically fill in the N-dimensional matrix that gives you all those options.
Like Wookey said, this can produce a selection of pointless libraries that either make no sense, or else are duplicates of other libraries, so GCC has ways to deal with this:
1. You can disable any specific option combination you like.
2. You can specify that one set of options should use the library from another, compatible set of options.
3. You can add custom "specs" rules that tell it what to do in the "fall back" case (normal procedure is to use the default library - the primary target for the toolchain, but in this case, we're talking about having a fall-back to a lowest-common-denominator library, which would be far less optimal).
All this can be done with a small patch to two or three files. It's quite easy, but we just need to know what it is we want to achieve. Any such patch should be done in a way that plays nice with other people requirements for building the sources, and even then would probably not be acceptable upstream.
Although these things *can* be done, I'm really not sure that they *should*. As has been pointed out already, this use case really is an abuse of a Linux user-space compiler, and will add features that 99.99% of users will never care about, yet will increase both the build and test burden for developers/packagers all the time, possibly considerably.
Andrew