|
From: | Philip McGrath |
Subject: | [bug#47180] [PATCH] gnu: racket: Don't inject store paths into Racket files. |
Date: | Fri, 16 Apr 2021 16:16:04 -0400 |
User-agent: | Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |