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

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

[Richard Chan]

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?

isspace is undefined (line 1358) because interp.cxx doesn't include
ctype.h.
FIX: #include <ctype.h> somewhere in interp.cxx?

I'll let you all know any further problems. BTW ecos
was pulled from CVS.

Cheers!

_________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com .

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

[Jonathan Larmour]

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?

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

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

> isspace is undefined (line 1358) because interp.cxx doesn't include
> ctype.h.
> FIX: #include <ctype.h> somewhere in interp.cxx?
> 
> I'll let you all know any further problems. BTW ecos
> was pulled from CVS.

Easily fixed. Done. Ditto flags.cxx.

Thanks for the reports.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions    http://www.redhat-techworld.com/

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

[Bart Veer]

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

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

[Jonathan Larmour]

Bart Veer wrote:
> 
> 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.

Okay?

Index: configure.in
===================================================================
RCS file: /home/cvs/ecc/host/libcdl/configure.in,v
retrieving revision 1.2
diff -u -5 -p -r1.2 configure.in
--- configure.in	2000/08/18 16:43:10	1.2
+++ configure.in	2001/07/09 15:37:37
@@ -110,11 +110,15 @@ dnl This should probably be fixed in aut
 dnl but for now this suffices. It is also necessary to worry about
 dnl infra_incdir and tcl_incdir
 if test "${MSVC}" = "yes" ; then
   INCLUDES="\"-I`cygpath -w ${srcdir} | tr \\\\\\\\ /`\"
\"-I${cyg_ac_infra_incdir}\" \"-I${cyg_ac_tcl_incdir}\""
 else
-  INCLUDES="-I${cyg_ac_infra_incdir} -I${cyg_ac_tcl_incdir}"
+  if test "${cyg_ac_tcl_incdir}" = "/usr/include" ; then
+    INCLUDES="-I${cyg_ac_infra_incdir}"
+  else
+    INCLUDES="-I${cyg_ac_infra_incdir} -I${cyg_ac_tcl_incdir}"
+  fi
 fi
 AC_SUBST(INCLUDES)
 
 dnl --------------------------------------------------------------------
 AM_CONFIG_HEADER(cdlconfig.h:config.h.in)

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions    http://www.redhat-techworld.com/