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

[Ferris McCormick]

This is a note relevant to generating omniORB 4.0(release) on a
sparc(mv8)-based system using g++-3.2.  The original message is perhaps
overly alarmist, since the only 'dir.mk' file I had to edit is the one in

omniORB-4.0.0/src/tool/omniidl/cxx

but if anyone else runs into this, at least here's an indication of what's
going wrong.  The problem is gcc-3.2's, not omniORB's (in my opinion).




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