Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Classic legacy MinGW builds currently broken #2924

Closed
mback2k opened this Issue Aug 31, 2018 · 20 comments

Comments

Projects
None yet
5 participants
@mback2k
Copy link
Member

mback2k commented Aug 31, 2018

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

This comment has been minimized.

Copy link
Member

MarcelRaad commented Aug 31, 2018

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

This comment has been minimized.

Copy link
Member Author

mback2k commented Sep 1, 2018

@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

This comment has been minimized.

Copy link
Member Author

mback2k commented Sep 3, 2018

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

This comment has been minimized.

Copy link
Member Author

mback2k commented Sep 4, 2018

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 mback2k self-assigned this Sep 4, 2018

@mback2k

This comment has been minimized.

Copy link
Member Author

mback2k commented Sep 7, 2018

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

This comment has been minimized.

Copy link
Member

bagder commented Sep 7, 2018

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

This comment has been minimized.

Copy link
Contributor

dago commented Sep 7, 2018

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

This comment has been minimized.

Copy link
Member Author

mback2k commented Sep 13, 2018

@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

This comment has been minimized.

Copy link
Member

bagder commented Sep 20, 2018

@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

This comment has been minimized.

Copy link
Member Author

mback2k commented Sep 21, 2018

@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

This comment has been minimized.

Copy link
Member

vszakats commented Sep 21, 2018

@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

This comment has been minimized.

Copy link
Member Author

mback2k commented Sep 24, 2018

@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

This comment has been minimized.

@MarcelRaad

This comment has been minimized.

Copy link
Member

MarcelRaad commented Sep 25, 2018

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

MarcelRaad added a commit to MarcelRaad/curl that referenced this issue Sep 26, 2018

MarcelRaad added a commit to MarcelRaad/curl that referenced this issue Sep 26, 2018

MarcelRaad added a commit to MarcelRaad/curl that referenced this issue Sep 26, 2018

MarcelRaad added a commit to MarcelRaad/curl that referenced this issue Sep 26, 2018

@mback2k

This comment has been minimized.

Copy link
Member Author

mback2k commented Sep 26, 2018

@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

This comment has been minimized.

Copy link
Member Author

mback2k commented Sep 27, 2018

@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 added a commit to MarcelRaad/curl that referenced this issue Sep 27, 2018

@MarcelRaad

This comment has been minimized.

Copy link
Member

MarcelRaad commented Sep 27, 2018

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

@mback2k

This comment has been minimized.

Copy link
Member Author

mback2k commented Sep 27, 2018

@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 mback2k closed this Sep 27, 2018

dmitrykos added a commit to dmitrykos/curl that referenced this issue Oct 4, 2018

curl_threads: fix classic MinGW compile break
Classic MinGW still has _beginthreadex's return type as unsigned long
instead of uintptr_t [0]. uintptr_t is not even defined because of [1].

[0] https://sourceforge.net/p/mingw/mingw-org-wsl/ci/wsl-5.1-release/tree/mingwrt/include/process.h#l167
[1] https://sourceforge.net/p/mingw/mingw-org-wsl/ci/wsl-5.1-release/tree/mingwrt/include/process.h#l90

Bug: curl#2924 (comment)
Closes curl#3051

CMake: added missing HAVE_BUILTIN_AVAILABLE (define and test), added missing test for HAVE_CLOCK_GETTIME_MONOTONIC
@mback2k

This comment has been minimized.

Copy link
Member Author

mback2k commented Nov 12, 2018

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

This comment has been minimized.

Copy link
Member Author

mback2k commented Nov 18, 2018

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

@lock lock bot locked as resolved and limited conversation to collaborators Feb 16, 2019

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.