cargo regression: cdylib output path changed

[Dushistov]

I use:

$ cargo --version
cargo 0.16.0-nightly (6e0c18c 2017-01-27)

Before that version cargo create cdylib in path like this:
target/release/libhelpers_py.so at now it changed to target/release/deps/libhelpers_py-4bae97ef34a93c7e.so.

The path is important for me, because of my two use cases:

1. Use rust code from python, to do that I place symlink to .so library
   in the same directory as python script, and this works like a charm,
   I run cargo build and start python script nothing more,
   at now I have to recreate symlink after every new commit?
2. I use rust code from java on android, build tool for java gradle,
   run cargo build --target=arm-linux-androideabi --release and grab
   output ".so" library, at now I have to write smart gradle script to list
   directory and find file by mask?

[alexcrichton]

Thanks for the report! Can you check beta/nightly to see if the bug is fixed there for you?

[alexcrichton]

I suspect this was fixed by #3478, but just want to confirm. Definitely an unintentional regression!

[Dushistov]

Can you check beta/nightly to see if the bug is fixed there for you?

yes cargo from rustup default beta:

$ cargo --version
cargo-0.17.0-nightly (dfc0f95 2017-02-01)

fix this bug for me,

is it possible to backport bugfix to stable cargo in terms of rustup?

[alexcrichton]

Ok, thanks for checking!

It's certainly possible for us to make another point release (1.15.2) but it's unclear whether the issue is severe enough to do so. For now I believe that target/release/deps/libhelpers_py.so also exists, so could both locations be checked?

[Dushistov]

It's certainly possible for us to make another point release (1.15.2) but it's unclear whether the issue is severe enough to do so. For now I believe that target/release/deps/libhelpers_py.so also exists, so could both locations be checked?

Actually, after I not found ".so" in usual place, I ran find target -name "*.so" and it show only:

$ find target/ -name "*.so"
target/release/deps/libptest_py-e4bb40c243c4e2ec.so

So no, there is no libptest_py.so, may be you not remove target directory before checking,
and there were old artifacts?

[alexcrichton]

Hm ok so the regression is worse than I thought :(

I think a "fix" should be to avoid the use of workspaces, but that's obviously not exactly a great fix...

[Dushistov]

At now, with rustc 1.19.0 and cargo 0.20.0 (a60d185c8 2017-07-13) all works fine.