[Gdal-dev] libgdal.la build error

Eric Dönges Eric.Doenges at rcs.ei.tum.de
Mon Dec 6 04:38:31 EST 2004


Kirk R.Wythers wrote:

> I am getting a build error with 1.2.5 on Mac OSX. Does anyone recognize 
> this:
> 
> __TEXT,__text)
> /usr/local/lib/libtiff.dylib(jidctint.o) definition of _jpeg_idct_islow
> ld: warning multiple definitions of symbol _jpeg_fdct_float
> /usr/local/lib/libjpeg.a(jfdctflt.o) definition of _jpeg_fdct_float in 
> section (__TEXT,__text)
> /usr/local/lib/libtiff.dylib(jfdctflt.o) definition of _jpeg_fdct_float
> ld: warning multiple definitions of symbol _jpeg_fdct_ifast
> /usr/local/lib/libjpeg.a(jfdctfst.o) definition of _jpeg_fdct_ifast in 
> section (__TEXT,__text)
> /usr/local/lib/libtiff.dylib(jfdctfst.o) definition of _jpeg_fdct_ifast
> ld: warning multiple definitions of symbol _jpeg_fdct_islow
> /usr/local/lib/libjpeg.a(jfdctint.o) definition of _jpeg_fdct_islow in 
> section (__TEXT,__text)
> /usr/local/lib/libtiff.dylib(jfdctint.o) definition of _jpeg_fdct_islow

The way I read this, you have a dynamic libtiff that includes a static
libjpeg (probably for JPEG support in TIFF files); this leads to
multiple defined symbol errors when you try to link anything with both
libraries. I'm not aware of any way to force Apple's Mach-O linker to
take the first definition it finds and ignore multiple symbol
definitions, so you'll probably have to rebuild libtiff either

a) without JPEG support
b) after installing a dynamic libjpeg, and linking against that

Of course, it might also work to simply leave the libjpeg.a out of your
link, since it's already included in libtiff.dylib

> ld: Undefined symbols:
> _fftw2d_create_plan referenced from libgrass expected to be defined in 
> /CLAM_EXTERNAL_LIBS/fftw/lib/libfftw.2.dylib
> _fftwnd_destroy_plan referenced from libgrass expected to be defined in 
> /CLAM_EXTERNAL_LIBS/fftw/lib/libfftw.2.dylib
> _fftwnd_one referenced from libgrass expected to be defined in 
> /CLAM_EXTERNAL_LIBS/fftw/lib/libfftw.2.dylib
> /usr/bin/libtool: internal link edit command failed
> make[1]: *** [libgdal.la] Error 1
> make: *** [check-lib] Error 2

As far as I can see, you're linking against libgrass, which expects to
find some necessary functions in libfftw.dylib found in
/CLAM_EXTERNAL_LIBS/fftw/lib/libfftw.2.dylib. It doesn't matter if you
have a working libfftw.dylib in /usr/local/lib - the Mach-O dynamic
linker won't look for it there, because MacOS X uses so-called
"two-level" namespaces by default. Basically this means the linker
records (at build time) in which library the dynamic linker should
expect to find which functions. To solve this problem, you could try to
disable two-level namespaces (sorry, I don't have the linker option
commited to memory), or make sure *all* dynamic libraries used are
compiled for and installed in the correct places (most likely 
/usr/local/lib) before linking anything with them. Note that the dylib
itself records where it expects to be installed, so you can't just
copy libraries around. Unfortunately, Mach-O dynamic libraries behave
a bit differently from ELF shared objects.

With kind regards,
Eric



More information about the Gdal-dev mailing list