[Insight-developers] RE: Complex vs f2c.h, "real" symbol conflicts in gcc 2.95

[Lorensen, William E (Research)]

Dropping 2.95 is not a good option.

I prefer #4 over the rest (so does Jim).


-----Original Message-----
From: Luis Ibanez [mailto:luis.ibanez at kitware.com]
Sent: Tuesday, June 07, 2005 9:35 AM
To: Lorensen, William E (Research)
Cc: Brad King; Insight Developers List
Subject: Complex vs f2c.h, "real" symbol conflicts in gcc 2.95



Bill,

Brad just found the reason why the "real" declarations are
colliding in GCC 2.95.

The problem seems to be related to the lack of "std" namespace
on the declarations of complex in the Gcc 2.95 headers.



We just created a bug entry for this issue.  BUG: 1908.
http://www.itk.org/Bug/bug.php?op=show&bugid=1908&pos=0




Possible solutions are:

   1) drop support for gcc 2.95   :-)

   2) replace <complex> with vcl_complex

   3) edit all f2c.h code and replace the 'real'
      with a name less prone to collision.

   4) create a native itk::Complex and do the right thing


Option (1) may not be a good idea, since we will be busy
enough dropping support for Visual Studio 6.0.

Option (3) requires to change a lot of lines of code, and
then wait for the next occurrence of a "real" symbol to
collide with the faulty headers of Gcc 2.95.


Brad is leaning towards option (2).

I'm leaning towards option (4) which can in fact take
advantage of (2) because we could make itk::Complex
derive from vcl_complex.  The argument in favor of (4)
is that we should avoid exposing VNL in the API for ITK.



We have some urgency for solving this issue because we
have 3 examples related to the use of complex numbers
in the Software Guide and the PDF is going to be cut
this week.


Any suggestions are welcome,


     Thanks


       Luis



----------------------------------------
Lorensen, William E (Research) wrote:

> I think the proper include files are being used. I believe that g++-3 has nothing to do with g++3.3. There is also a gcc2.8 on that machine. The compiler knows at install time which include to use. Like I said earlier we have been using the same compiler since the beginnings of itk.
> 
> Bill
> 
> -----Original Message-----
> From: Luis Ibanez [mailto:luis.ibanez at kitware.com]
> Sent: Monday, June 06, 2005 10:12 AM
> To: Lorensen, William E (Research)
> Subject: Re: Wednesday changes
> 
> 
> 
> Bill,
> 
> I'm looking at the problems in the Suns, and got the feeling that
> the configurartion in those machines is mixing headers from GCC 3.3
> with the compilation from GCC 2.95.
> 
> At least that's what the following directory from the error message
> makes me think:
> 
> /usr/tmp/local/lib/gcc-lib/sparc-sun-solaris2.5.1/2.95/../../../../include/g++-3/std/complext.h
> 
> 
> As you see, it seems to be going inside the directory for gcc 2.95
> and then going up four levels in order to find the definition of
> complex in g++-3.
> 
> Are these machines configured to use GCC 2.95 ? or GCC 3.3 ?
> 
> Their configuration (as far as I can see from the message
> in the Dashboard) is using:
> 
> CMAKE_C_COMPILER = /usr/tmp/local/bin/gcc
> CMAKE_CXX_COMPILER = c++
> 
> It will probably be a good idea to have a more explicit selection of
> the compiler. Somthing like
> 
> CMAKE_C_COMPILER = /usr/tmp/local/bin/gcc-3.3
> CMAKE_CXX_COMPILER = /usr/tmp/local/bin/g++-3.3
> 
> 
> BTW, the error message indicates that two declarations of "real"
> are conflicting. There is a "real" type being declared in f2c.h
> for the FORTRAN functions used in FEM, and there is the "real"
> function defined in complex.h for extracting the real part of
> a complex number.
> 
> 
> 
> 
>     Luis
> 
> 
> 
> 
> ------------------------------------------
> Lorensen, William E (Research) wrote:
> 
>>Luis,
>>The Sun gcc builds (esopus,calbe) did not like your complex changes.
>>
>>Bill
>>
>>
> 
> 
> 
> 
> 
>