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

Tue Jun 7 11:55:18 EDT 2005

Simple solution:

f2c.h is only included in netlib files and some FEM files.

I added :
#define real f2cReal
#define complex f2cComplex

to f2c.h

and everything is building. I got through vnl and FEM anyway. I'll keep building. This works because the FEM guys include f2c.h last. The netlib guys don't include any conflicting stuff anyway.

I probably should do the #define's only for gcc2.95?

I'll keep you all posted.

Bill

-----Original Message-----
From: insight-developers-bounces+lorensen=crd.ge.com at itk.org
[mailto:insight-developers-bounces+lorensen=crd.ge.com at itk.org]On Behalf
Of Lorensen, William E (Research)
Sent: Tuesday, June 07, 2005 11:03 AM
To: William A. Hoffman; Luis Ibanez
Cc: Brad King; Insight Developers List
Subject: RE: [Insight-developers] RE: Complex vs f2c.h,"real" symbol
conflicts in gcc 2.95

Jim and I also talked about that alternative. It really is best if we can use std::complex. I just dn't know the best way to go about it. If the magic only affected this one older compiler, then I guess it would be OK.

-----Original Message-----
From: William A. Hoffman [mailto:billlist at nycap.rr.com]
Sent: Tuesday, June 07, 2005 10:15 AM
To: Lorensen, William E (Research); Luis Ibanez
Cc: Brad King; Insight Developers List
Subject: Re: [Insight-developers] RE: Complex vs f2c.h, "real" symbol
conflicts in gcc 2.95

Is #4 really the right way?   Seems like we want to use the c++ type complex,
much like we use std::vector we want std::complex.   We use std::vector all over
the place in ITK, and itk::Vector is a different thing, not just a thin wrapper
on std::vector.  Maybe the answer is to create sort of an itk version of vcl_complex,
that goes by std::complex and is only used for this compiler.  Maybe a simple
include file that does a namespace std { #include <complex> }  and make sure
that file comes first in the include path. 

-Bill

At 10:00 AM 6/7/2005, Lorensen, William E (Research) wrote:
>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
>>>
>>>
>> 
>> 
>> 
>> 
>> 
>> 
>
>
>
>_______________________________________________
>Insight-developers mailing list
>Insight-developers at itk.org
>http://www.itk.org/mailman/listinfo/insight-developers 

_______________________________________________
Insight-developers mailing list
Insight-developers at itk.org
http://www.itk.org/mailman/listinfo/insight-developers