Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux kernel will support $ORIGIN, sort of

fzakaria.com

Post reply on HN
Print view View original

31–40 of 78 posts

Re: Linux kernel will support $ORIGIN, sort of

#31

Post by myrmidon »

mort96 wrote: post #25
roblabla wrote: post #14

Earlier quoted context omitted.

Not with NixOS. ld.so is tied to a version of glibc, in ways that can be subtly incompatible. And nixos can have multiple glibc version installed on a single machine. Besides, it allows for upgrades/downgrades to be done in a way that's much less error-prone.

"ld.so is tied to a version of glibc" is such a horrible GNUism.

Isn't that kinda to be expected if you want to provide dynamic loading functionality (dlopen)?

Is the windows situation really all that different/better (with GetProcAddress in kernel32.dll)?

Re: Linux kernel will support $ORIGIN, sort of

#32

Post by Joker_vD »

VorpalWay wrote: post #26
HexDecOctBin wrote: post #15

Earlier quoted context omitted.

Unfortunately, Glibc and loader are linked together intrinsically in the Linux ecosystem. So, if you want to be able to launch a program reliably, shipping your own loader and libc might actually be the only way.

Glibc is backward compatible though, they even have symbol versioning to provide multiple versions of the same symbol. So as long as you have the same or a newer version of glibc (than what was built against) you should be good to go. And I don't remember hearing about breakages for this. Other libraries on the system is far more hit and miss, but glibc is quite compatible. The other way around is harder though, you…

No, glibc isn't backwards compatible; I've had instances when the loader would refuse to load the executable because the installed glibc is too new for it.

Re: Linux kernel will support $ORIGIN, sort of

#33

Post by farfatched »

charcircuit wrote: post #10

Nix has caused so much busywork to be created through the entire Linux ecosystem. Rather than fixing their own project they force work upon so many others. Instead of looking for ways Nix could work with ensuring else they force everything else to be modified to work with Nix. You will constantly seem them trying to get projects to adapt a flake.nix or to replace bash scripts with a different shebang since they hardc…

Nobody forces projects to accept changes that add support for various platforms, yet it's common that they do.

Nix is one such platform.

Re: Linux kernel will support $ORIGIN, sort of

#34

Post by mort96 »

myrmidon wrote: post #31
mort96 wrote: post #25

Earlier quoted context omitted.

"ld.so is tied to a version of glibc" is such a horrible GNUism.

Isn't that kinda to be expected if you want to provide dynamic loading functionality (dlopen)? Is the windows situation really all that different/better (with GetProcAddress in kernel32.dll)?

The Windows situation is way different: every process is supposed to link against kernel32.dll, that's the public interface to the kernel. In Linux, glibc is just one of many C stdlib implementations, you can have many versions of glibc on the same system, etc.

Re: Linux kernel will support $ORIGIN, sort of

#35

Post by jcgl »

myrmidon wrote: post #31
mort96 wrote: post #25

Earlier quoted context omitted.

"ld.so is tied to a version of glibc" is such a horrible GNUism.

Isn't that kinda to be expected if you want to provide dynamic loading functionality (dlopen)? Is the windows situation really all that different/better (with GetProcAddress in kernel32.dll)?

Not my area, but isn't it really only because glibc doesn't maintain stable interfaces across versions? If it did, you absolutely could use the same ld.so with different glibc versions. But it doesn't, so here we are.

Re: Linux kernel will support $ORIGIN, sort of

#37

Post by stabbles »

chuckadams wrote: post #29
pm215 wrote: post #12

Earlier quoted context omitted.

I suspect it's a mix of historical reasons (#! support was added pretty early, in 1980 or so, when the unix development philosophy I think tended quite strongly to "do the simple thing", and there wasn't so much variation in where you might put important binaries like the shell), plus the fact that the kernel doesn't know anything about PATH (it's only your shell that does), plus vague worries about potentially accid…

> plus the fact that the kernel doesn't know anything about PATH (it's only your shell that does) glibc is what deals with PATH, not the shell. On Linux, it's execvp(3) in libc which is implemented in terms of execve(2) in the kernel, but POSIX doesn't make a distinction between syscalls and library functions, so a kernel could implement either or none directly.

To be fair, many shells have command caching, so they effectively roll their own exec syscall wrapper:

    $ python3 -c 'print("hi")'
    hi
    $ hash
    hits command
       1 /usr/bin/python3

Re: Linux kernel will support $ORIGIN, sort of

#38

Post by bonzini »

Joker_vD wrote: post #32
VorpalWay wrote: post #26

Earlier quoted context omitted.

Glibc is backward compatible though, they even have symbol versioning to provide multiple versions of the same symbol. So as long as you have the same or a newer version of glibc (than what was built against) you should be good to go. And I don't remember hearing about breakages for this. Other libraries on the system is far more hit and miss, but glibc is quite compatible. The other way around is harder though, you…

No, glibc isn't backwards compatible; I've had instances when the loader would refuse to load the executable because the installed glibc is too new for it.

That's not supposed to happen. I would like to have more info.

Re: Linux kernel will support $ORIGIN, sort of

#39

Post by geocar »

jcgl wrote: post #35
myrmidon wrote: post #31

Earlier quoted context omitted.

Isn't that kinda to be expected if you want to provide dynamic loading functionality (dlopen)? Is the windows situation really all that different/better (with GetProcAddress in kernel32.dll)?

Not my area, but isn't it really only because glibc doesn't maintain stable interfaces across versions? If it did, you absolutely could use the same ld.so with different glibc versions. But it doesn't, so here we are.

The C standard isn’t stable across versions.

extern int errno;

Re: Linux kernel will support $ORIGIN, sort of

#40

Post by roblabla »

myrmidon wrote: post #31
mort96 wrote: post #25

Earlier quoted context omitted.

"ld.so is tied to a version of glibc" is such a horrible GNUism.

Isn't that kinda to be expected if you want to provide dynamic loading functionality (dlopen)? Is the windows situation really all that different/better (with GetProcAddress in kernel32.dll)?

In theory, ld.so could provide a stable interface to its dynamic loading capabilities independently of glibc. Then glibc would not have to be updated in concert with ld.so. There's no inherent reason that glibc should be the library shipping a dynamic linker - we could easily be in a world where libld was developed independently from libc.

On Windows, things are less modular, so it's less of an issue. That said, there's also weird shenanigans when it comes to the CRT (which can be statically linked) vs ntdll (which provides the actual linker implementation), that can make certain niche features of the linker misbehave (delay loading in particular is weird).

Post reply on HN