[pypy-dev] Building a shared library on x86-64 fails due to static linking of libffi

Jason Creighton jcreigh at gmail.com
Thu Jul 22 15:34:55 CEST 2010


While working on asmgcc-64, I ran into this issue. For some reason, PyPy
wants to link libffi statically on some platforms, Linux included. But when
compiling with the "shared" option (as is done in some asmgcroot tests), you
get link errors like:

/usr/bin/ld: /usr/lib/libffi.a(ffi64.o): relocation R_X86_64_32S against
`.rodata' can not be used when making a shared object; recompile with -fPIC
/usr/lib/libffi.a: could not read symbols: Bad value

I interpret this to mean that since we building a shared library, the
resulting library must be position independent, so we can't link in non-PIC
such as is found in the static version of libffi on my system. (Ubuntu
10.04, x86-64). And indeed, if I switch to linking dynamically, the error
goes away and things seem to work.

However, I don't want to just blindly enable dynamic linking, because there
must be a reason it was configured to link statically in the first place.
What is that reason?

Also, what steps should I take here? I think I need to enable dynamic
linking of libffi on x86-64 Linux when building a shared library at the very
least, but to reduce the number of code paths, I'm somewhat inclined to link
dynamically whether we're building a library or not. What do you guys think?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/pypy-dev/attachments/20100722/0ac1b02a/attachment.html>

More information about the Pypy-dev mailing list