[Insight-users] Debian/Linux linking

[Luis Ibanez]

Hi Neil,

We just build ITK in a brand new Debian linux system without any trouble.

It seems that your system is not configured correctly. It is not a good 
idea to
dare building ITK with a poorly installed compiler.

Each version of gcc should be able to find its corresponding libstdc++
when the compiler is configured correctly.

Debian is quite flexible in installation, I would suggest you to 
reinstall the
compiler and verify that you can write simple programs using fstreams
before you move to build a demanding system like ITK.

Your current installation will probably have trouble with code
like the following:

#include <fstream>
int main()
{
  ofstream ff("test");
  ff << "Hello World" << std::endl;
  ff.close();
  return 0;
}

-----

If your system administrator is not cooperative,  you can always build
gcc3.2 in your home directory. The process will take you about 1 hour
and will save you a lot of trouble and unnecessary suffering.

Instructions about how to build gcc3.2 have been posted several times
in the list.


   Regards,


     Luis


-------------------------------------------------
Neil Killeen wrote:

>Hi
>
>I have been attempting to build ITK on a Debian Linux system.
>
>I get a linker error (below) when building the Testing directory. It is
>related to streams.   This is a libstdc++ linking issue.  In our system
>we have gone to a lot of trouble because different versions of gcc require
>different versions of libstdc++.    Here are some notes
>from our system on handling this issue:
>
>% more /usr/local/gnu/lib/libstdc++.README
>
>"g++ 2.95.3 requires libstdc++.so.2.10.0, but
>g++ 3.1.1  requires libstdc++.so.4.0.1.
>
>Do not create symlinks for libstdc++.so or libstdc++.a in this directory
>(/usr/local/gnu/lib) because apparently the GNU compilers look here for
>libstdc++.{a,so} before the version-specific directory,
>/usr/local/gnu/lib/gcc-lib/<platform>/<version>/.
>
>Hence, symlinks have been created in the version-specific directories
>so that each version of g++ finds the correct version of
>libstdc++.{a,so}."
>
>
>Now, I have checked via the g++ verbose switch, that the correct version
>of libstdc++ is being picked up.  What seems to be happening is that
>some symbols have preprended underscores on them, and these do not
>exist in the libstdc++
>
>
>The actual linker error (one example) is
>
>
>g++-3.1.1 -rdynamic -Wno-deprecated -ftemplate-depth-50 itkIOTests.o
>itkConvertBufferTest.o itkDicomImageIOTest.o itkMetaImageIOTest.o
>itkPNGImageIOTest.o itkVOLImageIOTest.o itkVTKImageIOTest.o
>itkRawImageIOTest.o itkRawImageIOTest2.o itkRawImageIOTest3.o
>itkRawImageIOTest4.o  -L/nfs/mid/NKILLEEN/itk/binary/linux/bin -lpthread
>-ldl -lVXLNumerics -lm -lITKIO -litkpng -litkzlib -lITKMetaIO -lITKCommon
>-lVXLNumerics -lm -lpthread -ldl
>-Wl,-rpath,/nfs/mid/NKILLEEN/itk/binary/linux/bin  -o
>/nfs/mid/NKILLEEN/itk/binary/linux/bin/itkIOTests
>/nfs/mid/NKILLEEN/itk/binary/linux/bin/libITKIO.a(itkDicomImageIO.o): In function `itk::DicomImageIO::CheckTagTable(std::basic_ifstream<char,
>std::char_traits<char> >&, std::list<Bal, std::allocator<Bal> >&) const':
>itkDicomImageIO.o(.text+0x5e6): undefined reference to `std::basic_istream<char, std::char_traints<char>
>  
>
>>::seekg(std::fpos<__mbstate_t>)'
>>    
>>
>
>
>
>Now of these symbols, look at the last line
>
> `std::basic_istream<char, std::char_traints<char> >::seekg(std::fpos<__mbstate_t>)'
>
>you see the __mbstate_t variable in the call to seekg.
>
>Now, in our libstdc++ library we see
>
>% nm libstdc++.so.4.0.1 | c++filt | more
>
>00049d20 W std::basic_istream<char, std::char_traints<char> >::seekg(std::fpos<mbstate_t>)
>
>
>you can see that there are no leading underscores...  I think this is the
>problem but don't know how to resolve it.
>
>Any thoughts on why this naming mismatch is occuring ?
>
>thanks
>Neil
>
>_______________________________________________
>Insight-users mailing list
>Insight-users@public.kitware.com
>http://public.kitware.com/mailman/listinfo/insight-users
>
>  
>