Classic legacy MinGW builds currently broken

[mback2k]

My classic builds using legacy MinGW are currently broken. I am going to try to investigate this myself, but posting this for reference here anyway:

vtls/schannel.c:295:16: error: 'ALG_CLASS_DHASH' undeclared (first use in this function)
   CIPHEROPTION(CALG_TLS1PRF);
                ^
vtls/schannel.c:212:10: note: in definition of macro 'CIPHEROPTION'
   return X
          ^
vtls/schannel.c:295:16: note: each undeclared identifier is reported only once for each function it appears in
   CIPHEROPTION(CALG_TLS1PRF);
                ^
vtls/schannel.c:212:10: note: in definition of macro 'CIPHEROPTION'
   return X
          ^
make[2]: *** [libcurl_la-schannel.lo] Error 1
make[1]: *** [all] Error 2
make: *** [all-recursive] Error 1```

[MarcelRaad]

Great to see you're still around! See #2721 (comment): what's __W32API_VERSION, __W32API_MAJOR_VERSION, __W32API_MINOR_VERSION, and __W32API_PATCHLEVEL on this system? I cannot reproduce this on the latest classic MinGW since 48cf45c (with follow-up 2c33105).

[mback2k]

@MarcelRaad Thanks for pointing me at this, I did not see the notification before. I will try to figure out the variables, but in order to do that I will have to restore my previous build system which crashed. I am currently building a new one which might also have a newer MinGW version.

[mback2k]

Status update: Some of my builds are back up and running. Currently re-building the libssh2 dependencies throughout the night and planning to restart native Windows builds tomorrow.

I hope to get it working before the release in order to get a potential bugfix in.

[mback2k]

Status update: Unfortunately I won't be able to re-test this before the release. My new curl builders are unable to checkout the repository for some reason. I will have to investigate this first and will report back once my builders are working again and I was able to identify the root cause within MinGW.

[mback2k]

Status update: Cross-compilation is back up and running, but native Windows builds are still delayed due to Git cloning issues. @bagder Could you please tell me how you made your buildbot react upon pull requests? I would like to have my (now dockerized) builds also performed before a merge is done.

[bagder]

Do you have any hints/advice on getting the buildbot setup for PRs @dago ? (it's not really me who set that up, it just uses my permission, Dagobert did the real work)

[dago]

Sure. For this to work you need to set up a hook in the GitHub project to the buildbot receiver. In my case this was
Payload URL: http://user:pass@buildbot.opencsw.org:8010/change_hook/github
Content Type: application/json
Secret: (from the snippet below)
Events: pull request, push
Then generate a personal access token with the scope „repo:status“.
The token can then be configured in buildbot.

You only need one buildbot trigger for github for all projects:

c['status'].append(html.WebStatus(http_port=8010, authz=authz_cfg,
                                change_hook_auth=["file:changehook.passwd"],
                                    change_hook_dialects={
                                        'github': {
                                            'secret': '<secret>',
                                            'strict': True
                                        }
                                    },
                                    ))

This is also documented at the Buildbot GitHub Change Hook Description

After that hopefully pull requests will be automatically checked and status easily visible :-)

[mback2k]

@dago Thank you very much. I will take a look at the change_hook configuration. The status part is already configured for my buildbot instance.

[bagder]

@mback2k: we build on windows in the CI and @vszakats builds the official windows builds using mingw successfully. These are indications that what you reported up here was due to a mingw bug/issue that no longer exists.

Can we close this or are you actively pursuing this?

[mback2k]

@bagder I am actively trying to bring my legacy MinGW buildbots back to live. The issue still persisted with those and I don't think any of the builds you mentioned use legacy MinGW (Windows XP level).

Please allow me to keep this issue open until my buildbots are working again and I can confirm that it also works with the MinGW setup I had.

[vszakats]

@mback2k: If your goal is to build binaries that run on Windows XP — in my experience this doesn't require old/legacy MinGW tools. E.g. the latest MinGW toolchain available on macOS (via Homebrew) is able to produce XP-compatible binaries just fine. It uses the same mingw-w64 package version as curl-for-win builds (with a bit newer gcc/binutils/clang versions.) Same should be true for the latest toolchain installed via MSYS2 and for the standalone mingw-w64 binary downloads.

The only incompatibility I've found in context of curl was that WinIDN option isn't compatible with XP, unless a normaliz.dll is installed. Sadly this component is no longer made available by MS, so it either needs to be obtained from elsewhere or curl be built without WinIDN for compatibility with default XP environments.

[mback2k]

@vszakats Thanks for the additional information. I just want to make sure that curl can still be build with the original MinGW toolchain. I was finally able to bring back my buildbots at https://libssh2build.uxnr.de/waterfall and https://curlbuild.uxnr.de/waterfall. I guess we will see tomorrow what things are still breaking or missing.

[mback2k]

Some issues with the legacy MinGW compiler toolchain seem to be still existing, see:
https://curlbuild.uxnr.de/builders/curl_winssl_mingw_x86/builds/4512/steps/compile/logs/stdio
https://curlbuild.uxnr.de/builders/curl_winssl_mingw_x86_dbg/builds/1766/steps/testcurl/logs/stdio

[MarcelRaad]

Many people are still using the classic MinGW from mingw.org as it's the first Google hit, so I consider supporting it important, at least in the latest version. The current version works fine except for one warning-as-error (EDIT: when using the default POSIX threads, not Win32 threads, which @mback2k 's builders are using.)

But again, what version is this and what are the values of the following macros after including windows.h?
__W32API_VERSION
__W32API_MAJOR_VERSION
__W32API_MINOR_VERSION
__W32API_PATCHLEVEL
__MINGW32__
__MINGW32_MAJOR_VERSION
__MINGW32_MINOR_VERSION

[mback2k]

@MarcelRaad I am using legacy MinGW from the package mingw-get-0.6.2-mingw32-beta-20131004-1-bin.zip which is build into a docker container via this Dockerfile.

[I will follow up or edit this post once I have the requested macro values.]

[mback2k]

@MarcelRaad These are the values I was able to capture with this debug commit:

__W32API_VERSION: 0.000000
__W32API_MAJOR_VERSION: 5
__W32API_MINOR_VERSION: 0
__W32API_PATCHLEVEL: 2
__MINGW32__: 1
__MINGW32_VERSION: 0.000000
__MINGW32_MAJOR_VERSION: 5
__MINGW32_MINOR_VERSION: 0

[MarcelRaad]

Thanks a lot @mback2k ! Does the original problem from #2924 (comment) still exist, or any other build problems?

[mback2k]

@MarcelRaad I think all mentioned issues have been fixed. At least I was able to perform a successful build after merging your threading fix.

Unfortunately my buildbots are now down again since my hoster has some virtualization issues. I won’t be able to take another look before the weekend since I am currently traveling on vacation.

[mback2k]

I can now finally report back that all issues with the setup at my hosting provider have now been solved and my buildbots are up and running again. I will also try to provide a webhook URL for @bagder in order to run builds for pull-requests soon.

[mback2k]

I provided web hook information to @bagder and now my buildbots also run for PRs, see #3285 as an example PR.