On 07/10/10 12:54, a...@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
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
