Is cargo:rustc-link-search useless in windows?

I noticed that rustc-link-search flag in Windows does nothing obvious.
I don't know how things are in other operating systems, but in Windows I have to assign a path to PATH with my own hands, without this flag everything works fine, even transit dependencies are handled well (I thought the compiler would load dependencies twice). I assume from what is written in the article that it automatically globally assigns the path to the library only in macOS.

macOS has special consideration where if DYLD_FALLBACK_LIBRARY_PATH is not already set, it will add the default $HOME/lib:/usr/local/lib:/usr/lib .

I can't understand what exactly this flag does in Windows

rustc-link-search is relevant for the compile time linker and as such needs to be used for all libraries. LD_LIBRARY_PATH/DYLD_LIBRARY_PATH/PATH is relevant for the dynamic linker and as such needs to be used for dynamic libraries that are not at a place where the dynamic linker would look anyway and rpath isn't used. (windows doesn't support rpath, but does look for dylibs next to the executable by default)

1 Like

Thanks for the answer, as I understand it, if the OS supports rpath, then you don't need to add paths manually somewhere? Does the compiler add them automatically in these OS?

You need to explicitly tell it to use rpaths. Rustc has the -Crpath option which will male rustc set rpaths that would work for the location to which rustc emits the executable and where the dynamic libraries are when running rustc. If you move the executable and dynamic libraries relative to each other after building, you will instead have to directly tell the linker the rpath to use. For example using the -Clink-arg rustc argument to make it pass through an arbitrary argument to the linker.

Thank you for the explanation

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.