I would be really happy if instead of a dumb tool like

    ar -r libexample.a f.o g.o

it was like creating shared libraries

    ld --static -o libexample.a f.o g.o -L /somewhere/lib -ldep1 -ldep2 -rpath /somewhere/lib

And that this would make the linker:

1. check whether all "undefined" symbols can be resolved in dependencies mentioned in `-l`, otherwise fail

2. store metadata of "used" libraries.

So, it would create an archive `libexample.a` containing:

    f.o
    g.o
    METADATA

where METADATA contains the search path `/somewhere/lib` and needed libraries `dep1` and `dep2`.

So that ultimately when you compile and link `gcc foo.c -lexample`, the linker resolves the dependencies just like in shared linking.

That would be awesome!

How do .rlibs work? Do those resemble these .sbos? .rlibs look like archives IIRC but maybe they're able to resolve relocations internal to them?

EDIT: after some brief searching around, I believe .rlibs are little more than archives with rust-specific metadata and internal relocations are not resolved.

This is great, static linking has always been my preferred way to build.

Modernizing of static libraries doesn't solve their main problem. They still contain compiled binary code, which is used by linker mostly as is. It maybe was fine 40 years ago, but nowadays this limitation leads to result binaries with suboptimal performance. Something better should be used instead, like compiler-dependent libraries containing intermediate code, which may be further composed and optimized, like it happens with LTO for non-static-library code.

"Glibc static compilation is broken for political purposes"

http://stalinux.wikidot.com/

Very nice to see an update!

I have to admit the pushback on ET_STAT is not completely unexpected. I can see why the gABI thread would argue that it can be solved without a new e_type. It would be a major change that requires updating all toolchains, on the consumer and producer side. It would certainly take over a decade for the support to percolate everywhere, including some of the mobile and embedded toolchains where I've had these static linking & symbol visibility issues before.

The reason I still wouldn't mind ET_STAT is that I feel it does remove some complexity in the long run by not relying on things like ar archives, their hidden members with special meaning, and their different flavors. We will still be working with ELF many decades from now, so I still see some value in doing these slow migrations that simplify the final design. I would be happy if fifty or a hundred years from now ar archives becomes history, like ELF has done to the a.out format.

That aside, there are also some interesting alternative ideas in the gABI thread (STB_LIBLOCAL is intriguing), but it seems like the path forward is through the toolchain first.

I'd consider it a very nice result if third-party tools like armerge are deprecated by upstream support in the native toolchain (but I appreciate the mention in the article!)

And thank you for continuing to work on this, really appreciate the work you've been doing there.

Why was their build broken?

It’s been a while but I’m pretty sure the Mach-O linker on macOS has exactly the feature you are looking for.

Basically there is a linker flag to produce a .o while maintaining relocation info.

This can then be fed into another linker later, but the important point is that internal symbols can be stripped, or even just remain internal through namespacing.