From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6562 invoked by alias); 15 Jul 2002 16:41:45 -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 6550 invoked from network); 15 Jul 2002 16:41:44 -0000 Received: from unknown (HELO proxy.baslerweb.com) (145.253.187.130) by sources.redhat.com with SMTP; 15 Jul 2002 16:41:44 -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 for ; Mon, 15 Jul 2002 18:41:00 +0200 Received: by COMM1 with Internet Mail Service (5.5.2448.0) id <34VTG3RN>; Mon, 15 Jul 2002 18:41:40 +0200 Message-ID: <850597605E79D21182830008C7A4B9CF1EB423FA@COMM1> From: "Koeller, T." To: ecos-discuss@sources.redhat.com Date: Mon, 15 Jul 2002 09:41:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [ECOS] #include in mqueue.cxx X-SW-Source: 2002-07/txt/msg00217.txt.bz2 I once suggested to include libsupc++ in the eCos repository, and I even submitted a patch to the ecos patches mailing list (it did not contain 'new', though). There is a discussion thread about this topic here on this ML. Thomas > -----Original Message----- > From: Jones, Michael [mailto:Michael.Jones@distefora-protec.de] > Sent: Monday, July 15, 2002 4:58 PM > To: Martin Buck; ecos-discuss@sources.redhat.com > Subject: AW: [ECOS] #include in mqueue.cxx >=20 >=20 >=20 > Hello! >=20 > Thanks for you response! >=20 > You are suggesting to install "libsupc++" - OK, but where to=20 > (and how)? And how do I tell the compiler where to find it? >=20 > And again why is it not part of the eCos repository?? The=20 > idea of such is to provide a working environment - I can=20 > hardly imagine that it relies on components that "maybe"=20 > exist on the build system. Or if yes, it should be documented=20 > somewhere... >=20 > As to your last two comments; I have at length considered the=20 > need for this construction and as bad style the usage is that=20 > we find in e.g. in kapi.cxx (yes - not nice is it?) the=20 > question is if somebody did it for a reason in the first=20 > place - like not having to rely on the new header? >=20 > Yet, as ever my primary target id to actually build a working=20 > app with eCos - and that is currently prohibited with this=20 > error (and I don't) seem to be the only. I will take whatever=20 > works in the long run, so I will be more then thankful for=20 > any advice that gets me there... >=20 > Regards, > Michael >=20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: Martin Buck [mailto:martin.buck@ascom.ch] > > Gesendet: Montag, 15. Juli 2002 14:31 > > An: ecos-discuss@sources.redhat.com > > Betreff: Re: [ECOS] #include in mqueue.cxx > >=20 > >=20 > > "Jones, Michael" wrote: > > > I have tried the verious enviroment setting to make the=20 > > compliler search a include path containing a "new" header.=20 > > But so far without success. > >=20 > > You have to install libsupc++ as well - it provides the basic C++ > > infrastructure and is a part of that. > >=20 > > > Also, I am not quite sure if I agree with the statement=20 > > that the "new" header belongs to the compiler and therefore=20 > > can be used. > > > Afterall, the library has to "backup" the headerfiles - And=20 > > the "new" header is based on a library that is not being=20 > > incuded in the final build... > >=20 > > But it should. gcc 3.x for C++ without libsupc++ is=20 > something like gcc > > for C without libgcc - a few things might work, but you=20 > won't get very > > far. > >=20 > > > And as mqueue.cxx seems to be the only file that requires=20 > > the "new" header - why does it require it? Why not change=20 > > mqueue.cxx so that is does not require a header that no other=20 > > files requires?? > >=20 > > Have you considered that no other file might need that=20 > functionality, > > but because it's ISO C++, it's perfectly reasonable to use=20 > if it *is* > > needed? > >=20 > > While we're at it, some other files actually need that functionality > > (placement operator new, e.g. in kapi.cxx), but they define=20 > their own > > operator new instead. According to ISO C++ 18.4.1.3 clause 1 this is > > illegal. Comments? > >=20 > > Martin > >=20 > > --=20 > > Before posting, please read the FAQ:=20 > > http://sources.redhat.com/fom/ecos > > and search the list archive:=20 > http://sources.redhat.com/ml/ecos-discuss > >=20 > >=20 >=20 > --=20 > Before posting, please read the FAQ:=20 > http://sources.redhat.com/fom/ecos > and search the list archive: http://sources.redhat.com/ml/ecos-discuss > -----------------------------------------------=20 Thomas Koeller, Software Development=20 Basler Vision Technologies=20 An der Strusbek 60-62=20 22926 Ahrensburg=20 Germany=20 Tel +49 (4102) 463-390=20 Fax +49 (4102) 463-46390 mailto:Thomas.Koeller@baslerweb.com=20 http://www.baslerweb.com=20 -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss