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
