This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: libsupc++.a
- From: Martin Buck <martin dot buck at ascom dot ch>
- To: "Koeller, T." <Thomas dot Koeller at baslerweb dot com>, ecos-discuss at sources dot redhat dot com
- Date: Thu, 20 Jun 2002 09:43:00 +0200
- Subject: [ECOS] Re: libsupc++.a
- Organization: Ascom Systec AG
- References: <850597605E79D21182830008C7A4B9CF1EB423C9@COMM1>
"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