[ECOS] RE: libsupc++.a

["Koeller, T." <Thomas dot Koeller at baslerweb dot com>]

Martin,

I never quite understood how this (using newlib) is supposed to work,
and that's why I never tried it. If I use newlib to generate the compiler
support libraries like libsupc++, doesn't this mean I will have to link
all my applications with newlib? And if I do, won't there be clashes between
newlib and the ecos-provided ISO C library functions? Am I wrong to assume
that I cannot use just the newlib headers without using the actual library?

I am cc'ing this to the ecos-discuss mailing list, as this is a question of
general interest. Hope that you, or anyone else, can shed some more light on
this topic that has puzzled me for long.

tk


> -----Original Message-----
> From: Martin Buck [mailto:martin.buck@ascom.ch]
> Sent: Monday, June 17, 2002 4:49 PM
> To: ecos-patches@sources.redhat.com; Koeller, T.
> Subject: Re: libsupc++.a
> 
> 
> "Koeller, T." wrote:
> > You can only build a cross gcc for ecos by doing a 'make 
> all-gcc'. This
> > does not build libsupc++.a, a 'make all' would be required 
> to achieve
> > this, which is impossible to do as there is no target C 
> library at this
> > point.
> 
> You don't need "make all", "make all-gcc all-target-libstdc++-v3" is
> sufficient. For this to work, you have to compile with newlib (and you
> have to #define _GLIBCPP_HAVE_UNISTD_H when compiling
> libstdc++-v3/libsupc++/pure.cc - the configure script seems 
> to get this
> one wrong in recent gccs). BTW, compiling with newlib is what RedHat
> suggests[1] and is what is done in toolchains they ship to their
> customers.
> 
> [1] http://sources.redhat.com/ml/ecos-discuss/2001-10/msg00274.html
> 
> > And then, functions in libsupc++.a should use the mechanisms
> > provided by the target system directly for efficiency. Take 
> as an example
> > the one function I implemented, __cxa_pure_virtual(). Its 
> purpose is to
> > abort a program if it happens to call a pure virtual 
> function. The version
> > that comes with gcc (or, more precisely, with libstdc++) 
> does this by
> > calling
> > std::terminate(), so it requires the standard C++ library.
> 
> std::terminate is part of libsupc++ as well. AFAIK, there are no
> dependencies on libstdc++ in libsupc++. If there were any, I 
> would call
> this a bug.
> 
> > For an embedded
> > system it is clearly preferable to map this simple 
> funtionality directly to
> > the ecos-provided mechanisms, CYG_FAIL() in this case.
> > 
> > Providing ecos-specific implementations for these functions 
> also has the
> > additional benefit of being able to add ecos-style 
> asertions, tracing and
> > so on.
> 
> That's right, but it has the huge drawback of messing around with an
> internal compiler-API that can change without warning. Plus, 
> you'll have
> to implement a lot of stuff from libsupc++ to be more-or-less ISO C++
> compliant.
> 
> Martin
> 

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss