[ptsneves]

There is a huge amount of tooling relying on DT_NEEDED for dependency detection. I am not so sure about general purpose Linux, but in the embedded Linux world this would be a disaster. The Yocto system for example would no longer be able to determine the runtime dependencies of generated binaries.

For the static library part, this is such a beaten down argument I just will not argue. I hope you enjoy re-installing your OS every time there is an security update on a library like openssl.

[sylware]

You missed the point: using "shared objects" would have to be explicit with "dlopen/dlsym/dlclose'.

Mixing static linking with dynamic linking was not a good idea in the first place, and I mean it.

ELF should be "fixed" about this, but to be sincere and honest, I think a lot could be removed from ELF on modern systems.

Maybe it is not worth to fix ELF, but to go something like NGELF which would be excrutiatingly simpler and cleaner than ELF, namely real and disruptive innovation.

[ptsneves]

> You missed the point: using "shared objects" would have to be explicit with "dlopen/dlsym/dlclose'.

dlopen and friends are function calls that you cannot evaluate build time. Actually not even at runtime as they are by nature dynamic and conditionally dlopen is a thing. Any shared object dependency tracking would be impossible or a new standard would be required.

Also dlopen is a POSIX standard. ELFs are used in many other places non POSIX.

> Mixing static linking with dynamic linking was not a good idea in the first place, and I mean it.

Why was it not a good idea? This happens all the time, especially the code that is at the very first executable address of the elf until some libc prepares things is arguably statically linked.

> [...] but to go something like NGELF [...]

Sounds interesting. Could you paste a link? I could not find it in google.