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

[Amaury Forgeot d'Arc]

Hi,

2010/7/22 Jason Creighton <jcreigh at 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