lu-zero/cargo-c

Libraries that aren't in libdir should not be moved to bindir on Windows

nirbheek opened this issue · 5 comments

Currently if you specify an install_subdir for a library, on Windows the .lib, .dll.lib and .def will be installed into $prefix/lib/$subdir but the .dll will be installed into $prefix/bin/$subdir.

This is surprising, and also not wanted when building, for example, plugins. You only want to do that for DLLs that applications link to, and hence might load from PATH at runtime. This should only happen with import libraries that are in libdir or other directories in the linker path.

In Meson, we only do this automatic transporting of the DLL if the library is installed into $libdir. Maybe cargo-c can do the same? It's a good heuristic and we've had no complaints about it.

For that we'd need a way to specify that a library should be a "module" or "plugin" and not a "library", or do I misunderstand you?

No, in Meson we do this for all libraries. Differentiating module / plugin and library is a different thing and another way of fixing this, but it has more complicated per-platform consequences. For instance, modules / plugins are allowed to have undefined symbols that the loader will provide, and there's per-platform quirks around that. It's a can of worms :)

Sounds interesting, probably we could copy this heuristic, do you have a link about it so I can refer to it in the Readme?

Meson doesn't have a document explaining this, but here's the code:

  1. shared_lib_dir on Windows is bindir
  2. Import library dir is libdir (.lib .dll.a .def)
  3. If the library install dir is custom (i.e., != shared_lib_dir), put the import library in the custom install dir for the DLL

I don't know what things look like inside cargo-c, i.e., whether you special-case DLLs or special-case import libraries.

Let see if this approach works for you and the logic is not wrong. Please look at the code and test it to confirm it is working as intended. Then I'll add a line in the documentation about it :)