On 6/28/21 5:46 PM, Zebediah Figura (she/her) wrote:
On 6/28/21 8:05 AM, Jacek Caban wrote:
On 6/28/21 5:51 AM, Zebediah Figura (she/her) wrote:
On 6/25/21 7:38 AM, Jacek Caban wrote:
On 6/23/21 8:38 PM, Alexandre Julliard wrote:
And honestly, building our dependencies as PE and linking them statically would make things so much easier for everybody, that there would need to be strong practical reasons to go out of our way to start relying on distro packages for this. A general dislike of the approach is not good enough IMHO.
I agree that it's a good way to move forward.
To implement it, we will need to build dependencies with winegcc (rather than plain mingw). I did experiment with it last year, you may see it here:
https://github.com/cjacek/wine-addons
While the build system itself is just a rough draft and needs rethinking, it shows how to build static libs with winegcc (it links them into standalone PE files, but they should be ready to statically link to Wine modules as well).
We will probably also need such static libs to be more portable by getting rid of libgcc dependency, but that's a latter step.
I remember a discussion a while ago, but why exactly do we need winegcc rather than plain mingw?
Those are just different CRTs. We use msvcrt/ucrt importlib in Wine with tiny additions of static parts of msvcrt and winecrt0. mingw-w64 has a ton of additions and depends on msvcrt importlib, libmingwex.a and libmingw32.a combination. You can't mix them in general (and there is no reason to).
I'm still missing something; shouldn't a shared library built with mingw stand alone? Why would it matter what import library + CRT version + crt0 library the rest of the source is built with?
It matters a lot less for shared libraries, but we're talking about using static libraries.
Jacek