6 ms·

Can Linux not trivially do the same thing as windows with LD_PRELOAD? If so why is this more of an issue on Linux than Windows? Is it really less a technical ch

by gabcoh 3y ago

Can Linux not trivially do the same thing as windows with LD_PRELOAD? If so why is this more of an issue on Linux than Windows? Is it really less a technical challenge and more just a matter of Linux getting less support from upstream developers?

bravetraveler 3y ago
I was thinking/wondering this myself. Not to reinvent the wheel - more toss an idea around, but a 'venv for LD_PRELOAD' sounds like it'd deal with this pretty handily Not... in a way I'd use as a distribution/release maintainer. Probably as an administrator [of my LAN]
- gabcoh 3y ago
  Such things already exist. Eg. Appimage or even docker.
  - bravetraveler 3y ago
    Right, but I don't really want to get into a distribution model - the hack suits me fine :) More an exercise in curiosity than anything Flatpak (or Snap, ew) probably deals with it fine today, Steam's there
  - lnxg33k1 3y ago
    and even that has been managed to be split between snap appimage and flatpak :D (sorry not meant to offend, long time linux day-to-day user here, but it was just ironic for me to point out fragmentation of fragmentation ^^)
- 0x457 3y ago
  That's Nix with extra steps.
  - bravetraveler 3y ago
    I specifically said I'm not really trying to solution this, lol. More toying with the LD_PRELOAD aspect than anything Nix is neat, and I don't think I've used it enough to be too critical - but in some ways it feels like 'extra steps' I wanted to make a 'reproducible' installation (ala kickstart, not strictly binary)... but it felt very much like distribution work; declaring dependencies and the like
    - 0x457 3y ago
      Oh, nix is an extra mile. A lot could be improved, but that's what I'm using to deal with dependencies.
      - bravetraveler 3y ago
        Gotcha, I don't feel so floundering now! I plan to spend more time with it, I see a lot of merit The amount of control is great, but the docs could use some work. For my simple goals (install Sway, Ansible, some other things) it was a broadsword when I need a butter knife
        0x457 3y ago
        What sold me on nix is home-manager and flakes: I can easily bootstrap my environment anywhere nix is available.
- never_inline 3y ago
  There are tools which overwrite linked libraries, eg: chrpath.
stabbles 3y ago
LD_PRELOAD is too global to be useful, it's hard to scope it to one process (and not child processes). macOS is better in the sense that it clears DYLD_* variables when the dynamic linker has done its work and the process starts. (Although that can also be painful when you want to run a shell script and set DYLD_* outside)
- nly 3y ago
  You can compile binaries with additional relative library paths in to them that will take priority over /usr/lib64
  - josephg 3y ago
    How? Maybe this should be better documented & recommended. I suppose at some point you're just statically linking with more steps - though for a problem like this it might be worth it.
    - xioxox 3y ago
      See the ELF rpath, which can be set by the linker. This can be modified after using patchelf.
    - rkeene2 3y ago
      $ORIGIN has been pretty well-known and documented for a very long time
    - yrro 3y ago
      https://sourceware.org/binutils/docs-2.40/ld/Options.html#index-runtime-library-search-path https://sourceware.org/binutils/docs-2.40/ld/Options.html#in...
    - ywei3410 3y ago
      The other comments have already covered the how, but I'd like to add that the mechanism used extensively in Nix [1]. [1] https://nixos.org/ https://nixos.org/
- 3y ago
aidenn0 3y ago
This sounds like it's an interaction with the GPU driver though, which could also happen on windows...
LispSporks22 3y ago
It can be done by setting rpath to origin, even post compilation using the patchelf tool. Works great with C shared libraries. Perhaps ABI issues with C++ shared libs introduces other problems.
- JonChesterfield 3y ago
  With the warning that rpath!=runpath, both are called rpath, and which you get depends on your linker and whether you also pass -Wl,--disable-new-dtags Runpath is the default, and also the one that is non-transitive and overridden by environment variables.
admax88qqq 3y ago
Yes linux _can_, the machinery is there, but culturally the common distros do not. And the defaults do not. On windows I can literally drop a DLL next to an executable and it will pick it up. On linux I have to do a wrapper script to set LD_PRELOAD, or mutate the binary's rpath to get it to load. It's not really a question of capability, but a question of culture and defaults that makes linux hard to support. Debian for example goes through great pains (or used to at least) to unbundle shared libraries such as openssl from projects like chromium.

by gabcoh 3y ago

bravetraveler 3y ago

I was thinking/wondering this myself. Not to reinvent the wheel - more toss an idea around, but a 'venv for LD_PRELOAD' sounds like it'd deal with this pretty handily Not... in a way I'd use as a distribution/release maintainer. Probably as an administrator [of my LAN]

gabcoh 3y ago
Such things already exist. Eg. Appimage or even docker.
- bravetraveler 3y ago
  Right, but I don't really want to get into a distribution model - the hack suits me fine :) More an exercise in curiosity than anything Flatpak (or Snap, ew) probably deals with it fine today, Steam's there
- lnxg33k1 3y ago
  and even that has been managed to be split between snap appimage and flatpak :D (sorry not meant to offend, long time linux day-to-day user here, but it was just ironic for me to point out fragmentation of fragmentation ^^)
0x457 3y ago
That's Nix with extra steps.
- bravetraveler 3y ago
  I specifically said I'm not really trying to solution this, lol. More toying with the LD_PRELOAD aspect than anything Nix is neat, and I don't think I've used it enough to be too critical - but in some ways it feels like 'extra steps' I wanted to make a 'reproducible' installation (ala kickstart, not strictly binary)... but it felt very much like distribution work; declaring dependencies and the like
  - 0x457 3y ago
    Oh, nix is an extra mile. A lot could be improved, but that's what I'm using to deal with dependencies.
    - bravetraveler 3y ago
      Gotcha, I don't feel so floundering now! I plan to spend more time with it, I see a lot of merit The amount of control is great, but the docs could use some work. For my simple goals (install Sway, Ansible, some other things) it was a broadsword when I need a butter knife
      - 0x457 3y ago
        What sold me on nix is home-manager and flakes: I can easily bootstrap my environment anywhere nix is available.
never_inline 3y ago
There are tools which overwrite linked libraries, eg: chrpath.

stabbles 3y ago

LD_PRELOAD is too global to be useful, it's hard to scope it to one process (and not child processes). macOS is better in the sense that it clears DYLD_* variables when the dynamic linker has done its work and the process starts. (Although that can also be painful when you want to run a shell script and set DYLD_* outside)

nly 3y ago
You can compile binaries with additional relative library paths in to them that will take priority over /usr/lib64
- josephg 3y ago
  How? Maybe this should be better documented & recommended. I suppose at some point you're just statically linking with more steps - though for a problem like this it might be worth it.
  - xioxox 3y ago
    See the ELF rpath, which can be set by the linker. This can be modified after using patchelf.
  - rkeene2 3y ago
    $ORIGIN has been pretty well-known and documented for a very long time
  - yrro 3y ago
    https://sourceware.org/binutils/docs-2.40/ld/Options.html#index-runtime-library-search-path https://sourceware.org/binutils/docs-2.40/ld/Options.html#in...
  - ywei3410 3y ago
    The other comments have already covered the how, but I'd like to add that the mechanism used extensively in Nix [1]. [1] https://nixos.org/ https://nixos.org/
3y ago

aidenn0 3y ago

This sounds like it's an interaction with the GPU driver though, which could also happen on windows...

LispSporks22 3y ago

It can be done by setting rpath to origin, even post compilation using the patchelf tool. Works great with C shared libraries. Perhaps ABI issues with C++ shared libs introduces other problems.

JonChesterfield 3y ago
With the warning that rpath!=runpath, both are called rpath, and which you get depends on your linker and whether you also pass -Wl,--disable-new-dtags Runpath is the default, and also the one that is non-transitive and overridden by environment variables.

admax88qqq 3y ago

Yes linux _can_, the machinery is there, but culturally the common distros do not. And the defaults do not. On windows I can literally drop a DLL next to an executable and it will pick it up. On linux I have to do a wrapper script to set LD_PRELOAD, or mutate the binary's rpath to get it to load. It's not really a question of capability, but a question of culture and defaults that makes linux hard to support. Debian for example goes through great pains (or used to at least) to unbundle shared libraries such as openssl from projects like chromium.