[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#47180] [PATCH] gnu: racket: Don't inject store paths into Racket fi
[bug#47180] [PATCH] gnu: racket: Don't inject store paths into Racket files.
Fri, 16 Apr 2021 16:16:04 -0400
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.9.1
On 4/12/21 8:55 AM, Ludovic Courtès wrote:
Philip McGrath <email@example.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 :)