cc 1.0.86 changes placement of .a files in an incompatible manner, but only when used in cargo install

[scouten-adobe]

Discovered that a public crate I maintain (https://github.com/adobe/xmp-toolkit-rs) that uses cc suddenly stopped building today, but only when it is used by a downstream crate and then only when the downstream crate is built using cargo install.

I've confirmed that pinning the cc release to 1.0.83 "fixes" the problem and am working on an emergency release.

Some additional info here (adobe/xmp-toolkit-rs#194 (comment)). If needed, I can work on building a repro case in a day or two if that would be helpful.

A quick bit of context before I have to sign off. xmp-toolkit-rs has a rather complicated build process that assembles object files from three different libraries, each with wildly different requirements for C vs C++ build flags and then links them together. It depends on the location of the intermediate .o files as part of the build process and those files appear to have moved (again, only in the downstream cargo install case) between 1.0.83 and 1.0.86.

The error surfaced in this part of the build.rs code for xml-toolkit-rs: https://github.com/adobe/xmp-toolkit-rs/blob/76ba3ba32a46e9e2b6262c8b457449f422cda7b9/build.rs#L171-L199

[NobodyXu]

It's probably related #914 , it changes the object filename to always include hash of the dirname.

It used to only include hash if file.has_root() or if file contains .. in components.

[NobodyXu]

It depends on the location of the intermediate .o files as part of the build process and those files appear to have moved (again, only in the downstream cargo install case) between 1.0.83 and 1.0.86.

Honestly it is not a good idea to depend on filename within object file.

Not even a good idea before #914 is merged, since we use std::collections::hash_map::DefaultHasher, which does not guarantee a stable hash result since it is initialised with a random state, and it also does not provide any guarantee on the hash algorithm it uses between different rustc/stdlib version.

[NobodyXu]

Ideally you probably don't want to depend on object name in the archive.

If you have to do so, then you could add a new API to cc, to specify the function cc::Build uses to generate the object name.