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

[Philip McGrath <philip@philipmcgrath.com>]

Hi,

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.

But I don't have much of an idea of what "somehow" might be, and I'm not 
really a C hacker when I can avoid it :)

-Philip