guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Suggestion for a guix shell feature.


From: Maxim Cournoyer
Subject: Re: Suggestion for a guix shell feature.
Date: Fri, 29 Dec 2023 12:21:31 -0500
User-agent: Gnus/5.13 (Gnus v5.13)

Hi,

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> Hiyall,
>
> On 29 December 2023 03:58:27 UTC, Maxim Cournoyer
> <maxim.cournoyer@gmail.com> wrote:
>>Guix doesn't/shouldn't make use of LD_LIBRARY_PATH, except in rare cases
>>to wrap binaries.  It's better to patch the dlopen calls to use the
>>absolute shared library file name.
>
> Fully agree.
>
> Furthermore, '--ld-library-path' sounds like an inflexible alias of a
> nonexistent '--ad-hoc-search-path=FOO=/bar' option.
>
> So why not instead write a cute little (name "LD_LIBRARY_PATH") fake
> package that does nothing but declare a search path for /lib?  It
> could live in any channel rather than further fatten 'guix shell'.
>
>>Perhaps you are missing the package configuring LIBRARY_PATH and other
>>useful environment variables for finding libraries?  That'd be
>>gcc-toolchain, if I recall correctly.
>
> I might be mistaken but I assumed this was more about running
> 'pre-existing' (cough cough nudge nudge) software not built from
> source.

Ah, if this is the case, the 'guix shell --container --emulate-fhs' may
help, by providing some FHS layout with libraries under e.g. /usr/lib/.

-- 
Thanks,
Maxim



reply via email to

[Prev in Thread] Current Thread [Next in Thread]