On Tue, Aug 10, 2021 at 11:19 PM Nick Bowler <nbow...@draconx.ca> wrote: > > On 2021-08-10, Vincent Torri <vincent.to...@gmail.com> wrote: > [...] > > As I have said, the problem is not the lib itself. There is no problem > > with the lib. The problem is with the binary : when I compile it, > > there is no way to know if the library, that the binary uses, is a > > static library or shared library (know == having a macro to > > distinguish shared lib and static lib) > > I'm not too familiar with shared libraries on Windows, but I think > mingw solves this particular problem by generating static wrapper libs > with stub functions that then call the real implementation in the dll.
I guess that you are talking about the import library (which could be created with gcc on Windows). Import libraries can also be built with Visual Studio. > With such a wrapper, I suppose there is no difference (from the program's > perspective) between linking against the real static archive versus > linking against the wrapper. When using mingw and libtool simple > libraries appear to "just work" at least. > > Without such a wrapper I suppose you will need to know at compile time > which libraries will be used in the future at link time. I don't think > libtool can make any assumptions here in general, as link options are > not typically passed to compile mode commands (and in fact, many libtool > options are overloaded to mean different things depending on whether you > are running it in compile or link mode). ok, so no perfect solution > It all seems very annoying indeed. I wonder how Windows users deal with > this. Well, if you have a Visual Studio solution (either hand-written, or created with a meta build-system like cmake or meson), you explicitly write the link command. The only solution I can see is : forcing to have only one specific library. either static or shared, and throw an error if the wrong lib is chosen at configure time. And as I prefer DLL compared to static lib, I know what to do :-) thank you Vincent Torri
