Bug #583

Linking fails when compiling

Added by drhex - over 8 years ago. Updated over 8 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:Andreas Huggel% Done:

100%

Category:build
Target version:0.18

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

#1 Updated by drhex - over 8 years ago

exiv2-0.17.1 compiled and linked fine on the same system

#2 Updated by Andreas Huggel over 8 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

#3 Updated by Andreas Huggel over 8 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.

#4 Updated by Andreas Huggel over 8 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?

#5 Updated by drhex - over 8 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!

#6 Updated by Andreas Huggel over 8 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.

#7 Updated by drhex - over 8 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?

#8 Updated by Andreas Huggel over 8 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.

#11 Updated by Andreas Huggel over 8 years ago

  • % Done changed from 0 to 100

#12 Updated by Andreas Huggel over 8 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF

Redmine Appliance - Powered by TurnKey Linux