GNU bug report logs - #30229
Python modules installed by pip in virtualenv can't find shared objects.

Previous Next

Full log

View this message in rfc822 format

From: zimoun <zimon.toutoune <at> gmail.com>
To: Ricardo Wurmus <rekado <at> elephly.net>
Cc: 30229 <at> debbugs.gnu.org, Fis Trivial <ybbs.daans <at> hotmail.com>
Subject: bug#30229: Python modules installed by pip in virtualenv can't find shared objects.
Date: Thu, 25 Nov 2021 00:39:21 +0100

Hi,

On Tue, 23 Jan 2018 at 13:00, Ricardo Wurmus <rekado <at> elephly.net> wrote:

>> When a python module needs to load a dynamic shared object, it looks in the
>> path provided by *LD_LIBRARY_PATH*(1), but guix doesn't modify this environment
>> variable to export the needed path for python.
>
> We cannot set this environment variable by default lest we break other
> packages that may be installed.  LD_LIBRARY_PATH is dangerous as it
> tells the runtime linker to prefer libraries in the specified
> directories.
>
> For Guix packages we use different means to embed store paths in
> binaries, which are looked up at runtime.  For binaries that’s achieved
> with RUNPATH; for others we patch the sources to ensure that libraries
> are not looked up merely by name but by absolute path.
>
> In your particular case (installing packages without Guix) I think the
> best way is to manually set LD_LIBRARY_PATH on demand, or to set
> LD_PRELOAD to the specific libraries that are required.
>
> In general, though, I recommend using Guix for package management and
> development instead of virtualenv and pip.

Regarding the improvements of ’guix import pypi’ since 2018, and because
tweaking LD_LIBRARY_PATH is dangerous, I do not see what could be the
next action to solve this.

Therefore, I propose to close it.  WDYT?


Cheers,
simon

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.