[gabcoh]

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?

[stabbles]

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]

You can compile binaries with additional relative library paths in to them that will take priority over /usr/lib64

[josephg]

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]

See the ELF rpath, which can be set by the linker. This can be modified after using patchelf.

[yrro]

https://sourceware.org/binutils/docs-2.40/ld/Options.html#in...

[ywei3410]

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/

[rkeene2]

$ORIGIN has been pretty well-known and documented for a very long time

[ungamedplayer]

You can set it in the environment for a single process.

[bravetraveler]

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]

Such things already exist. Eg. Appimage or even docker.

[lnxg33k1]

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 ^^)

[bravetraveler]

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

[0x457]

That's Nix with extra steps.

[bravetraveler]

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]

Oh, nix is an extra mile. A lot could be improved, but that's what I'm using to deal with dependencies.

[bravetraveler]

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]

What sold me on nix is home-manager and flakes: I can easily bootstrap my environment anywhere nix is available.

[never_inline]

There are tools which overwrite linked libraries, eg: chrpath.

[LispSporks22]

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]

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]

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.

[aidenn0]

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