This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: libsupc++.a


"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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]