Bug #551
Mac OS X 10.4.11 build failure
0%
Description
On both Mac OS X 10.4.11 PPC and Intel build I get the following failure quoted text from PPC):
g++ -dynamiclib -single_module -flat_namespace -undefined suppress -o .libs/libexiv2.4.0.0.dylib .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/ifd.o .libs/image.o .libs/iptc.o .libs/jp2image.o .libs/jpgimage.o .libs/makernote.o .libs/makernote2.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/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/tiffparser.o .libs/tiffvisitor.o .libs/types.o .libs/value.o .libs/version.o .libs/properties.o .libs/xmp.o .libs/xmpsidecar.o -all_load /tmp/exiv2-0.17/xmpsdk/src/.libs/libxmpsdk.a -L/usr/local/lib -L/tmp/exiv2-0.17/xmpsdk/src /usr/local/lib/libintl.dylib -lc /usr/local/lib/libiconv.dylib -lz /usr/local/lib/libexpat.dylib -Wl,-framework -Wl,CoreFoundation -install_name /usr/local/lib/libexiv2.4.dylib -compatibility_version 5 -current_version 5.0
ld: multiple definitions of symbol __divdi3
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_divdi3.o) private external definition of __divdi3 in section (_TEXT,_text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(divdi3_s.o) definition of __divdi3
ld: multiple definitions of symbol __udivdi3
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_udivdi3.o) private external definition of __udivdi3 in section (_TEXT,_text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(udivdi3_s.o) definition of __udivdi3
ld: multiple definitions of symbol __umoddi3
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_umoddi3.o) private external definition of __umoddi3 in section (_TEXT,_text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(umoddi3_s.o) definition of __umoddi3
ld: multiple definitions of symbol __moddi3
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libgcc.a(_moddi3.o) private external definition of __moddi3 in section (_TEXT,_text)
/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/../../../libgcc_s.10.4.dylib(moddi3_s.o) definition of __moddi3
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/libtool: internal link edit command failed
make1: * [lib] Error 1
make: * [all] Error 2
Additional information:
I have successfully built version 0.17 under 10.5.3 (both PPC/Intel).
I had built 0.14 w/o any errors under 10.4.11.
Related issues
History
Updated by Andreas Huggel over 13 years ago
Can you build 0.16 on this system?
If yes, can you build 0.17 with the rmconvert.patch from #552?
Updated by Andreas Huggel over 13 years ago
Another tip and some pointers, courtesy of Google:
Before running make, run this:
$ perl -pi -e "s/-all_load//g" libtool
http://lists.apple.com/archives/Unix-porting/2005/May/msg00004.html
http://savannah.gnu.org/support/?105489
Updated by marius - over 13 years ago
FWIW 0.16 fails with the same error.
However, the perl reinplace code works.
Thanks!
Updated by Andreas Huggel over 13 years ago
So this looks very much like the libtool/OS X/convenience library issue described in the links above.
Won't fix in Exiv2, apply the perl hack when needed.
Updated by Robin Mills over 13 years ago
I encountered this in April, 2008 with exiv2-0.16 on Tiger (MacOS-X 10.4.11).
I documented my solution at http://www.clanmills.com/articles/gpsexiftags/macos.shtml
To build libexiv2 correctly on PPC on Tiger, I had to use the commands:
configure MACOSX_DEPLOYMENT_TARGET=10.4
make MACOSX_DEPLOYMENT_TARGET=10.4
sudo make install
When I didn't, I had linking errors - doubly defined entry points from the c++ libraries.
So although I don't see any reason to re-open this issue, I've added this work-around note in case somebody wishes to build on Tiger.
Updated by Andreas Huggel over 13 years ago
Changed back to 'resolved', since the note above says it needn't be reopened