Re: [ECOS] Does GCC-3.0 break ecos-CVS?

[Bart Veer <bartv at redhat dot com>]

>>>>> "Jifl" == Jonathan Larmour <jlarmour@redhat.com> writes:

    Jifl> Richard Chan wrote:
    >> 
    >> Hi, I am trying to build the ecos tools from CVS using a GCC
    >> 3.0 on i686-linux-pc-gnu. GCC 3.0 was built with
    >> --disable-shared and --enable-shared for libstdc++. I'm using
    >> the whole libstdc++-v3 ISO compliance caboodle. I am also using
    >> binutils-2.11.2.
    >> 
    >> Here are two problems with interp.cxx:
    >> 
    >> including -I/usr/include on the command line of c++ means
    >> that c++ can't find <string.h> using #include_next
    >> FIX: don't explicitly use -I/usr/include on c++ command line?

    Jifl> Interesting that one - the problem is because we search for
    Jifl> tcl.h and include its location explicitly on the command
    Jifl> line even if it's already in the include path. I'm not sure
    Jifl> how to fix this - explicitly matching against /usr/include
    Jifl> isn't necessarily right as libcdl could be host-x-host
    Jifl> cross-compiled. Determining the system include path doesn't
    Jifl> seem to be easy. And just testing for whether an include of
    Jifl> <tcl.h> works is dubious as well because it may have been
    Jifl> overridden with --with-tcl-header or --with-tcl to select a
    Jifl> different version than the system version.

    Jifl> I think explicitly matching /usr/include is probably good
    Jifl> enough for most purposes. Bart?

I believe -I/usr/include is explicitly disallowed with gcc for any
platform that relies on fixincludes. It used to be ok on Linux because
the headers did not need fixing there, but clearly is has now been
disallowed for other reasons as well. Explicitly matching /usr/include
in the various configure.in should suffice. I am not too worried about
cross-compilation issues: cross-compilation of the eCos host tools is
pretty rare. I'll look into this when I get a chance.

Bart