Notices where this attachment appears
-
Embed this notice
@xerz Why even, musl is also good when dynamically linked. (In fact one of my reasons for throwing the last remains of glibc here is how awful glibc's ld.so is)
-
Embed this notice
> think about pledge/unveil on linux
> it's restrictions added in the middle of runtime
> remember that epic fail in glibc ld.so
-
Embed this notice
@icedquinn @mischievoustomato @novenary @wolf480pl GNU basically never documents their extensions, this is why I say they do vendor-locking.
But that should only matter for ones where you don't have proper third-party implementations/documentations, which here you absolutely did.
Like if EAC wanted, they could be like "Nope, we're doing ld.so ourselves" (probably a terribly bad idea btw) and they would be able to implement gnu_hash support easily.
-
Embed this notice
@icedquinn @mischievoustomato @novenary @wolf480pl What do you mean exactly by technical report?
Because it's been documented for at least 10 years by now (just not by GNU AFAIK) and with third-party implementations like LLVM's lld, musl's ld.so, …
It's very much a de-facto standard.
-
Embed this notice
@icedquinn @mischievoustomato @novenary @wolf480pl Also it's a funny thing because it likely means there was a massive blind spot for EAC.
AFAIK the ld.so of glibc will load gnu_hash when present and so ignore dt_hash.
-
Embed this notice
@tthbaltazar @psykose Meanwhile I though few times about making my own barebones ld(1) implementation, lol. (meanwhile musl's ld.so looks good to me)