Invalid build when using Cargo workspaces.

[calavera]

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.

[danielpclark]

:thinking: interesting. So you have a working solution but you're hoping for a better one; correct?

[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.

[calavera]

It looks like the real issue is this: https://github.com/rust-lang/rust/issues/46369. I tested my project using cdynlib and it creates the object correctly with both projects in the workspace.