conda-forge / conda-forge/conda-forge.github.io
Windows library naming conventions
- Dominant language
- JavaScript
- Stars
- 170
- Forks
- 320
- Avg merge
- 2d 10h
- Merged PRs (30d)
- 5
Description
### Your question:
On Unix, we have reasonably standard naming conventions: `-l{name}` generally maps to `lib{name}.so` (or `lib{name}.dylib`, plus SONAMEs) and `lib{name}.a`. Unfortunately, Windows with MSVC doesn't seem to follow a single convention. Per the comments in https://github.com/conda-forge/blis-feedstock/pull/43#discussion_r2515762930, I'd like to open a more general discussion on how to deal with that.
The way I understand it, there are two main problems here:
1. You can't link directly to a dynamic library (`.dll`). You need to link to an import library instead, and that library uses the same format and suffix as a static library (both `.lib`), so they need to be distinguished by filename.
2. `-l{name}` maps onto `{name}.lib`.
What seems to be rather consistent is using `{name}.lib` as the import library name, so that `-l{name}` links to the dynamic library (except for some historic cases such as `libprotobuf.lib`). However, the rest doesn't seem particularly consistent.
The "pure" MSVC convention for the dynamic library would be to use a matching `{name}.dll`, but some packages are using `lib{name}.dll` instead. On top of that, we have different approaches to applying SOVERSION: some libraries just don't use it at all, others use conventions such as `*-{sover}.dll` or `*.{sover}.dll`.
Technically, the exact convention doesn't matter much here — the library name is stored in the import library, so the linker is happy with whatever we choose. However, changing it at any point implies breaking executables that are linking to it (which is solved by rebuilding, except for programs compiled by the user directly). Furthermore, if we choose to diverge from upstream convention, we're risking incompatibility with precompiled binaries (probably not that much of a concern).
With static libraries, it's even worse. Some packages are using `lib{name}.lib` (when using `{name}.lib`), which is not exactly the most transparent solution. Others are using names such as `{name}static.lib`, `{name}_static.lib` and similar.
The exact questions I'd like to pose are:
1. What should be our recommendations for naming conventions? In particular, if we are submitting fixes to missing Windows support upstream, which style should be recommended?
2. Should we follow upstream conventions when there are some, or force our own conventions instead?
3. If the latter, should we try to submit changes upstream?
CC @h-vetinari @isuruf @jaimergp
Contributor guide
Assessment
This issue has not been assessed yet.