On Wednesday 26 November 2008 22:01:24 David McCullough wrote:
> Jivin Mike Frysinger lays it down ...
>
> > 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
>
> Sounds ok, default of off would make sense.
>
> Here is an approach we discussed years ago:
>
> http://mailman.uclinux.org/pipermail/uclinux-dev/2003-May/016805.html
>
> also includes some more info on the problems from back then if anyone
> really want's the history ;-)
>
> Still, better to let the compiler do it's thing it's way now that the
> issues appear to have been worked out,that seems like more effort than we want to expend, and it seems prone to errors itself. i dont like to introduce solutions that are prone to false positives which is the gut feeling i get with that thread. one last question ... can i get the configure based linker script changes merged first ? or should i just write another thing here like we do with seding the script on the fly ? -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ 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
