Hi,
On 25 September 2016 at 10:16, Armin Rigo wrote:
> How about looking first from the place of the symlink itself, and if
> not found, we dereference the symlink and look again?
That can't work, because there is no way to know the path of the
symlink to libpypy-c.so. We can only learn the der
Hi again,
On 25 September 2016 at 09:13, Armin Rigo wrote:
> On 24 September 2016 at 23:30, Philip Jenvey wrote:
>> Does this have any effect on virtualenvs?
>>
>> virtualenv symlinks libpypy-c.so and _pypy_init_home returns its location
>> realpath()’d..
How about looking first from the place
Hi Philip,
On 24 September 2016 at 23:30, Philip Jenvey wrote:
> Does this have any effect on virtualenvs?
>
> virtualenv symlinks libpypy-c.so and _pypy_init_home returns its location
> realpath()’d..
Well spotted. More thinking needed.
Armin
___
p
Does this have any effect on virtualenvs?
virtualenv symlinks libpypy-c.so and _pypy_init_home returns its location
realpath()’d..
--
Philip Jenvey
> On Sep 24, 2016, at 1:52 PM, Armin Rigo wrote:
>
> Hi all,
>
> Now PyPy looks for lib-python/lib_pypy starting from the (real)
> location of i
Hi all,
Now PyPy looks for lib-python/lib_pypy starting from the (real)
location of its ``libpypy-c.so``, no longer from the ``pypy``
executable.
Linux distribution packagers, take note! At a minimum, the
``libpypy-c.so`` must really be inside the path containing
``lib-python`` and ``lib_pypy``.
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.initp
