Frank, This looks like if the linking of the GDAL shared library was using the static version of libstdc++ (the message "recompile with -fPIC" is for libstdc++, not GDAL...) . A bit of googling shows that this error has been encountered with various software packages.
Several tracks : 1) https://bugs.archlinux.org/task/14268 suggest to check that there is no /usr/lib/libstdc++.la around. If there's one, rename it, and try again. 2) Other links would suggest that /usr/lib/gcc/x86_64-linux-gnu/4.4.5/libstdc++.a library was incorrectly built, and not appropriate for being used by shared libraries. 3) http://code.google.com/p/staff/issues/detail?id=150 is also interesting : """ > Very strange, but why g++ tries to link libstdc++ staticaly? That was the key question. With the help of strace (my favorite tool) I figured out that g++ fell back to the static lib (/usr/lib/gcc/x86_64-linux-gnu/4.4.5/libstdc++.a) after getting an error when trying to access the shared lib (/usr/lib/gcc/x86_64-linux-gnu/4.4.5/libstdc++.so). The shared lib was a broken symlink. The link apparently broke when I upgraded libstdc++6 to 4.6.1-4 without upgrading libstdc++6-4.4-dev at the same time. Sorry to have bothered you with this... """ So perhaps start by upgrading your libstdc++6-4.4-dev package ? 4) If none of the above works and it is libtool related as the above would suggest, perhaps you could also try adding --without-libtool to your GDAL ./configure command line. The experience shows that it sometimes helps, but I'm not positive it will be the case here. > Hi, > > I try to compile gdal 1.9.0RC2 on my Debian machine > > brfr@devel:~/gdal$ uname -ra > Linux devel 2.6.32-5-amd64 #1 SMP Mon Oct 3 03:59:20 UTC 2011 x86_64 > GNU/Linux > > but make exits with an error 2. The last messages before exiting: > /usr/bin/ld: > /usr/lib/gcc/x86_64-linux-gnu/4.4.5/libstdc++.a(functexcept.o): > relocation R_X86_64_32 against `std::bad_typeid::~bad_typeid()' can not > be used when making a shared object; recompile with -fPIC > /usr/lib/gcc/x86_64-linux-gnu/4.4.5/libstdc++.a: could not read symbols: > Bad value > collect2: ld returned 1 exit status > make[1]: *** [libgdal.la] Fehler 1 > make[1]: Leaving directory `/home/brfr/gdal/gdal-1.9.0' > make: *** [check-lib] Fehler 2 > > I tried already with the fPIC flag > brfr@devel:~/gdal$ export CXXFLAGS="-fPIC" > brfr@devel:~/gdal$ ./configure --with-python --with-geos=yes --enable-debug > brfr@devel:~/gdal$ make > but without success > > > Any hints? > > Frank > > > > -- > Frank BRONIEWSKI > > METRICO s.à r.l. > géomètres > technologies d'information géographique > rue des Romains 36 > L-5433 NIEDERDONVEN > > tél.: +352 26 74 94 - 28 > fax.: +352 26 74 94 99 > http://www.metrico.lu > _______________________________________________ > gdal-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/gdal-dev > _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
