From: david larsson <david.larsson@selfhosted.xyz>
To: "Sébastien Lerique" <sl@eauchat.org>
Cc: help-guix@gnu.org,
Help-Guix <help-guix-bounces+someone=selfhosted.xyz@gnu.org>
Subject: Re: Profile's LD_LIBRARY_PATH by default
Date: Thu, 29 Oct 2020 11:07:28 +0000 [thread overview]
Message-ID: <fb0f1e9701c27f327417e6819ecb3062@selfhosted.xyz> (raw)
In-Reply-To: <87d0119whd.fsf@eauchat.org>
On 2020-10-29 10:07, Sébastien Lerique wrote:
> Hello!
>
> On 29 Oct 2020 at 10:10, david larsson <david.larsson@selfhosted.xyz>
> wrote:
>> On 2020-10-28 13:49, Sébastien Lerique wrote:
>>> [snip]
>>> While running a racket program which uses OpenCV, I realised that my
>>> LD_LIBRARY_PATH does not contain my user's profile libs. I have
>>> `libopencv*.so` in `~/.guix-profile/lib/`, but running a racket
>>> program which needs that fails:
>>> ```
>>> $ racket capture.rkt
>>> ffi-lib: couldn't open "libopencv_core.so" (libopencv_core.so: cannot
>>> open shared object file: No such file or directory)
>>> ```
>>> While running
>>> ```
>>> env LD_LIBRARY_PATH=/home/sl/.guix-profile/lib/ racket capture.rkt
>>> ```
>>> works.
>>> (Also, this <http://0x0.st/ik3s.txt> is the output of `env
>>> LD_DEBUG=libs racket capture.rkt`.)
>>> Is this normal behaviour, i.e. that the path to dynamic libs
>>> installed
>>> in my user profile should be manually configured in my shell startup
>>> scripts? Should this not be included in
>>> `~/.guix-profile/etc/profile`?
>
>> I wondered the same, and got answer in the IRC #guix that setting
>> LD_LIBRARY_PATH is highly discouraged (unless you have a specific and
>> good reason to do so in a specific case - never globally). I a good
>> explanation
>> about it here:
>> https://web.archive.org/web/20060719201954/http://www.visi.com/~barr/ldpath.html
>>
>> A good example of how it can go wrong:
>>
>> "In its startup script[a program called WidgetMan], it sets
>> LD_LIBRARY_PATH to
>> point to its copy of Motif so it uses that one when it runs. As it
>> happens,
>> WidgetMan is designed to launch other programs too. Unfortunately,
>> when
>> WidgetMan launches other apps, they inherit the LD_LIBRARY_PATH
>> setting and some
>> Motif based apps now break when run from WidgetMan because WidgetMan's
>> Motif is
>> incompatible with (but the same library version as) the system Motif
>> library.
>> Bummer!"
>
> Yes I see that makes sense. Does this mean that one shouldn't install
> libraries in user profiles?
Not necessarily - it shouldn't hurt anway IIUC. Though I assume it is
more common to install libraries when you use guix environment or guix
profile.
>
> Or maybe that, if I were to package this racket program, then it would
> depend on `opencv` and set its required lib paths properly in its
> package definition (so work no matter if it's system-wide or in a user
> profile)?
IIUC, yes, through package inputs and then the build-system usually
finds the path for you.
> Then, for development, is setting LD_LIBRARY_PATH still the only way
> without installing the lib system-wide?
It is possibly the easiest way, but perhaps not the guix-iest way.
Please someone correct me if Im wrong here:
For development you can use guix environment or guix-profile and
possibly even grafts if you want to develop against newer versions of
opency.
Say you want to test updating the opency package in a profile created by
guix package -m manifest.scm -p ~/guix-profiles/dev-profile; the new
opency version can be grafted onto your racket package X (or all
packages in the profile depending on opency) without rebuilding X, by
adding "(replacement opency-fixed)" in the opency package definition in
the profile manifest. On the next package update for the profile (i.e.
guix package -m manifest-with-replacement.scm -p
~/guix-profile/dev-profile) all dependencies of opency would be updated
(such as your package X). The "manifest.scm" file is a package module
that contains; the definition of opency with "(replacement
opency-fixed)", the package definition for "opency-fixed", definition of
X, and also any other packages you need to test.
see here: https://guix.gnu.org/manual/en/html_node/Security-Updates.html
and here:
https://guix.gnu.org/manual/en/html_node/Invoking-guix-environment.html
>
> (that's a lot of questions, apologies!)
No problem :-)
prev parent reply other threads:[~2020-10-29 11:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-28 13:49 Profile's LD_LIBRARY_PATH by default Sébastien Lerique
2020-10-29 9:10 ` david larsson
2020-10-29 10:07 ` Sébastien Lerique
2020-10-29 11:07 ` david larsson [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fb0f1e9701c27f327417e6819ecb3062@selfhosted.xyz \
--to=david.larsson@selfhosted.xyz \
--cc=help-guix-bounces+someone=selfhosted.xyz@gnu.org \
--cc=help-guix@gnu.org \
--cc=sl@eauchat.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.