Hi all, Right now the "pypy" executable looks for its lib-python/lib_pypy directories by starting from the path of the "pypy" executable and going up. That path is derived from the C-level argv[0], on which we try once to call readlink() if it is a symlink. That logic is in pypy.module.sys.initpath. When using cffi's embedding mode, however, the logic starts differently: we start at the path of the "libpypy-c.so" library instead, and then we look around in the same way. This is because, of course, there is no "pypy" executable in this case. This difference breaks some packaged pypy's: it is the only thing that prevents e.g. the Arch Linux pypy from working in embedded mode. The reason is that they install /opt/pypy/* like we recommend, and set a symlink /usr/bin/pypy -> /opt/pypy/bin/pypy like we also recommend, but they really move libpypy-c.so in /usr/lib/libpypy-c.so. It works fine in the regular case, but fails with the embedding mode. I tried to make a symlink /usr/lib/libpypy-c.so -> /opt/pypy/bin/libpypy-c.so and embedding mode then works fine. As an attempt to fix this more generally, we should make the two cases more similar. Does it make sense to only look around from the "libpypy-c.so" location? Finding the path of "libpypy-c.so" requires a little bit more hackery than just reading "argv[0]", but on the other hand it is not likely to break even if "pypy" is called strangely (because argv[0] can in theory be any random string). It is code that is so far in pypy.module._cffi_backend.embedding, which would probably move to pypy.module.sys.initpath. This change would require minor fixes for pypy packagers---e.g. arch linux would simply make a symlink for /usr/lib/libpypy-c.so instead of for /usr/bin/pypy. Makes sense? A bientôt, Armin.