Re: [ECOS] Linkerscript -- C++ new/delete functions requirement

["David Marqvar (DAM)" <dam at tt dot dk>]

Hi,

> > 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
eCos
> > 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
made
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.
synth.ld)
> > - 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
exist
> > 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
> start.

Ok. What I expected.

> > Further more the EXTRAS could just be defined in a standard manner with
a
> > more conventional name, not by the current "hack":
> > $(CC) -E -P -Wp,-MD,target.tmp -DEXTRAS=1 -xc $(INCLUDE_PATH)
$(CFLAGS) -o
> > $@ $<
>
> 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.

/David Marqvar
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