Re: How do I use wrap-ruby-program to make curl findable in a Ruby package?

[Carlo Zancanaro <carlo@zancanaro.id.au>]

Hi Marek,

On Tue, Feb 06 2024, Marek Paśnikowski wrote:
> 06.02.2024 13:20:52 CET Carlo Zancanaro:
>> I'm glad you got something working. Using wrap-program like this will
>> likely work, but with the downside that LD_LIBRARY_PATH will also be
>> inherited by any child processes. This might be fine for ruby-nano-bots,
>> but this has caused me serious compatibility problems in the past.
>
> If my logic is correct, this should be mitigated somewhat by placing the
> needed library path at the end of the $LD_LIBRARY_PATH ? Which is why I opted
> for the ~suffix~ argument in the ~wrap-program~ .

The problems I have had in the past was when spawning another program,
which doesn't want LD_LIBRARY_PATH set at all. Doing so caused
completely incorrect library versions to be loaded for child processes,
because the environment variable was inherited by all child processes.

I ended up having to modify the places where those child processes were
spawned to clear LD_LIBRARY_PATH before spawning.

>> Usually, I prefer to store a reference to the precise library in the
>> store, rather than setting LD_LIBRARY_PATH. I'm not really sure how to
>> do that in your case, because I'm not familiar with ruby-nano-bots or
>> any of its dependencies.
>
> I believe this exact behaviour is achieved by ~(search-input-file inputs "lib/
> libcurl.so")~ . When I first attempted to build the ~wrap-program~ call I had 
> a nesting error which explicitly showed that "/gnu/store/hash-curl/lib" is of 
> unexpected type. Am I wrong?

No, sorry. You are using a precise store reference in LD_LIBRARY_PATH,
that's fine. I was more saying as an alternative to LD_LIBRARY_PATH,
it's nicer to patch the program itself to load a specific library. That
is, patch ruby-nano-bots (or its relevant dependency) during the Guix
build so it's dlopening the specific library in the store.

Carlo