staticlibs contain broken archive indexes when linked against external LTO libraries

[george-hopkins]

When building LTO-enabled external libraries with cc (invokes gcc-ar), the resulting staticlibs contain a broken archive index. It doesn't parse __gnu_lto_* and index them as is:

$ gcc-nm -s target/release/libexample.a | head
Archive index:
[...]
__gnu_lto_v1 in example.o
__gnu_lto_slim in example.o
$ gcc-nm -s target/release/build/example-0173c929f3540f9e/out/libexample.a | head
Archive index:
example_abc in example.o

When linking against the staticlib later on, GCC is unable to pick-up these symbols because they are not indexed properly. If I rebuild the index manually (extracting all objects and combine them back together with gcc-ar crs), the build process works as expected.

I'm not sure whether this actually a bug or just something that is not supported. It would be understandable if rustc doesn't provide handling of these special symbols.

Meta

rustc 1.31.0-nightly (2bd5993ca 2018-10-02)
binary: rustc
commit-hash: 2bd5993ca25e09b894e4fd6539a2fba64599eee2
commit-date: 2018-10-02
host: x86_64-unknown-linux-gnu
release: 1.31.0-nightly
LLVM version: 8.0

[alexcrichton]

Thanks for the report! I suspect this is the same issue as #26003, just manifesting itself with gcc rather than MSVC, so I'm going to close in favor of that issue.

[george-hopkins]

Thank you for taking a look at this! It seems to be the same issue indeed. In case anyone comes across it too: A simple pass with gcc-ar s target/release/libexample.a after cargo build builds a fixed index.