Jivin Mike Frysinger lays it down ...
> 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 ?
Whatever you prefer, eems like its time for the configure based linker
script.
Cheers,
Davidm
--
David McCullough, [EMAIL PROTECTED], Ph:+61 734352815
Secure Computing - SnapGear http://www.uCdot.org http://www.snapgear.com
_______________________________________________
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
