On Tuesday, 3 July 2018 at 17:54:08 UTC, Seb wrote:
> On Tuesday, 3 July 2018 at 15:10:34 UTC, Chris M. wrote:
>> On Tuesday, 3 July 2018 at 14:38:53 UTC, Mike Parker wrote:
>>> On Tuesday, 3 July 2018 at 13:32:21 UTC, Chris M. wrote:
>>>
>>>>
>>>> After hashing it out with some people on the Discord, I'm fairly certain we narrowed it down to the 64-bit user32.lib from mingw missing these functions.
>>>>
>>>> https://issues.dlang.org/show_bug.cgi?id=19051
>>>
>>> So are the mingw libs only shipped in the zip file? I don't have them with the installer version of 2.080.0, nor lld for that matter. But I see them in the zip for the 2.081.0 RC.
>>
>> Seems to be an option in the 2.080.1 installer (which I ignored before since I wasn't entirely sure how things worked on Windows), not sure about previous versions though.
>
> BTW in case someone has a bit of time to look at the MinGW headers. They are built as part of the `build-mingw-libs` branch at the installer repo:
>
> https://github.com/dlang/installer/blob/build-mingw-libs/windows/build_mingw.bat
>
> This is automated via AppVeyor:
>
> https://github.com/dlang/installer/blob/build-mingw-libs/appveyor.yml
>
> And it's added to the zip here:
>
> https://github.com/dlang/installer/blob/master/create_dmd_release/build_all.d#L505
>
> I think the installer detects whether Visual Studio is installed or nor, but I'm not sure on this (I don't use Windows).

https://sourceforge.net/projects/mingw/files/MinGW/Base/w32api/w32api-5.0.2/

Looks like there's a user32.def file in the src package that does not have these two functions defined. Not too sure how this vcvars64.bat file builds the 64-bit libraries from this, but I think I'll have to open a ticket with the mingw devs to have them be added (or see if they have a good explanation).

On Tuesday, 3 July 2018 at 18:24:47 UTC, Chris M. wrote:
> On Tuesday, 3 July 2018 at 17:54:08 UTC, Seb wrote:
>> [...]
>
> https://sourceforge.net/projects/mingw/files/MinGW/Base/w32api/w32api-5.0.2/
>
> Looks like there's a user32.def file in the src package that does not have these two functions defined. Not too sure how this vcvars64.bat file builds the 64-bit libraries from this, but I think I'll have to open a ticket with the mingw devs to have them be added (or see if they have a good explanation).

Sorry, looks buildsdk.d does the actual building, not vcvars64.bat

On 04/07/2018 6:24 AM, Chris M. wrote:
> Looks like there's a user32.def file in the src package that does not have these two functions defined. Not too sure how this vcvars64.bat file builds the 64-bit libraries from this, but I think I'll have to open a ticket with the mingw devs to have them be added (or see if they have a good explanation).

Those files are for 32bit only.

See[0] for 64bit versions under the directory mingw-w64-crt/lib64.

[0] https://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/mingw-w64-v5.0.4.zip/download

On Tuesday, 3 July 2018 at 17:54:08 UTC, Seb wrote:
> BTW in case someone has a bit of time to look at the MinGW headers. They are built as part of the `build-mingw-libs` branch at the installer repo:
>
> https://github.com/dlang/installer/blob/build-mingw-libs/windows/build_mingw.bat
>
> This is automated via AppVeyor:
>
> https://github.com/dlang/installer/blob/build-mingw-libs/appveyor.yml
>
> And it's added to the zip here:
>
> https://github.com/dlang/installer/blob/master/create_dmd_release/build_all.d#L505
>
> I think the installer detects whether Visual Studio is installed or nor, but I'm not sure on this (I don't use Windows).

AFAICT, the issue is that MinGW is used, as opposed to MinGW-w64 (a confusingly separate project unfortunately AFAIK). There's no SetWindowLongPtr for Win32, it's #defined as SetWindowLong. The 64-bit user32.def of MinGW-w64 contains it [1], while it's missing in the MinGW .def file [3] and the 32-bit MinGW-w64 one [2].

[1] https://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-crt/lib64/user32.def
[2] https://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-crt/lib32/user32.def
[3] https://sourceforge.net/p/mingw/mingw-org-wsl/ci/5.0-active/tree/w32api/lib/user32.def

On Tuesday, 3 July 2018 at 18:35:43 UTC, kinke wrote:
> On Tuesday, 3 July 2018 at 17:54:08 UTC, Seb wrote:
>> [...]
>
> AFAICT, the issue is that MinGW is used, as opposed to MinGW-w64 (a confusingly separate project unfortunately AFAIK). There's no SetWindowLongPtr for Win32, it's #defined as SetWindowLong. The 64-bit user32.def of MinGW-w64 contains it [1], while it's missing in the MinGW .def file [3] and the 32-bit MinGW-w64 one [2].
>
> [1] https://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-crt/lib64/user32.def
> [2] https://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-crt/lib32/user32.def
> [3] https://sourceforge.net/p/mingw/mingw-org-wsl/ci/5.0-active/tree/w32api/lib/user32.def

What are next steps then?

On Wednesday, 4 July 2018 at 20:36:55 UTC, Chris M. wrote:
> On Tuesday, 3 July 2018 at 18:35:43 UTC, kinke wrote:
>> On Tuesday, 3 July 2018 at 17:54:08 UTC, Seb wrote:
>>> [...]
>>
>> AFAICT, the issue is that MinGW is used, as opposed to MinGW-w64 (a confusingly separate project unfortunately AFAIK). There's no SetWindowLongPtr for Win32, it's #defined as SetWindowLong. The 64-bit user32.def of MinGW-w64 contains it [1], while it's missing in the MinGW .def file [3] and the 32-bit MinGW-w64 one [2].
>>
>> [1] https://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-crt/lib64/user32.def
>> [2] https://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-crt/lib32/user32.def
>> [3] https://sourceforge.net/p/mingw/mingw-org-wsl/ci/5.0-active/tree/w32api/lib/user32.def
>
> What are next steps then?

Probably something along the lines of

1) cloning the repo
2) preparing the environment so that build_mingw.bat works locally
3) downloading MinGW-w64 archive in build_mingw.bat
4) adapting paths in buildsdk.d
5) fix until working
6) check if other scripts need to be adapted too (packaging etc.)
7) open GitHub PR