Re: Feature request for MinGW GCC 10 port

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============6652075795307219632==
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="vdYM2GQKaztpydwBRs4Y7nzu03H4Z7MaV"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--vdYM2GQKaztpydwBRs4Y7nzu03H4Z7MaV
Content-Type: multipart/mixed; boundary="abzjkrdngMYcGoF9Hbq1UD4ZS8y3Mm9la";
 protected-headers="v1"
From: Keith Marshall <[email protected]>
To: [email protected]
Message-ID: <624f44ea-d995-7b16-1d75-846de42d65fe-JlWs9+JhQMeJPt80KsDg5Q@public.gmane.org>
Subject: Re: [MinGW-Users] Feature request for MinGW GCC 10 port
References: <83o8ios2h0.fsf-mXXj517/[email protected]>
 <2f677270-bd9c-49d9-b564-e909406e3a47-JlWs9+JhQMeJPt80KsDg5Q@public.gmane.org> <83k0t8pgv4.fsf-mXXj517/[email protected]>
In-Reply-To: <83k0t8pgv4.fsf-mXXj517/[email protected]>

--abzjkrdngMYcGoF9Hbq1UD4ZS8y3Mm9la
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

On 23/12/2020 17:33, Eli Zaretskii wrote:
>> From: Keith Marshall <[email protected]>
>> Date: Tue, 22 Dec 2020 22:58:08 +0000
>>
>> On 20/12/2020 19:26, Eli Zaretskii wrote:
>>> Kieth,
>>
>> Misspelling my name isn't a very auspicious way to start a feature
>> request, but no matter ...
>=20
> Ouch! please accept my sincere apologies for this blunder.

Sure, no problem.

>>> I have a humble feature request, for when you find time to produce a
>>> MinGW build of GCC 10.x: would you please consider including libgccji=
t
>>> in the set of binaries?
>>
>> I've no idea when I may get around to GCC 10.x, so I've had a quick
>> look, to see what may be required to build libgccjit-0.dll for 9.2.
>=20
> FWIW, I'm told that libgccjit is full of problems before GCC 10.

Possibly.  I've got it building now, for GCC-9.2, but I don't know if it
will actually work.  Perhaps you can help me to test it?

>> It turns out that the mingw32 target is not well catered for, in the G=
CC
>> 9.2 sources.  I can get a libgccjit.so (which is actually a DLL) built=
,
>> but it needs some gross, kludgey hacks, to work around several problem=
s:
>>
>>  - specifying --enable-host-shared (as the documentation demands) make=
s
>>    the build look for libiberty.a in a nonexistent "pic" subdirectory =
of
>>    where it is actually built; after make crashes, "ln -s . pic" in th=
e
>>    real build directory kludges around this, allowing "make" to be
>>    restarted, and to progress beyond this.
>>
>>  - GCC's jit sources gratuitously use dlopen(), but neglect to include=

>>    dlfcn.h; jit-common.h needs a patch, to work around this.
>>
>>  - availability of fchmod() is gratuitously assumed; a further patch i=
s
>>    needed, to use chmod() instead.
>>
>>  - linking of the DLL gratuitously requires -lpthread, which isn't
>>    specified; I can patch the makefile fragment, to explicitly do so,
>>    but that feels kind of nasty, since it bypasses system features
>>    discovery.
>=20
> Maybe you can get some ideas by looking at what the MinGW64 folks did
> to resolve these issues.  There are, AFAICT, 2 patches:
>=20
>   https://github.com/msys2/MINGW-packages/blob/1670118e2b98e2956927d60c=
f4ca7fa3562e6b26/mingw-w64-gcc/0022-jit-port-libgccjit-to-Windows.patch
>   https://github.com/msys2/MINGW-packages/blob/1670118e2b98e2956927d60c=
f4ca7fa3562e6b26/mingw-w64-gcc/0023-gcc-jit-Rename-libgccjit.dll-to-libgc=
cjit-0.dll.patch
>=20
> At least some of the issues you mention seem to be handled by those
> patches.

I guess those are against GCC-10 sources; they mostly mimic the changes
I've made myself, but don't address my libpthread.a dependency (at all).
They do, however, go further to avoid dlopen()/dlerror()/dlclose(), than
I did, (I just delegated those to our own <dlfcn.h> implementation), and
they also replace mkdtemp() with a custom alternative, (which didn't
even arise as an issue for me, since we already have an implementation
for that).

>> With those kludges in place, I get a libgccjit.so (built according to
>> ELF link command convention, but it is actually a Windows DLL), but no=

>> corresponding import library.  The build then immediately crashes out,=

>> trying to do whatever else would normally follow.
>>
>> It's ugly, but may be enough.  What do you think?
>=20
> Well, the crash is a bummer: I wonder what exactly crashes and why?

The DLL build completes, but JIT then proceeds to resolve a dependency
on the installed build GCC, and the dependency is incorrectly specified
in the gcc/Makefile.in; fixing that lets the build run to completion.

> Is the produced libgccjit functional?

I don't know.  I suspect that the testsuite will be inadequate, when
cross compiling, and I don't know how to test it, otherwise.

> The dependency on pthreads is also unfortunate, as that many times
> conflicts with w32api headers and creates build problems.  It would be
> good to avoid that dependency, if possible.

It arises because the JIT context is gratuitously guarded by a POSIX
mutex lock.  Perhaps that could be converted to a Windows alternative,
(critical section, maybe); perhaps GCC-10 already does so, because the
patches you pointed me to do nothing to address this.

>> If you would like me to pursue this further, for future GCC
>> releases, perhaps you would be so kind as to file a formal feature
>> request ticket:
>> https://mingw.osdn.io/index.html?page=3Dcontact.html#feature-request
>=20
> Done, thanks.

Thanks.  I suggest we keep further discussion on the ticket, where we
can also make binaries available for download/exchange.

--=20
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F


--abzjkrdngMYcGoF9Hbq1UD4ZS8y3Mm9la--

--vdYM2GQKaztpydwBRs4Y7nzu03H4Z7MaV
Content-Type: application/pgp-signature; name="OpenPGP_signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="OpenPGP_signature"

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEEwZ7AGBVH3lDh1I9TwK02xjR+Wj8FAl/j2w8FAwAAAAAACgkQwK02xjR+Wj+8
vQ/7BhDdR/kpSUZ3sgh1FO281eFQCNW7wzqcrZQviUUVylec8WvrzukpGuGayzPdCQe3otTXj+na
Bhyv2ZAYw/EsjRZ2Rn29coP2ol+7OdDfYeVxHn8/YVYb7HHTkT2at+VWK9AeSU91GqXa4QzP1VhB
dngZxQubBLQMiZiCpKyqyY77In92+G/khIkl6HC6W69ljqjALXs4QW0lHfKl0d4R7AMixcP8unqg
qCCPD1IqxXJoaRf6gFlcLw1DJ8CFZWf00YneOQX1CHncnE34RadHLKU9l9Jwsp36xRcF/c1TCRfJ
4eT/OwpyvI+a84atejICsYG0+UMpB9qPYehrTGQCrAmRMVjC5eCCqkMkkKOkvyVxxpwos5U8ubJ2
eu3MLZ92dVVTupvvB4p4DGdpYbms5TjgDuTRebC7yDugxwJBFj9g7uEms4aHrtRr5UBondhe+zMP
HibANU+feEpoIGiN4JDVoBYFRC+ZTafAJ4vLCPy1vDC4I/44QjizfXsmShE8Y+j4nEg9GzNPXXe8
/rKRozqNLJfXGNTnGRt7veDqeSt/Tauria+alVuf7Gxg9CbG0y1jz1yg4i00aqrYNsUCYj5gJVjr
tUnsn+JvZ1DDHzzA9TFS03w9HW+/FZ1vlN5TLWY/bGfYJ0EpWC1pTN4EZ2L7jeI21XylSDj+ESSj
P0E=
=urmP
-----END PGP SIGNATURE-----

--vdYM2GQKaztpydwBRs4Y7nzu03H4Z7MaV--


--===============6652075795307219632==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTWluR1ctVXNl
cnMgbWFpbGluZyBsaXN0Ck1pbkdXLVVzZXJzQGxpc3RzLm9zZG4ubWUKClRoaXMgbGlzdCBvYnNl
cnZlcyB0aGUgUG9zdGluZyBFdGlxdWV0dGUsIGFzIGRlc2NyaWJlZCBhdCBodHRwczovL21pbmd3
Lm9zZG4uaW8vaW5kZXguaHRtbD9wYWdlPW1haWxpbmcuaHRtbCNsaXN0LWV0aXF1ZXR0ZS4KV2Ug
YXNrIHRoYXQgeW91IGJlIHBvbGl0ZSBhbmQgZG8gdGhlIHNhbWUuICBEaXNyZWdhcmQgZm9yIHRo
ZSBsaXN0IGV0aXF1ZXR0ZSBtYXkgY2F1c2UgeW91ciBhY2NvdW50IHRvIGJlIG1vZGVyYXRlZC4K
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCllvdSBtYXkg
Y2hhbmdlIHlvdXIgTWluR1cgQWNjb3VudCBPcHRpb25zIG9yIHVuc3Vic2NyaWJlIGF0OgpodHRw
czovL2xpc3RzLm9zZG4ubWUvbWFpbG1hbi9saXN0aW5mby9taW5ndy11c2VycwpBbHNvOiBtYWls
dG86bWluZ3ctdXNlcnMtcmVxdWVzdEBsaXN0cy5vc2RuLm1lP3N1YmplY3Q9dW5zdWJzY3JpYmU=

--===============6652075795307219632==--