AW: [ECOS] #include <new> in mqueue.cxx

AW: [ECOS] #include <new> in mqueue.cxx

[Jones, Michael]

Hello!

Thanks for you response!

You are suggesting to install "libsupc++" - OK, but where to (and how)? And how do I tell the compiler where to find it?

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 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?

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...

Regards,
Michael


> -----Ursprüngliche 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 <new> in mqueue.cxx
> 
> 
> "Jones, Michael" wrote:
> > I have tried the verious enviroment setting to make the 
> compliler search a include path containing a "new" header. 
> But so far without success.
> 
> You have to install libsupc++ as well - it provides the basic C++
> infrastructure and <new> is a part of that.
> 
> > Also, I am not quite sure if I agree with the statement 
> that the "new" header belongs to the compiler and therefore 
> can be used.
> > Afterall, the library has to "backup" the headerfiles - And 
> the "new" header is based on a library that is not being 
> incuded in the final build...
> 
> But it should. gcc 3.x for C++ without libsupc++ is something like gcc
> for C without libgcc - a few things might work, but you won't get very
> far.
> 
> > And as mqueue.cxx seems to be the only file that requires 
> the "new" header - why does it require it? Why not change 
> mqueue.cxx so that is does not require a header that no other 
> files requires??
> 
> Have you considered that no other file might need that functionality,
> but because it's ISO C++, it's perfectly reasonable to use if it *is*
> needed?
> 
> While we're at it, some other files actually need that functionality
> (placement operator new, e.g. in kapi.cxx), but they define their own
> operator new instead. According to ISO C++ 18.4.1.3 clause 1 this is
> illegal. Comments?
> 
> 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

Re: AW: [ECOS] #include <new> in mqueue.cxx

[Martin Buck]

"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

Re: AW: [ECOS] #include <new> in mqueue.cxx

[Martin Buck]

"Jones, Michael" wrote:
> OK, so I have downloaded, built and installed newlib...

Don't build/install it manually...

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

...and put the directories in the right place: at the same level as
libstdc++-v3, i.e. into src/gcc-3.0.4.

Here's the build script I used. I don't guarantee that it works on any
system but mine. You might have to tweak the version numbers/target
directory.

#!/bin/sh

set -e -x

TARGET=arm-elf

DEST="/usr/local/pkg/ecos-tools-$TARGET"

BINUTILS_VERSION=2.12
GCC_VERSION=3.0.4
NEWLIB_VERSION=1.10.0

BINUTILS_DIR="binutils-$BINUTILS_VERSION"
GCC_DIR="gcc-$GCC_VERSION"
NEWLIB_DIR="newlib-$NEWLIB_VERSION"

umask 022

rm -fr "$BINUTILS_DIR" "$GCC_DIR" "$NEWLIB_DIR"
tar xvIf "binutils-$BINUTILS_VERSION.tar.bz2"
tar xvzf "gcc-$GCC_VERSION.tar.gz"
tar xvzf "newlib-$NEWLIB_VERSION.tar.gz"

ln -s "../$NEWLIB_DIR/newlib" "$GCC_DIR"
ln -s "../$NEWLIB_DIR/libgloss" "$GCC_DIR"

rm -fr build
mkdir -p build/binutils build/gcc

cd build/binutils
"../../$BINUTILS_DIR/configure" --target="$TARGET" --prefix="$DEST" \
    --disable-nls
make LDFLAGS=-s all install

cd ../gcc
PATH="$DEST/bin:$PATH"
"../../$GCC_DIR/configure" --target="$TARGET" --prefix="$DEST" \
    --with-gnu-as --with-gnu-ld --with-newlib --disable-nls
make LANGUAGES="c c++" LDFLAGS=-s \
    all-gcc all-target-libstdc++-v3 install-gcc
install-target-libstdc++-v3

cd ../..
rm -fr "$BINUTILS_DIR" "$GCC_DIR" "$NEWLIB_DIR" build 


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

AW: [ECOS] #include <new> in mqueue.cxx

[Jones, Michael]

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