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]

AW: #include <new> in mqueue.cxx


OK, so I have downloaded, built and installed newlib... 

done a build as below - no change...

OK, so I copy libgloss and newlib into the src/gcc-3.0.4/gcc directory and rebuild gcc with "--with-newlib"...

done a build as below - no change...


../ecosconfig new pc net
../econconfig tree
make

...
/ecos-c/cygwin/ecos/packages/compat/posix/current/src/mqueue.cxx:73:48: new: No such file or directory

I have searched the mail archives and have not found anything that changed anything...

Guess I will have to ask if anybody out there knows a walkthrough through this...

Regards,
Michael



> -----Ursprüngliche Nachricht-----
> Von: Martin Buck [mailto:martin.buck@ascom.ch]
> Gesendet: Montag, 15. Juli 2002 17:41
> An: ecos-discuss@sources.redhat.com
> Betreff: Re: [ECOS] #include <new> in mqueue.cxx
> 
> 
> "Jones, Michael" wrote:
> > You are suggesting to install "libsupc++" - OK, but where 
> to (and how)? 
> 
> This has been discussed quite a few times on this list, e.g. here:
> http://sources.redhat.com/ml/ecos-discuss/2001-09/msg00215.html
> 
> Is the list archive and its serach engine some kind of secret 
> that only
> I know? ;-)
> 
> > And how do I tell the compiler where to find it?
> 
> It's part of the compiler, so it will know where to find it. The eCos
> linker scripts will link it in automatically if they detect 
> that you're
> using gcc 3.x (at least the one for ARM, which is the only one I'm
> using).
> 
> > And again why is it not part of the eCos repository?? The 
> idea of such is to provide a working environment - I can 
> hardly imagine that it relies on components that "maybe" 
> exist on the build system. Or if yes, it should be documented 
> somewhere...
> 
> As I said, it's part of the compiler (and yes, eCos assumes that you
> have a compiler for the target system ;-). And it probably will be
> documented once gcc 3.x is the recommended compiler for eCos. 
> Currently
> it's gcc 2.95.3 and that one doesn't need libsupc++ (it's 
> part of libgcc
> there).
> 
> > As to your last two comments; I have at length considered 
> the need for this construction and as bad style the usage is 
> that we find in e.g. in kapi.cxx (yes - not nice is it?) the 
> question is if somebody did it for a reason in the first 
> place - like not having to rely on the new header?
> 
> I would be very surprised if that were the case. The compiler that was
> current when that part of the code was written supplied the 
> <new> header
> by default. Maybe it's the additional sanity check of the pointer. I
> guess only Jonathan will be able to tell us:
> 
> Sun Aug 16 18:15:12 1998  Jonathan Larmour  <jlarmour@cygnus.co.uk>
> [...]
>         * src/stdio/common/fopen.cxx:
>         Change to use new method of construction from above, using new
> 
> > Yet, as ever my primary target id to actually build a 
> working app with eCos - and that is currently prohibited with 
> this error (and I don't) seem to be the only. I will take 
> whatever works in the long run, so I will be more then 
> thankful for any advice that gets me there...
> 
> Have you considered using gcc 2.95.3?
> 
> 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


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