Bug #583
Linking fails when compiling
100%
Description
I downloaded exiv2-0.18-pre2 (.tar.gz from website) to an Ubuntu 7.10 system with gcc version 4.1.3 20070929 (prerelease). Then ran
./configure --prefix=/usr
make
The files compile Ok (warnings about unused variables), but libtool seems to have problems:
../libtool --mode=link g++ -L../xmpsdk/src -o libexiv2.la basicio.lo bmpimage.lo canonmn.lo convert.lo cr2image.lo crwimage.lo datasets.lo error.lo exif.lo futils.lo fujimn.lo gifimage.lo image.lo iptc.lo jp2image.lo jpgimage.lo makernote.lo metadatum.lo minoltamn.lo mrwimage.lo nikonmn.lo olympusmn.lo orfimage.lo panasonicmn.lo pngimage.lo pngchunk.lo preview.lo properties.lo psdimage.lo rafimage.lo sigmamn.lo pentaxmn.lo sonymn.lo tags.lo tgaimage.lo tiffcomposite.lo tiffimage.lo tiffvisitor.lo types.lo value.lo version.lo xmp.lo xmpsidecar.lo -rpath /usr/lib -version-info 6:0:1 -lz -lm -lexpat -lxmpsdk
g++ -shared -nostdlib /usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/crti.o /usr/lib/gcc/i486-linux-gnu/4.1.3/crtbeginS.o .libs/basicio.o .libs/bmpimage.o .libs/canonmn.o .libs/convert.o .libs/cr2image.o .libs/crwimage.o .libs/datasets.o .libs/error.o .libs/exif.o .libs/futils.o .libs/fujimn.o .libs/gifimage.o .libs/image.o .libs/iptc.o .libs/jp2image.o .libs/jpgimage.o .libs/makernote.o .libs/metadatum.o .libs/minoltamn.o .libs/mrwimage.o .libs/nikonmn.o .libs/olympusmn.o .libs/orfimage.o .libs/panasonicmn.o .libs/pngimage.o .libs/pngchunk.o .libs/preview.o .libs/properties.o .libs/psdimage.o .libs/rafimage.o .libs/sigmamn.o .libs/pentaxmn.o .libs/sonymn.o .libs/tags.o .libs/tgaimage.o .libs/tiffcomposite.o .libs/tiffimage.o .libs/tiffvisitor.o .libs/types.o .libs/value.o .libs/version.o .libs/xmp.o .libs/xmpsidecar.o -Wl,--whole-archive /usr/src/exiv2-0.18-pre2/xmpsdk/src/.libs/libxmpsdk.a -Wl,--no-whole-archive -L/usr/src/exiv2-0.18-pre2/xmpsdk/src -lz /usr/lib/libexpat.so -L/usr/lib/gcc/i486-linux-gnu/4.1.3 -L/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib -L/lib/../lib -L/usr/lib/../lib -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/i486-linux-gnu/4.1.3/crtendS.o /usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/crtn.o -Wl,-soname -Wl,libexiv2.so.5 -o .libs/libexiv2.so.5.1.0
.libs/basicio.o: In function `Exiv2::FileIo::transfer(Exiv2::BasicIo&)':
basicio.cpp:(.text+0x130f): undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()'
basicio.cpp:(.text+0x13e2): undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()'
basicio.cpp:(.text+0x1439): undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()'
basicio.cpp:(.text+0x1501): undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()'
basicio.cpp:(.text+0x15eb): undefined reference to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()'
.libs/basicio.o:basicio.cpp:(.text+0x15f9): more undefined references to `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()' follow
History
Updated by Andreas Huggel almost 13 years ago
This may be a related issue:
http://www.ogre3d.org/phpBB2/viewtopic.php?p=303919&sid=ce193664e1d3d7c4af509e6f4e2718c6
in particular "the old issue with visibility flags on Ubuntu for gcc < 4.2" - that's new in 0.18-pre2 compared to 0.17.1
Updated by Andreas Huggel almost 13 years ago
Another similar looking one is here:
http://groups.google.com/group/python-ogre-developers/browse_thread/thread/ad14666d6784d6cc
Do you have "patch" installed? if not, pls install and re-try.
Updated by Andreas Huggel almost 13 years ago
To check if the visibility flags are causing the problem, can you please do this:
- Start with a newly unpacked 0.18-pre2 directory tree
- Run ./configure as usual
- In config/config.mk remove "-fvisibility=hidden fvisibility-inlines-hidden" from the line "CXXFLAGS = ..." In src/exv_config.h, remove the line "#define EXV_HAVE_GXXCLASSVISIBILITY"
- make
Does it link now?
Updated by drhex - almost 13 years ago
"patch" was already installed.
There was no file called exv_config.h in the src directory after unpacking and running configure.
However, removing the -fvisibility arguments from config/config.mk did the trick and libtool now succeded. Thank you!
Updated by Andreas Huggel almost 13 years ago
There was no file called exv_config.h in the src directory after unpacking and running configure.
Yes, of course, I'm sorry. This should have read
- In config/config.h, remove the line "#define HAVE_GXXCLASSVISIBILITY"
(This file is copied to the source directory, renamed to exv_conf.h and the defines prepended with EXV_ only when make is run.)
I'll fix this with an option to configure to disable the visibility stuff.
Thanks for reporting this.
Updated by drhex - almost 13 years ago
Would it not be possible to detect that a system has this problem in e.g. configure and then automatically adjust to that?
(i.e "remembering to enable the visibiliy option to configure" seems to be as complex for the end user as "remembering to remove -fvisibility from config/config.mk")
Well, an option is certainly more elegant and perhaps is it difficult to detect the problem before compiling?
Updated by Andreas Huggel almost 13 years ago
What I meant is this:
+ By default, configure will automatically detect if the compiler supports the visibility feature (just like today).
+ In addition, there will be a new configure option (eg, "--disable-gxxclassvisibility") to manually turn it off. So that in cases where the auto-detection gets it wrong for some reason, it can be disabled anyway.
Of course if the configure check is flawed I will need to fix it. But the current test is actually quite specific: It checks if the C++ compiler supports the option "-fvisibility-inlines-hidden", and g++ does so since version 4. I have no idea what's wrong with the Ubuntu 7.10 version of g++ 4.1 but essentially, those who use a broken compiler will have a choice of getting one that works or use that little workaround.
Anyway, I would always only be able to investigate why it doesn't work in a particular case and add that exception to the configure logic after the fact, i.e., after someone hit it and got stuck and took the trouble to report it.