Fedora 29 Might Make Change To Eliminate Unnecessary Linking

[phoronix]

Phoronix: Fedora 29 Might Make Change To Eliminate Unnecessary Linking

Yet another notable change proposal for Fedora 29 is to "remove excessive linking", which could help program start-up times, but may be too late for happening with the current Fedora Linux release cycle...

http://www.phoronix.com/scan.php?page=news_item&px=Fedora-29-Linker-As-Needed

[timofonic]

I'm extremely surprised this isn't yet done by ALL major distributions...

[RayDonnelly]

The problem with `-Wl,--as-needed` is that it only applies to shared libraries found after it. I had to patch libtool to shunt this argument to the front of the list.

[grigi]

Actually it has been default on Gentoo for years. No need to set it in your make.conf

[F.Ultra]

I'm extremely surprised this isn't yet done by ALL major distributions...

The problem is that if A links with B but needs symbols from C without linking with C and B links with C without using any symbols from C then it all works, but if you then link B with --as-needed then out of the blue A breaks.

Yes this means that A is built wrong and should be fixed but with 100k packages this is quite a bit to go over and fix for a major distribution, also there will likely exist 3:d party software that are built wrong here and that will break if the distribution decides to compile with --as-needed all of a sudden.

Which is why you see Fedora introduce this but not RHEL.

[puleglot]

The problem with `-Wl,--as-needed` is that it only applies to shared libraries found after it. I had to patch libtool to shunt this argument to the front of the list.

Gentoo and Debian applies patch to ltmain.sh

[Weasel]

The problem is that if A links with B but needs symbols from C without linking with C and B links with C without using any symbols from C then it all works, but if you then link B with --as-needed then out of the blue A breaks.

Yes this means that A is built wrong and should be fixed but with 100k packages this is quite a bit to go over and fix for a major distribution, also there will likely exist 3:d party software that are built wrong here and that will break if the distribution decides to compile with --as-needed all of a sudden.

Which is why you see Fedora introduce this but not RHEL.

The stupidity in Linux userland never ceases to amaze me.

"Import a symbol from a library but don't link to it", WTF? That's not even possible on Windows DLLs since symbols are part of the imports from a library. And rightfully so.

[nanonyme]

The stupidity in Linux userland never ceases to amaze me.

"Import a symbol from a library but don't link to it", WTF? That's not even possible on Windows DLLs since symbols are part of the imports from a library. And rightfully so.

Unless of the of course you directly dll open during runtime and getprocaddress or whatever it was. But then you know you're operating on thin ice

[F.Ultra]

The stupidity in Linux userland never ceases to amaze me.

"Import a symbol from a library but don't link to it", WTF? That's not even possible on Windows DLLs since symbols are part of the imports from a library. And rightfully so.

Windows have their own hell here since you there can link with two different DLL:s that each link to different versions of a third library with all the ugliness that this can cause.

On Linux the symbols are a shared namespace per process so if your application links with say OpenSSL and you then start to use Zlib functions but forget to link with it (-lz) you can still access the exposes symbols from zlib that OpenSSL links.

However there are some hoops that you have to jump over for this to work because out of the box gcc will refuse to build, exactly how you enable this is not something that I remember any more but I've seen it in the past.

[Weasel]

Windows have their own hell here since you there can link with two different DLL:s that each link to different versions of a third library with all the ugliness that this can cause.

Actually it handles this situation perfectly without conflicts, this is ugly only on Linux / Unix. Remember that symbols are not global, and in fact you don't even need symbols to import from a given DLL, you can use ordinals (indices of sorts). Clearly importing "function number 1" from a bazillion DLLs works perfectly fine, same as importing symbol ABC from a bazillion DLLs, no conflict at all, they're separate.

On Linux the symbols are a shared namespace per process so if your application links with say OpenSSL and you then start to use Zlib functions but forget to link with it (-lz) you can still access the exposes symbols from zlib that OpenSSL links.

This should never be allowed. Ever. It's just stupid. Should totally give you massive error and smack you in the head for trying to do it. IMO.

I mean on Linux/Unix shared objects, it's like using god damn a shared global variable space for the symbols, while on Windows they're all local to the DLL itself (same as on Linux if you manually use dlopen/dlsym). Even if you use 1 million versions of a library, they'll all be in separate namespaces/scopes, so each function is unique, and each of their global vars are also unique etc... no conflicts there.