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/ (0x00007ffde239e000) => not found => /lib/x86_64-linux-gnu/ (0x00007f0967c25000) => /lib/x86_64-linux-gnu/ (0x00007f0967a06000) => /lib/x86_64-linux-gnu/ (0x00007f09677ee000) => /lib/x86_64-linux-gnu/ (0x00007f09673fd000) => /lib/x86_64-linux-gnu/ (0x00007f096705f000)
        /lib64/ (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/ (0x00007ffdf47fe000) => /lib/x86_64-linux-gnu/ (0x00007fbd0485a000) => /lib/x86_64-linux-gnu/ (0x00007fbd04652000) => /lib/x86_64-linux-gnu/ (0x00007fbd04433000) => /lib/x86_64-linux-gnu/ (0x00007fbd0421b000) => /lib/x86_64-linux-gnu/ (0x00007fbd03e2a000)
        /lib64/ (0x00007fbd052ff000) => /lib/x86_64-linux-gnu/ (0x00007fbd03a8c000)

So the workaround to solve this problem is to have the Rutie library in the Cargo workspace like this:

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.


Related questions

No questions were found.
Github User Rank List