Clang "Interface Stubs" Merged For Offering Interface Libraries To ELF Shared Objects

[phoronix]

Phoronix: Clang "Interface Stubs" Merged For Offering Interface Libraries To ELF Shared Objects

In addition to Clang-Scan-Deps being merged a few days ago, another new feature for LLVM's Clang is called the Clang Interface Stubs and brings a concept from Windows/macOS over to Linux/ELF systems...

http://www.phoronix.com/scan.php?page=news_item&px=Clang-Interface-Stubs

[grigi]

Is this not what .a files are?

[tildearrow]

Typo:

containing the mininal information needed to build against that library.

[Redfoxmoon]

Is this not what .a files are?

No, those are static archives, also used by mingw import libraries with the extensions .lib.a :-)

[grigi]

OH, hold on, I remember now. You link against the .so files at runtime, but also at compile time in conjunction with the interface that is specified in the headers.
Which is more complicated than needed. Haven't paid attention to that in a while.

[carewolf]

OH, hold on, I remember now. You link against the .so files at runtime, but also at compile time in conjunction with the interface that is specified in the headers.
Which is more complicated than needed. Haven't paid attention to that in a while.

You don't need the symbols defined at compile time, but you need them at link time, though you can skip that if you want to (-z undefs). The only thing that really requires the symbols at link time is for recording the symbol tags, so you can get the same version of the function at runtime in case multiple exists (or you are picking up a wrong version of the library and can refuse to launch). Most libraries don't used versioned symbols though.

[blacknova]

So, they decided to implement dll import libraries for linux. It is have been in practice on Windows since forever. The main pro for this is a greatly reduced size of the files linker need to process. Not sure if this will provided any advantages for SDK sizes, since you'd need not just shared library but an import library as well. And you cannot not included shared library in SDK as you'd need it for test runs/debugging etc. Really it is just an equalization of toolsets for all platforms.

[discordian]

You don't need the symbols defined at compile time, but you need them at link time, though you can skip that if you want to (-z undefs). The only thing that really requires the symbols at link time is for recording the symbol tags, so you can get the same version of the function at runtime in case multiple exists (or you are picking up a wrong version of the library and can refuse to launch). Most libraries don't used versioned symbols though.

There are multiple other uses, `--as-needed` can drop useless library dependencies and packaging tools are able to give you the correct dependencies.
eg. if I crosscompile for 32-bit debian I would need a pack of these stubs to ultimately find out which packages are required.

[carewolf]

There are multiple other uses, `--as-needed` can drop useless library dependencies and packaging tools are able to give you the correct dependencies.
eg. if I crosscompile for 32-bit debian I would need a pack of these stubs to ultimately find out which packages are required.

I prefer simply to not link with libraries that I don't need But yes error feedback and sanity checking is another good reason to check at link time.

[discordian]

I prefer simply to not link with libraries that I don't need

Then you likely dont work with different architectures or C libraries. Do you know which architectures need libatomic and when, or when musl needs to link to libpthread, then make similar thoughts about linking dependent software libraries either static or dynamic?