rustc refuses to add bitcode to specific rlibs unless the crate id is "lib"

[Tobba]

In the standard distribution this happens to librlibc (with a target of i386-linux-elf), but I have it happening on another crate of mine

May also be a windows-only issue since as far as I know the rlib creation relies on invoking llvm-as, which is one of the dodgiest utilities within LLVM

[huonw]

Do you have a (reasonably) small self-contained example crate for this?

[Tobba]

That really would be librlibc, it only seems to happen under some very specific conditions

[huonw]

Yes, it seems that's it's unreliable, since (on x86-64 linux):

$ ar t librlibc-d1ece24e-0.11.0-pre.rlib 
rlibc.o
rust.metadata.bin
rlibc.bc.deflate

It would be very useful to narrow down an example that's not just the current state of librlibc, since that shifts and morphs and may happen to migrate away from the conditions required, without the fundamental bug being fixed.

(Also, just to be clear: what do you mean by "unless the crate is 'lib'"? literally that #![crate_id="rlibc"] fails but #![crate_id="lib"] works fine?)

[Tobba]

Yep

It may be a windows only issue then, it happens to every rlibc I have built, and I updated to master last night

I'll see if I can get a better test case down however

[Tobba]

Actually, it seems like the issue goes deeper, the bitcode file IS there, but the archive isnt read properly

7zip doesnt find the bitcode, neither does rustc, but llvm-ar finds it

[Tobba]

I'm starting to suspect rustc actually finds the bitcode, but other issues cause symptoms of it missing. This can be closed for now