[Gdal-dev] No python support for x86_64 with kakadu?

[Alessandro Amici]

Chris,

On Thursday 28 October 2004 20:46, Chris Hodgson wrote:
> I have compiled gdal successfully with kakadu on my machine, which is an
> Athlon 64 FX. However, I didn't get python support for some reason.so,
> going back to try to add it, I try this:
>
> [root at dragonfly gdal]# python setup.py build

good, the use of the setup.py script is not the standard procedure to build 
the python module, but in normal circumstances it has a good chance to 
work ;). your problem is elsewhere.

> ['pymod/gdal_wrap.c', 'pymod/numpydataset.cpp', 'pymod/gdalnumeric.cpp']
> running build
> running build_py
> running build_ext
> building '_gdalmodule' extension
> c++ -pthread -shared build/temp.linux-x86_64-2.3/pymod/gdal_wrap.o
> build/temp.linux-x86_64-2.3/pymod/numpydataset.o
> build/temp.linux-x86_64-2.3/pymod/gdalnumeric.o -L./.libs -lgdal -o
> build/lib.linux-x86_64-2.3/_gdalmodule.so
> /usr/bin/ld: /usr/local/lib/libgdal.a(jp2.o): relocation R_X86_64_32 can
> not be used when making a shared object; recompile with -fPIC
> /usr/local/lib/libgdal.a: could not read symbols: Bad value
> collect2: ld returned 1 exit status
> error: command 'c++' failed with exit status 1
>
> hmm... something isn't kosher with the 64-bit relocation. I did compile
> kakadu with -fPIC.
>
> Here I see what is probably part of the problem:
>
> [root at dragonfly gdal]# ./configure
> --with-kakadu=/usr/local/src/v4_2_1-00488N --without-geos
> --without-libtool --with-python --with-pic
> ...
> configure: creating libtool
> appending configuration tag "CXX" to libtool
> checking for ld used by g++... /usr/bin/ld -m elf_x86_64
> checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
> checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports
> shared libraries... yes
> checking for g++ option to produce PIC... -fPIC
> checking if g++ PIC flag -fPIC works... yes
> checking if g++ supports -c -o file.o... yes
> checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports
> shared libraries... yes
> checking dynamic linker characteristics... GNU/Linux ld.so
> checking how to hardcode library paths into programs... immediate
> checking whether stripping libraries is possible... yes
> appending configuration tag "F77" to libtool
> checking for ranlib... (cached) ranlib 
> /usr/bin/ld: conftest2.o: relocation R_X86_64_32 can not be used when
> making a shared object; recompile with -fPIC
> conftest2.o: could not read symbols: Bad value
> collect2: ld returned 1 exit status
> checking for g++ -shared ... no(1)
> checking for ld -shared ... no
> checking for dlopen in -ldl... yes
> checking for main in -lm... yes
>
> It does seem to find the fPIC option, but something else in conftest.o
> fails... do I need to run autoconf myself to generate 64-bit compatible
> configure tests? How can I do this? Is this likely to be part of my
> problem?

you used the --without-libtool option (correct, if you want to build kakadu 
support, but then the --with-pic option will probably be ignored, please 
don't add it) and in fact the error come from the gdal self-made check for 
'g++ -shared'.

Frank, this is for you ;-). It has nothing to do with libtool.

> How can I tell if my existing libgdal.a was compiled with -fPIC? Or does
> that even make any sense... I don't have a libgdal.so, because configure
> doesn't think I have support for gcc -shared... something's icky here...

as a workaround you may try to hand edit GDALmake.opt (after configure) adding 
the support for shared libraries. search fo LD_SHARED and change it to:
LD_SHARED = g++ -shared
(better if you make distclean before ;)

cheers,
alessandro