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

[William A. Hoffman]

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