How to: How to wrap executablea?

How to: How to wrap executablea?

[Marius via]

Good evening,

I'm trying to execute a pre compiled program (on a Guix System) that I think is trying to call /lib64/ld-linux-x86-64.so.2 by its absolute path. Since Guix System does use the store and usually makes use of variables like "SHELL", "LIBRARY_PATH", etc. How do I wrap executables that technically are gnu-linux cross platform but use absolute paths that depend on distribution?

I've read the entire Guix Ref. Manual but I'm too scared to do anything and don't know exactly what to do.

Should I use "guix shell --container -S" and create a symbolic link in the virtual shell?

Or should I make a package definition?

I know this is not really a guix problem... More like the people that programmed the executable hardcoded everything to their distribution (I think they used Ubuntu)...


I would like to know how to deal with this kind of problem, because the majority of code is hardcoded like this (for example hardcoded call to /usr/bin/bash).


Thank you.

Best regards,
Marius.
-- 
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.

Re: How to: How to wrap executablea?

[woshilapin]

Hi Marius,
 
> I'm trying to execute a pre compiled program (on a Guix System) that I think is trying to call /lib64/ld-linux-x86-64.so.2 by its absolute path. Since Guix System does use the store and usually makes use of variables like "SHELL", "LIBRARY_PATH", etc. How do I wrap executables that technically are gnu-linux cross platform but use absolute paths that depend on distribution?

It might not be exactly the same problem, but I remember getting around this kind of problem by providing guix's version of the library with `LD_LIBRARY_PATH`. Doing something like this.

```
eval "$(guix shell --search-paths)"
export LD_LIBRARY_PATH="${LIBRARY_PATH}"
```

It's probably a horrible hack (I honestly don't know enough to know if it's nice or horrible), but it got me something to work with.

Hope this helps, and I'd be happy to know of a cleaner solution.

Sincerely,
--
woshilapin / Jean

Re: How to: How to wrap executablea?

[Dev@icepic]

Hi!

I think you need to rewrite the path to the dependencies of the executable using `patchelf`, so that the libs from the store are used. I only have done this in nix, but it should be the same for guix? Maybe someone with more experience can comment on this.

Best regards

Christoph

Re: How to: How to wrap executablea?

[Andreas Enge]

Am Thu, Nov 21, 2024 at 01:00:54PM +0100 schrieb Dev@icepic:
> I think you need to rewrite the path to the dependencies of the executable using `patchelf`, so that the libs from the store are used. I only have done this in nix, but it should be the same for guix? Maybe someone with more experience can comment on this.

I think you need to use "patchelf --set-interpreter FILENAME" for the
ld-linux.so bit. I have done it in the past, but try to avoid it, as in the
end running prebuilt binaries is always a hit-or-miss experience, possibly
after spending quite some time trying to make things work.

Andreas

Re: How to: How to wrap executablea?

[Marius via]

Thank you all,


I've recently found this possible solution that it's native to Guix: <https://guix.gnu.org/en/blog/2023/the-filesystem-hierarchy-standard-comes-to-guix-containers/>. So there we have the technical words we were looking for, since Guix System does not conform with FHS the binary did not work. But if I execute it in a shell container with a FHS emulated file system then it would probably work (I've to try it yet)!


Best regards,
Marius.

El 21 de noviembre de 2024 11:31:33 UTC, woshilapin <woshilapin@tuziwo.info> escribió:
>Hi Marius,
> 
>> I'm trying to execute a pre compiled program (on a Guix System) that I think is trying to call /lib64/ld-linux-x86-64.so.2 by its absolute path. Since Guix System does use the store and usually makes use of variables like "SHELL", "LIBRARY_PATH", etc. How do I wrap executables that technically are gnu-linux cross platform but use absolute paths that depend on distribution?
>
>It might not be exactly the same problem, but I remember getting around this kind of problem by providing guix's version of the library with `LD_LIBRARY_PATH`. Doing something like this.
>
>```
>eval "$(guix shell --search-paths)"
>export LD_LIBRARY_PATH="${LIBRARY_PATH}"
>```
>
>It's probably a horrible hack (I honestly don't know enough to know if it's nice or horrible), but it got me something to work with.
>
>Hope this helps, and I'd be happy to know of a cleaner solution.
>
>Sincerely,
>--
>woshilapin / Jean