[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