Question: Is 1.0.63 (progressive linking?) a breaking change?

[jrobhoward]

I've experienced recent problems building rust-rocksdb after the upstream (cc-rs) dependency started resolving to version 1.0.63.

• When it consumes 1.0.63 (default behavior / semver thinks it is compatible), the linking complains about undefined symbols
• rust-rocksdb does build fine, if I update my Cargo.toml file to consume a fixed version of 1.0.62
• If you're interested in more details, please see issues/479

I don't know enough about the progressive linking change (commit id=e4ff87239325e7f9fe1f2b21a979b947f6f7503e), to tell if this is expected behavior (e.g. rust-rocksdb should be using cc-rs differently), or if there is an actual bug/regression in cc-rs itself.

Thanks in advance, for any information you can provide.

[alexcrichton]

Thanks for the report and sorry for the breakage! This seems highly likely to be due to #564 indeed, although that was not supposed to be a breaking change. The intention is that we add 100 objects at a time to the final archive instead of all-at-once which can blow command line length limits for lots of object files.

Do you know if there's anything special about the targets you're compiling for? Or perhaps a unique toolchain? I think the ar invocations are right but I'm not 100% sure.

[alexcrichton]

cc @maxded as well as the author of the original PR

[alexcrichton]

Ah I see the issue, rocksdb has two objects called format.o and two objects called merge_operator.o. With the previous all-in-one command line they were all showing up in the output but now with incrementally building the *.a file they're replacing each other and only one is showing up (and the second object file is replacing the first).

I've got a fix locally I'll post soon.

[maxded]

Ah sorry! An oversight on my behalf, apologies for the inconvenience. Thanks, @alexcrichton for the quick investigation.

[alexcrichton]

No worries, this was one that's pretty surprising if you can predict it ahead of time :)

[jrobhoward]

Thanks @alexcrichton & @maxded, for the fast responses.
I did want to follow-up and say that I am still getting undefined symbols, even when consuming v1.0.64.

I'm not sure if the cargo build output (posted in the link) is going to be sufficient (though the reproduction steps are fairly straightforward). Is there anything I can do to help confirm that ar is getting called with the proper flags?

[alexcrichton]

Oh dear, sorry about that! I tested the OP of your issue and 1.0.64 works for me, but I'm running on macOS, not Linux. I'll test on Linux later today and see if ar does the same thing with the q flag that it does on mac.

[alexcrichton]

Ok turns out Linux is indeed different. I believe #570 should work for Linux.