From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21650 invoked by alias); 19 Jun 2002 14:56:26 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 21566 invoked from network); 19 Jun 2002 14:56:20 -0000 Received: from unknown (HELO proxy.baslerweb.com) (145.253.187.130) by sources.redhat.com with SMTP; 19 Jun 2002 14:56:20 -0000 Received: from comm1.baslerweb.com ([172.16.13.2]) by proxy.baslerweb.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Wed, 19 Jun 2002 16:55:44 +0200 Received: by COMM1 with Internet Mail Service (5.5.2448.0) id ; Wed, 19 Jun 2002 16:52:46 +0200 Message-ID: <850597605E79D21182830008C7A4B9CF1EB423C9@COMM1> From: "Koeller, T." To: 'Martin Buck' Cc: ecos-patches@sources.redhat.com, "'ecos-discuss@sources.redhat.com'" Date: Wed, 19 Jun 2002 07:56:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: [ECOS] RE: libsupc++.a X-SW-Source: 2002-06/txt/msg00325.txt.bz2 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