Hi, 2010/7/22 Jason Creighton <jcreigh@gmail.com>:

Hello,

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.

Exactly

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?

The reason is actually in the code: pypy/rlib/libffi.py # On some platforms, we try to link statically libffi, which is small # anyway and avoids endless troubles for installing. On other platforms # libffi.a is typically not there, so we link dynamically. Probably static linking to libffi should be disabled on 64bit platform. Or just skip the test: for what I know, --shared is not really needed on Unix platforms. -- Amaury Forgeot d'Arc