Re: libsupc++.a

[Martin Buck <martin dot buck at ascom dot ch>]

"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