rtems gcc 4.6.1 can not compile stop at check TLS
joel.sherrill at OARcorp.com
Mon Aug 29 16:27:40 CDT 2011
Just to try to wrap this up:
+ There are both multiply-enabled and
multilib variants in both the 4.10 and 4.11 RPMs. Is
this the desired set?
+ Is this a reasonable and meaningful set?
+ The number of multilib variants per target varies from
1 to 15 for 4.11. lm32 is at 4. The distribution of number
of variants per architecture is:
I am not saying that any variant is not justified but 4 is
far from the worst case. Taken a broad view, 10 of 15
targets have 6 or less.
Multilib variants are always a hot topic and justifying new
ones is always required.
I personally don't recall comparing the set for CPU-rtems with
the set produced by the related CPU-elf in a long time. This
could result in discussing adding or deleting variants. But I
recall in the past we have had variants which were completely
justifiable but not in the CPU-elf target for unknown reasons.
So it wouldn't be an automatic decision to do anything. Just
a discussion point on differences.
On 08/29/2011 12:46 PM, Sebastien Bourdeauducq wrote:
> On Mon, 2011-08-29 at 18:54 +0200, Ralf Corsepius wrote:
>> It's the same, what you do when using a mainstream OS - You are using
>> binaries which have been compiled by a setup to support a "main-stream"
>> target audience, which means it, is using a compromise between several
> And here the "main-stream" audience is mostly composed of... Milkymist
> users? isn't it?
>> Simply adding a mulitlib for each and every flag a compiler supports
>> simply not useful - Think about the zoo of cpu variants/instruction-set
>> variants the i?86 cpu-family consists of.
> LM32 isn't x86. We are not talking about a "zoo" of options here.
>>> This multilib patch is upstream GCC already.
>> ROTFL, implemented, submitted and commited by you!
> This does not make this modification illegitimate.
>> If gcc-4.6.1 would build (which it, as I told you several times before,
>> it doesn't
> I never questioned that fact. I actually spent a few days trying to
> resolve the issue, without much success. If someone has a solution, I
> would be happy to apply it in a timely fashion - which does represent a
> progress compared to the total lack of interest for LM32 by the other
> GCC maintainers.
>> users need to learn to live with "sub-optimality".
>> ), I likely already would have implemented custom multilibs
>> for lm32-rtems (Which is what we already do for many targets), which
>> likely would revert this change.
> You seem to have some fundamental disagreement with us trying to make a
> good and fast product...
> rtems-users mailing list
> rtems-users at rtems.org
Joel Sherrill, Ph.D. Director of Research& Development
joel.sherrill at OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
More information about the rtems-users