Windows MinGW build failing with Bad file number

[lm8]

Windows MinGW build failing with Bad file number

[busterb]

What does 'Windows MinGW' mean, as in where did you install it from and what version?

You're probably right in that its hitting some limit on max number of files that /mingw/bin/gcc in your environment can open, but we might need more info on where that compiler comes from. FWIW, we've tested this cross-compiled with MinGW on Linux without issue (it's in our github actions and quite a few downstream projects use it), it gets exercised in whatever MinGW environment is on Appveyor, and it builds on Cygwin in Windows 10 and Windows 11.

[busterb]

Hi, checking again, which MinGW distribution are you hitting this issue with? There are at least six for Windows, and Cygwin's works as far as I can tell: https://www.mingw-w64.org/downloads/

[busterb]

This probably started when we began linking internal apps directly to object files rather than libraries: a316f8a

This made some test scenarios easier since internal apps always can run standalone, but it also had some downsides, e.g. you can't disable static builds and get a dynamic openssl.exe for instance. Would be OK if we wanted to revert to the previous behavior, though not necessarily just because this compiler has a max number of files it can open.

[lm8]

I tried both the MinGW distribution from the original MinGW project (which I was very active with in the past and still use for a lot of projects) and the MinGW64 compiler from the fork of the original MinGW. I thought the problem might be passing arguments in the shell not something with the compiler itself. You mentioned you cross-compiled. If the problem is with the Windows port of the bash shell and limitations passing longer arguments, I don't think you'd notice the issue when you cross-compile. Has anyone else had any luck building the latest versions of libressl directly on Windows using configure/make/make install? Is there a work-around or a way to leave out oscpcheck during the build? Maybe instead of reverting to linking libraries instead of object files, if there was an option to simply not build internal standalone apps that could cause overflows like this one? That way, it might be possible to continue to build the libraries directly on Windows using the configure/makefile scripts. Also, I'm curious why static libraries couldn't be used to build standalone apps rather than listing every object file. Thanks.

[lm8]

Just as a guess, assuming the Cygwin build that worked uses configure/make/make install instead of cmake, Cygwin users typically run bash in a terminal program. Some MinGW users do that but many build running bash directly in the command prompt. That might be limiting the line length. Doing some searches, I see mention that cmd.exe has a limit of 8192 while shell and execute functions have a limit of 32767.

[busterb]

Also, I'm curious why static libraries couldn't be used to build standalone apps rather than listing every object file.

I believe this was to work around issues when users would disable building static libraries, which then caused the build to break as well.

There are five different native distributions of Mingw-w64 here at least: https://www.mingw-w64.org/downloads/ - are you using MSYS2, mingw-w64-builds, winlibs.com, w64devkit, LLVM-MinGW? It helps to be specific please!

[busterb]

Got it to fail with MSYS2 like this:

  CCLD     ocspcheck.exe
../../libtool: line 1900: /ucrt64/bin/cc: Argument list too long
make[2]: *** [Makefile:463: ocspcheck.exe] Error 126

[lm8]

I'm glad you were able to reproduce the problem. I have a temporary work-around I'm using. I just created my own makefile and I'm using that instead of the official one. It's a way to get the latest libressl library to build on Windows with the tools I have available. It's working for me, at least for now.