In dists: libpypy-c is in bin/ instead of lib/

Issue #2630 new
Min RK
created an issue

in *ix binary dists, the libpypy-c library is in the bin/ prefix instead of the lib/, so linkers don't find it without adding LDFLAGS=/path/to/pypy/bin, which is unusual.

Seems like the dylib should just be moved to /lib/, unless I'm missing something.

The homebrew recipe patches this itself, but it would be nice if this were the default.

Comments (2)

  1. Armin Rigo

    That's not possible to do while keeping the current general-purpose locator logic: the pypy executable looks for libpypy-c.so inside its own directory, not inside ../lib/. I think we're fine if 3rd-party distributions like homebrew reorganize things, as long as it continues working in all cases (regular usage, or cffi embedding).

    Note that we are not aware that on OS X, a freshly translated pypy needs LDFLAGS hackery in order to run. It seems to work without it for us on the nightly buildbots.

  2. Min RK reporter

    Note that we are not aware that on OS X, a freshly translated pypy needs LDFLAGS hackery in order to run

    Not in order to run, but in order to build any Extensions. pypy3 5.8 can't build Extensions that link the C API by default on macOS without LDFLAGS. Maybe there's not a test for this? I suspect this PR may fix the more immediate issue of failing to build, as it seems that extensions are meant to rely on the executable itself loading, and thus Extensions shouldn't directly link -lpypy3-c, which is what would not work without LDFLAGS adding the unusual lib path.

    How I came to this:

    1. building an Extension on macOS resulted in lots of undefined C-API symbols
    2. add pypy3-c to the Extension's libraries, since it defines the missing symbols. This worked because I got pypy from homebrew.
    3. As soon as I tried to build on Linux it failed with libpypy3-c not found because it's in bin/ instead of lib/

    Setting LDFLAGS=-undefined dynamic_lookup appears to address the same issue without pulling in pypy3-c as an explicit library dependency.

    So if nothing but the pypy executable itself should ever link pypy3-c, then I think this isn't a major issue, even if it's a bit unusual to have a dylib in bin/.

  3. Log in to comment