winegcc library creation/import broken

[Alexandre Julliard]

Peter Dons Tychsen <donpedro.list at 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.
>
> 1) In one of my projects i generate a library with winegcc.
> This one had problems linking to my until i fixed it with LoadLibrary().
>
> 2) 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.

-- 
Alexandre Julliard
julliard at winehq.org