Peter Dons Tychsen donpedro.list@gmail.com writes:
Hi and thanks for clarifying,
I don't know if/when it will be fixed. I understand that direct Unix linking is convenient, but it's not the way Windows does it. We may want instead to work on making it easier to work with import libs and use proper Windows imports.
OK. I am still not sure about the exact rules with winegcc generated libraries vs normally generated libraries.
- In one of my projects i generate a library with winegcc.
This one had problems linking to my until i fixed it with LoadLibrary().
- The same project (inside the library) uses other libraries
generated with normal gcc. They do not have the problem, and do not need LoadLibrary() to work. I e.g. use libusb-1.0 this way without problems.
a) Why the difference? Is it because the LoadLibrary() also invokes LoadLibrary() for child libraries of the library?
Libraries built with winegcc import Windows APIs, so they have a Windows import table that needs to be resolved by LoadLibrary. Potentially the libraries it imports are in PE format, so there's no way that the Unix loader can resolve them.
A pure Unix library like libusb doesn't call Windows APIs, so there's no issue.
If that's the case, can Wine (wineloader i guess) not just detect UNIX style loading of libraries and then call LoadLibrary() for each of them automatically.
Yes, something like that. Patches are welcome ;-)
b) Also, if Wine just wants to use import libs and Windows imports, will that not sort of kill wine-lib and winegcc? They way e.g. i use it is to slap an existing Windows GUIs on top of UNIX program and libraries. My UNIX libs do not have import libs and such.
You can link to Unix libs without problem. What you cannot do is link in the Unix sense to a Windows dll built in .so format, because the Wine loader needs to be told about that .so dll.