guix-patches
[Top][All Lists]
Advanced

[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


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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]