3 ms·
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
by stabbles 1y ago
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.
- eyalitki 1y agoOP here, it was also my opinion that the handling of static libraries should significantly be improved, and ld should have a "--static-lib" flag to properly handle it. Sadly, the ELF committee prefers a more subtle approach, hence even the proposed build of the static bundle object is done on top of the existing "ld -r", and the output is still wrapped inside a .a archive for compatibility. I hope that once integrated to linkers the adoption of this new format will help convince that it deserves significantly better tooling.