On Wed, Nov 26, 2008 at 19:29, David McCullough wrote:
> Jivin Bernd Schmidt lays it down ...
>> David McCullough wrote:
>> > Jivin Mike Frysinger lays it down ...
>> >> the default elf2flt linker script atm outputs __{C,D}TOR_{LIST,END}__
>> >> unconditionally. this can conflict with the symbols already provided
>> >> by gcc's crt{begin,end} objects. so how best to handle this ? are
>> >> these symbols really needed anymore ? or are they for ports whose gcc
>> >> doesnt provide these symbols but install relies on the C library to do
>> >> the processing or something ?
>> >
>> > On the older toolchains it used to get it wrong all the time, so we
>> > would pull the support from the toolchain and do it in the linker
>> > script. The ifo pages for ld actually show hwo to do this, don't know
>> > why they changed their minds ;-)
>>
>> That doesn't sound plausible; this is really basic compiler
>> functionality that ought to work in every release. Which versions of
>> the toolchain get it wrong, and what kinds of problems do they cause?
>
> The 2.95 elf compilers that we used to use (m68k and arm), both behaved
> differently, some didn't terminate the ctor/dtor lists correctly, and
> there were some other issues I can't remember properly anymore.
>
> If the people currently maintaining compilers want it gone it sounds
> fair to me.
if you'd really like to keep that older support there, we could have
it be a configure option that would default to off ... not sure if we
want to attempt to detect dynamically whether the toolchain is broken
...
-mike
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
