Invalid build when using Cargo workspaces.
calavera opened this issue · 3 comments
I bumped into an interesting issue with Cargo workspaces.
I have a repository with two Rust libraries, one of them is the "core" library where I have a bunch of shared code. The other library is a ruby gem built with Rutie.
When I put both libraries in the workspace, the generated dynamic library includes a reference to libstd
, which cannot be resolved in my system because I don't have anything set in LD_LIBRARY_PATH. That dynamic library won't work when it's loaded by the Ruby bindings.
ldd ../target/release/libtraffic_mesh_ruby.so
linux-vdso.so.1 (0x00007ffde239e000)
libstd-4a76ff35a356aedf.so => not found
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f0967c25000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0967a06000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f09677ee000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f09673fd000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f096705f000)
/lib64/ld-linux-x86-64.so.2 (0x00007f09685eb000)
If I put the "core" inside the workspace, but I exclude the Rutie library, the dynamic library generated doesn't include the reference to libstd
and it works (as far as I can tell, I still have to add tests to the ruby part).
ldd target/release/libtraffic_mesh_ruby.so
linux-vdso.so.1 (0x00007ffdf47fe000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbd0485a000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fbd04652000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fbd04433000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fbd0421b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbd03e2a000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbd052ff000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fbd03a8c000)
So the workaround to solve this problem is to have the Rutie library in the Cargo workspace like this:
[workspace]
members = ["core"]
exclude = ["ruby-lib"]
I'm not familiar with the build toolchain, but I'd expect to be a better solution to this problem.
🤔 interesting. So you have a working solution but you're hoping for a better one; correct?
I think it's unexpected that putting both projects in a workspace makes the shared object not valid anymore. This workaround also creates two target directories, which is not ideal.
It looks like the real issue is this: rust-lang/rust#46369. I tested my project using cdynlib
and it creates the object correctly with both projects in the workspace.