RE: [ECOS] RE: libsupc++.a

RE: [ECOS] RE: libsupc++.a

[Woller, Thomas]

I am looking at this subject right now, and have the same
questions.  Basically, I am attempting to port ACE (minus TAO)
over to eCos but am having problems resolving include file
dependencies (include_next in std_cstddef for one).  I am
thinking that i should/can use the newlib provided include files
but do not want to link with the newlib libraries.  looking for
information also... thanks
Tom Woller
Cirrus Logic Corp
tom.woller@cirrus.com

-----Original Message-----
From: Koeller, T. [mailto:Thomas.Koeller@baslerweb.com]
Sent: Wednesday, June 19, 2002 9:53 AM
To: 'Martin Buck'
Cc: ecos-patches@sources.redhat.com;
'ecos-discuss@sources.redhat.com'
Subject: [ECOS] RE: libsupc++.a


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

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

[ECOS] Re: libsupc++.a

[Martin Buck]

"Koeller, T." wrote:
> I never quite understood how this (using newlib) is supposed to work,
> and that's why I never tried it.

To be honest, neither do I, but I somehow managed to get it working. :-)

> 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?

In theory, yes. But basically, you just use newlib's header files to
provide declarations for the few libc functions libsupc++ wants to use.
Newlib (in contrast to GNU libc, for example, which uses some magic
inline code) seems to be a more-or-less straightforward libc
implementation, so you end up with with a few undefined symbols in
libsupc++ that happen to be provided by the eCos libc in a compatible
way, so you can link the whole stuff together and it just works. This
wouldn't work if libsupc++ would to things like "sizeof(FILE)" which
would most likely give different results with newlib/eCos libc, but I
guess the libsupc++ authors knew about this and took it into account.

The correct solution of course would be to compile libsupc++ against the
header files of the libc you want to link it against, but then the
libsupc++ authors would have to deal with all the possible libc's out
there. And as long as the interface between libsupc++ and libc is lean
enough (libsupc++ currently only needs malloc(), free(), memset() and
write()), I guess we can live with the current "good enough" solution.

Oh, and as I mentioned in my previous e-mail: The configure scripts in
my current toolchain (which seems to be a close relative of gcc 3.1)
seem to get a bit confused by newlib. So you might have to add a
"#define _GLIBCPP_HAVE_UNISTD_H" to the beginning
libstdc++-v3/libsupc++/pure.cc if you get undefined symbols when linking
applications using virtual functions. Apart from this, everything else
works automagically if you unpack newlib to the subdirectory "newlib" in
the toolchain sources and configure the toolchain with "--with-newlib".
As I said, this is exactly the way toolchains provided by RedHat to
their customers are configured.

HTH,
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

[ECOS] RE: libsupc++.a

[Koeller, T.]

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