[Pyrex] build failure on wrapper definition

[Lenard Lindstrom]

Jim Kaubisch wrote:
> Hi,
>
> I'm trying to write a wrapper around a c library supplied by the
> manufacturer of process control equipment we're using. This is my first
> attempt at using Pyrex and it looks like I've already landed in a bunch
> of trouble - my pyx file compiles ok, but the linker chokes as per
> following extracts. There are a fair number of ctypedef's and cdef
> enum's in the file, but the def below is the first instance of trying
> to define a wrapper. The file built ok before adding the "def". Any
> hint of what is happening here would be greatly appreciated! :-)
>
> Thanks,
> Jim
>
> ------
>
> cdef extern from "/usr/include/stdint.h":
>
> #typedef uint32_t  u32;	// 32-bit unsigned.
> 	ctypedef unsigned int uint32_t
> 	ctypedef uint32_t u32
>
> cdef extern from "Sens121.h":
> #extern u32 S26_DriverOpen ( u32 NumMMs );
> 	u32 S26_DriverOpen ( u32 NumMMs )
>
> #	u32 S26_DriverOpen ( u32 NumMMs )
> def s26_DriverOpen (numMMs):
>         return S26_DriverOpen (numMMs)
>
> Using distutils, this is the result of trying to build
>
> python setup.py build_ext --inplace
> running build_ext
> building 'Sens121' extension
> gcc -pthread -fno-strict-aliasing -DNDEBUG -O2 -g -pipe -Wall
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
> --param=ssp-buffer-size=4 -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fPIC
> -I/usr/include/python2.4 -c Sens121.c -o
> build/temp.linux-x86_64-2.4/Sens121.o
> gcc -pthread -shared build/temp.linux-x86_64-2.4/Sens121.o ./lib2600.a
> -o Sens121.so
> /usr/bin/ld: ./lib2600.a(s26core.o): relocation R_X86_64_32S against `a
> local symbol' can not be used when making a shared object; recompile
> with -fPIC
> ./lib2600.a: could not read symbols: Bad value
> collect2: ld returned 1 exit status
> error: command 'gcc' failed with exit status 1
>   

I know little about linux shared libraries but something about the gcc
-fPIC option. It is a compiler option that specifies position
independent code generation. Apparently all object files linked into a
shared library need to be position independent. The object files,
s26core.o at least,  in lib2600.a were not compiled with the -fPIC
option. I believe this is never an issue with 32 bit PC's, as all code
is position independent. Maybe it is with 64 bit machines.

-- 
Lenard Lindstrom
<len-l at telus.net>