Need to handle (strip?) .a files

[ikeycode]

Noticed while building llvm

clang-14.0.6-2-1-x86_64.stone                 100%   50MB   5.7MB/s   00:08    
clang-devel-14.0.6-2-1-x86_64.stone           100% 2129KB   5.1MB/s   00:00    
clang-libs-14.0.6-2-1-x86_64.stone            100%   28MB   6.4MB/s   00:04    
lld-14.0.6-2-1-x86_64.stone                   100%   17MB   3.6MB/s   00:04    
lld-devel-14.0.6-2-1-x86_64.stone             100%   40MB   5.2MB/s   00:07    
llvm-14.0.6-2-1-x86_64.stone                  100%   15MB   6.3MB/s   00:02    
llvm-dbginfo-14.0.6-2-1-x86_64.stone          100%  777MB   5.6MB/s   02:19    
llvm-devel-14.0.6-2-1-x86_64.stone            100%  532MB   5.7MB/s   01:33    
llvm-libs-14.0.6-2-1-x86_64.stone             100%   24MB   6.6MB/s   00:03

We understand heaviness with -dbginfo, they're meant to be mahusive. The -devel is clearly hiding huge .a files and needs rectifying in boulder:

130M	libLLVMScalarOpts.a
67M	libPolly.a

etc.

[ermo]

Correct me if I'm wrong, but isn't there more to it than "just strip .a files blindly"?

In the case where an executable/library/runtime builds statically against a static library .a file in ar format, it will import symbols at link time and save them in its own object code.

If the symbols it imports/incorporates have no string table for function/variable names, doesn't that basically make it impossible for the program being linked statically against the static library to provide introspection/debug-ability for the statically linked artefacts? As in: won't this just result in e.g. a gdb session showing hex offsets and not useful symbol table information when debugging?

[ermo]

After discussing it, the outcome is that we're going to avoid stripping static archives, in order to facilitate a better debugging story for statically built binaries.

Instead, we're going to pattern .a files (possibly with a suitable header check) out into a -devel-static subpackage.

This leaves the burden of pulling in static archives on the packagers responsible for anything configured to build/link statically.

This has the additional benefit of building against dynamic libraries by default AND ensuring less painful (read: smaller) -devel package updates.

[ikeycode]

Need some more consideration re: the naming split. Also some packages may be negatively impacted by this, notably locale archives in glibc. Monitor the split, basiclly.