[bug#47180] [PATCH] gnu: racket: Don't inject store paths into Racket files.

[Ludovic Courtès]

Hi,

Philip McGrath <philip@philipmcgrath.com> skribis:

> On 4/12/21 8:55 AM, Ludovic Courtès wrote:
>> Philip McGrath <philip@philipmcgrath.com> skribis:
>>> Rather than using "config.rktd", an alternative approach would be to
>>> set things up so that `dlopen` would find the foreign libraries,
>>> perhaps via `LD_LIBRARY_PATH`. This has some intriguing possibilities:
>>> I could imagine Guix providing an alternate `dlopen` implementation
>>> that might be useful beyond Racket.
>> What would that alternate dlopen do?  It still has to know where to
>> look
>> for things, somehow.
>
> This was a very fuzzy thought with a lot of reliance on "somehow"—I'm
> not certain it would actually make sense or even be possible—but what
> I had in mind is that `dlopen`, together with the dynamic linker and
> its various configuration and cache files, has some places it will
> search for shared libraries, e.g. in "/lib" and "/usr/lib". If 
> `gnu-build-system` could somehow communicate with those mechanisms,
> then packages doing things like `dlopen("libm.so.6", RTLD_LAZY)`
> wouldn't need to have their source code rewritten to include store
> files: Guix would arrange for `dlopen` to find "libm.so.6" among the
> package inputs. Then Guix would only need to know how to graft
> whatever mechanism it used to configure things for `dlopen`, rather
> than having to worry about all of the strange things compilers might
> do with string literals.

To me, the most practical way it can work is by explicitly replacing
“libfoo.so” with “/gnu/store/…/libfoo.so” in the source.

We could change the ‘dlopen’ implementation altogether so that it (say)
looks for a meta-data file listing search paths, but that’s the kind of
intrusive change I’d rather avoid.

Also, there are cases where we actually want “dynamic binding” (search
for the lib and load it *if* it’s available) rather than “static
binding” (hard-code the name of the library so it’s always found when we
dlopen it).  This is the case for plugins and such.

I guess we need to explore the problem space a bit further.  :-)

Thanks,
Ludo’.