My unfortunate experience is that changing the default just breaks other things.
I really blame C++ as the root evil. This type of behavior really really ought to be part of the language spec. It’s super weird that it’s not.
> How is [foo.imp.lib] file created?
When the DLL is compiled
> I don't really see the benefit of linking against foo2.15.imp.lib compared to foo2.15.dll
The short version is “because the whole file isn’t actually necessary”.
Zig moves mountains to make cross-compiling possible. Linux is BY FAR the hardest platform to crosscompile for. macOS and Linuxate trivial. Linux it’s alllllmost impossible. Part of their trick to make it possible is to generate stub .so files which are effectively import libs. Which is what should have been used all along! https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
> When you link against a symbol that was last changed in 2.15, you link against glibc2.15, not against glibc2.40. If you only use symbols from glibc2.15, then you have effectively linked the complete program against glibc2.15.
It really really needs to be explicit. It’s otherwise impossible to control. And hard to understand where a newer symbol is coming from.
> on Windows you put the libraries into 'C:\Program Files\PROGRAM\'
It is relatively rare for a program in Program Files to add itself to the PATH.
> they should have at least the decency to roll it in /opt
I think folders like /opt and /usr/lib are pure evil. Programs should include their %{#^]{}^]+}*}^ dependencies.
uv solves a lot of the Python problems. Every project gets to define its own version of Python and own collection of libraries with whatever god forsaken version resolution. Having /usr/lib/python3.x is a failure state.