winegcc library creation/import broken

[Peter Dons Tychsen]

Hi AJ,
> Because of the loader changes needed to support PE builtins, importing a
> Winelib library directly at the Unix level is currently broken. It may
> be reimplemented at some point, but that's not trivial.
> You can still link to a library at the Unix level (as opposed to
> building an import library and linking to that), but you have to tell
> Wine explicitly about the loaded library. This can be done by adding a
> LoadLibraryA("libtest.so") at the start of your app.

Has anyone tried this recently? Are there any examples of this still working?

I tried to insert LoadLibraryA("libtest.so") with success, but this
did not change anything. Still the same crash.

Thanks,

/pedro

[Peter Dons Tychsen]

Hi Again,

Den søn. 14. mar. 2021 kl. 10.26 skrev Peter Dons Tychsen
:
> Hi AJ,
> > Because of the loader changes needed to support PE builtins, importing a
> > Winelib library directly at the Unix level is currently broken. It may
> > be reimplemented at some point, but that's not trivial.
> > You can still link to a library at the Unix level (as opposed to
> > building an import library and linking to that), but you have to tell
> > Wine explicitly about the loaded library. This can be done by adding a
> > LoadLibraryA("libtest.so") at the start of your app.
>
> Has anyone tried this recently? Are there any examples of this still working?
>
> I tried to insert LoadLibraryA("libtest.so") with success, but this did not change anything. Still the same crash.

And i am not using an import library, just linking directly with the
library, and then confirming it with LoadLibrary() as you suggested
(which is successfully loaded).

Could i be using the wrong compiler flags or something? My example is
fairly trivial.

Thanks,

/pedro

[Peter Dons Tychsen]

Hej again AJ,

OK. I have made an example that shows the problem here:
https://drive.google.com/file/d/1R4iIUkOTEP9dczwpUjqgApHE2W51gLwK/view?usp=s...

https://drive.google.com/file/d/1B-EgplAnMhx_31y5j4Q2Aa6SAx2VW3oe/view?usp=s...

Its a very simple app and lib. Just run "./build.sh" to build both and
see the problem.

It includes your suggestion with LoadLibrary(), which seems to make no
difference.

The make-files are based off winemaker, and are very simple.

Any tips on getting this working would be great.

Thanks,

Den søn. 14. mar. 2021 kl. 10.33 skrev Peter Dons Tychsen
:
> Hi Again,
>
> Den søn. 14. mar. 2021 kl. 10.26 skrev Peter Dons Tychsen
> :
> > Hi AJ,
> > > Because of the loader changes needed to support PE builtins, importing a
> > > Winelib library directly at the Unix level is currently broken. It may
> > > be reimplemented at some point, but that's not trivial.
> > > You can still link to a library at the Unix level (as opposed to
> > > building an import library and linking to that), but you have to tell
> > > Wine explicitly about the loaded library. This can be done by adding a
> > > LoadLibraryA("libtest.so") at the start of your app.
> >
> > Has anyone tried this recently? Are there any examples of this still working?
> >
> > I tried to insert LoadLibraryA("libtest.so") with success, but this did not change anything. Still the same crash.
>
> And i am not using an import library, just linking directly with the
> library, and then confirming it with LoadLibrary() as you suggested
> (which is successfully loaded).
>
> Could i be using the wrong compiler flags or something? My example is
> fairly trivial.
>
> Thanks,
>
> /pedro

[Alexandre Julliard]

Peter Dons Tychsen  writes:
> Hej again AJ,
>
> OK. I have made an example that shows the problem here:
> https://drive.google.com/file/d/1R4iIUkOTEP9dczwpUjqgApHE2W51gLwK/view?usp=s...
>
> https://drive.google.com/file/d/1B-EgplAnMhx_31y5j4Q2Aa6SAx2VW3oe/view?usp=s...
>
> Its a very simple app and lib. Just run "./build.sh" to build both and
> see the problem.
>
> It includes your suggestion with LoadLibrary(), which seems to make no
> difference.

The problem in your example that you have two copies of lib.dll.so, one
that is imported implicitly and one that is loaded by LoadLibrary, so it
gets loaded twice. You have to make sure that the dll loaded by
LoadLibrary is exactly the same as the one that was imported at the Unix
level.

[Peter Dons Tychsen]

Hi AJ,

Thanks for you comments,
> The problem in your example that you have two copies of lib.dll.so, one
> that is imported implicitly and one that is loaded by LoadLibrary, so it
> gets loaded twice. You have to make sure that the dll loaded by
> LoadLibrary is exactly the same as the one that was imported at the Unix
> level.

In the example i sent there is only 1 DLL at any time.

I even copy the DLL to a specific location before linking it with the app,
and the same location is used for LoadLibrary().

So not only is there only 1 library, but the same location is used for linking,
and for loading the library inside the app.

Did you try the example? I simply cannot get it to work. Are you sure its not
just broken currently with all the loader changes?

Thanks,

/pedro

[Peter Dons Tychsen]

Hi again
> I even copy the DLL to a specific location before linking it with the app,
> and the same location is used for LoadLibrary().

Ah, found a bug in the makefile that referenced lib/lib.dll.so instead
of ./lib.dll.so.
(probably what you already found).

This makes it work again! Thanks!

Do you have any idea if/when this will be fixed in later versions so
we do not need the LoadLibrary() workaround?

Thanks,

/pedro

[Alexandre Julliard]

Peter Dons Tychsen  writes:
> Hi again
> > I even copy the DLL to a specific location before linking it with the app,
> > and the same location is used for LoadLibrary().
>
> Ah, found a bug in the makefile that referenced lib/lib.dll.so instead
> of ./lib.dll.so.
> (probably what you already found).
>
> This makes it work again! Thanks!
>
> Do you have any idea if/when this will be fixed in later versions so
> we do not need the LoadLibrary() workaround?

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.

[Peter Dons Tychsen]

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?
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.

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.

Thanks for time and inputs,

/pedro

[Alexandre Julliard]

Peter Dons Tychsen  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.