Ask questionsInvalid build when using Cargo workspaces.
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.
Answer questions calavera
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.