[ECOS] Linkerscript -- C++ new/delete functions requirement
David Marqvar (DAM)
Thu May 29 03:05:00 GMT 2003
> > I am currently creating a little patch (fix IMHO) that makes it
> > configureable from configtool if the new/delete functions should betaken
> > from libsupc++.a or be provided directly in eCos.
> > This is to allow us (and others) to avoid the need for C++ libraries in
> > since we currently will not allow the use of these in our code, and
> > therefore don't like the idea of having them available at all.
> libsupc++ is only a low level C++ runtime library that supplies
> functionality that the compiler depends on. It is not the full C++
> library at all. Apart from new and delete it mostly contains support
> for exception handling, nothing more.
Ok. We do not have any c++ libraries at all. When we shifted to gcc 3.x we
simple substitudes for new / delete in our code. This code have now been
moved to the eCos code.
It seems to work - all tests _compiles_ (will try to run the tests later),
out code works.
> Given the subtle interaction between the compiler, the contents of
> this library, and the definitions in the <new> header, I would be very
> wary of trying to remove it.
Ok. Maybe we should just create the libsupc++.a if we run into any problems.
> > Currently I've only tested with synth.ld, and I'm wondering why the
> > #include <pkgconf/system.h>
> > is not placed in the top of the "master" linker script file (e.g.
> > - if it is moved up there I can just define the needed macro in system.h
> > Is there any not-so-obvious reason to this - maybe something that only
> > for a different target?
> I doubt it. That's just the way it was done. There was never anything
> in the main part of that file that needed configuration. The .ld files
> for other architectures do include system.h, and other headers, at the
Ok. What I expected.
> > Further more the EXTRAS could just be defined in a standard manner with
> > more conventional name, not by the current "hack":
> > $(CC) -E -P -Wp,-MD,target.tmp -DEXTRAS=1 -xc $(INCLUDE_PATH)
> > $@ $<
> I'm not sure I understand your point here.
I think the "special" definition of EXTRAS (-DEXTRAS=1) could have been
avoided if using the inclusion of system.h, as suggested above. To me this
backdoor to EXTRAS is closing in to an ugly hack ;-)
Thank you for the answer.
Thrane & Thrane
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss
More information about the Ecos-discuss