[omniORB] g++-3.2 -O -I/usr/include -- Can't #include <math.h> (fwd)

[Ferris McCormick]

(Repost for comment of an incompatibility between the omniORB-4.0.0
build process and gcc/g++ release 3.2)

I am led to believe that it is both known and intentional that (on sparc,
at least), with g++ release 3.2,
  g++ -O -I/usr/include
can lead to incorrect compiles. This can result in the error reported
below when building omniORB 4.0.0 (release) on sparc linux systems on 
which python is installed in /usr.  If you modify the affected 'dir.mk'
files (such as in src/tool/omniidl/cxx) not to add what resolves
-I/usr/include (from PYINCDIR) to DIR_CPPFLAGS, then omniORB builds
without further incident and seems to run fine.

  I am reposting this note because I was not sure until now whether I
was seeing something local to my installation or not.  Apparently, not,
and omniORB is having problems with a known incompatibility between
g++-2.95.3 and g++-3.2.

Regards,

--
Ferris McCormick (P44646, MI) <fmccor@inforead.com>
Phone: (703) 392-0303
Fax:   (703) 392-0401


---------- Forwarded message ----------
Date: Wed, 2 Oct 2002 19:58:48 +0000 (UTC)
From: Ferris McCormick <fmccor@inforead.com>
To: gentoo sparc list <gentoo-sparc@gentoo.org>
Cc: omniorb-list@omniorb-support.com
Subject: [gentoo-sparc] g++-3.2 -O -I/usr/include -- Can't #include <math.h>

I have submitted an error (against g++ 3.2) on this, but since I
found it with omniORB 4.0(release) running gentoo-sparc 1.4-rc1,
I'll pass it on for comments:

System is Gentoo 1.4-rc1 on a sparc64 (Ultra2), gcc/g++-3.2.

Suppose your source file (c.cc, say) is

#include <math.h>

and nothing else.  If you compile it with
g++ -O -I/usr/include c.cc

Then, the compiler gives you this nonsense:
============================================================================
cc1plus: warning: changing search order for system directory 
"/usr/include"
cc1plus: warning:   as it has already been specified as a non-system 
directory
In file included from /usr/include/math.h:350,
                 from c.cc:2:
/usr/include/bits/mathinline.h:216: declaration of `double fdim(double, 
double)
   ' throws different exceptions
/usr/include/bits/mathcalls.h:313: than previous declaration `double 
   fdim(double, double) throw ()'
/usr/include/bits/mathinline.h:223: declaration of `float fdimf(float, 
float)' 
   throws different exceptions
/usr/include/bits/mathcalls.h:313: than previous declaration `float 
   fdimf(float, float) throw ()'
=============================================================================

I.e., if the user for some reason forces the '-I/usr/include' to the front 
of the normal search path given below---

=============================================================================
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/g++-v32
 /usr/include/g++-v32/sparc-unknown-linux-gnu
 /usr/include/g++-v32/backward
 /usr/local/include
 /usr/lib/gcc-lib/sparc-unknown-linux-gnu/3.2/include
 /usr/sparc-unknown-linux-gnu/include
 /usr/include
=============================================================================

then "g++ -O" can't handle "#include <math.h>"

Why include omniORB list?  Python lives in '/usr'; omniORB needs Python
include files, and it automatically figures out that they are in 
'/usr/include'.  I am manually removing the "-I/usr/include"s as I find
them, but that's a pretty poor solution to what (I think) should be no
error in the first place.

Has anyone else seen this?

Sorry for the rant;
Regards,

--
Ferris McCormick (P44646, MI) <fmccor@inforead.com>
Phone: (703) 392-0303
Fax:   (703) 392-0401


_______________________________________________
gentoo-sparc mailing list
gentoo-sparc@gentoo.org
http://lists.gentoo.org/mailman/listinfo/gentoo-sparc