I am currently working on a project at work which requires me to dynamically link in the standard library. I have been able to get my libs and exe to dynamically link the stdlib as planned, but I've hit a bit of a snag trying to actually get the libstd into the build output.
Currently I am resorting to a build script which tries to find the libstd and copy it over to the output folder, but it isn't going very well, namely because I need to support compiling on the local system (windows pc) and cross compiling for our embedded targets using cross, both of which keep the libstd in different places, with different extensions, etc.
Is there a reason why the libstd dynamic library isn't copied to the build output anywhere when we dynamically link to it?
When you dynamically link to the standard library, it is assumed the library is already properly installed in your system (as with other shared libraries). If this is not the case for your system (why are you then using dynamic linking?) then you need to install the standard library alongside your build output.
How would you install the standard library if not through deployment or installing the build tools?
I need to dynamically link the stdlib and then deploy it to my embedded device, the only way I found to do that is to search for a file with "std" in the name and the proper extension located in the directory {LD_LIBRARY_PATH}/rustlib/{TARGET}/lib/ from a build script.
If it was copied to my deps folder automatically, ideally with specific name, then I wouldn't even need a build script in my case, and I could just make a simple copy script.
As @jethrogb's parentheticals were alluding: If you need to deploy your own copy of std alongside your binary, then most of the benefits of dynamic linking don't apply. With static linking, there would be no separate file to deploy in the first place, because it'd all be in the same binary.
So why does your project require dynamically linking std?
The standard library uses static state for a few things (namely, calculation of the thread id), if I don't dynamically link it into all of my binaries, that state isn't unique which causes crossbeam-channels not to work.