bitcoin: conftest.exe error during make of depends on Windows Subsystem for Linux
Expected behavior Making the Bitcoin depends on Windows Subsystem for Linux (Ubuntu 18.04) should complete without error.
Actual behavior I’m getting prompted with a conftest.exe application error (see below for screenshot) during the make of the depends. This blocks further progress of make until I click the prompt. It doesn’t seem to impact the ultimate build result, but it wastes time, blocking the remaining process while waiting for user input. I assume WSL is incorrectly trying to run this executable in Windows. The error occurs during the “checking for clock_gettime monotonic clock…” step, or shortly thereafter. I verified that no extraneous paths have been added to my $PATH variable.
To reproduce 1.) In Windows, open bash prompt of Windows Subsystem for Linux (Ubuntu 18.04). 2.) Install the required packages to build Bitcoin, set the default mingw32 g++ compiler option to posix, etc. (In other words, do all the standard preparation steps for compiling Bitcoin on Windows.) 3…) Run the following:
PATH=$(echo "$PATH" | sed -e 's/:\/mnt.*//g')
//this strips out problematic Windows %PATH% imported var (see doc/build-windows.md)
git clone https://github.com/bitcoin/bitcoin.git
cd bitcoin/depends
make HOST=x86_64-w64-mingw32
4.) Now wait until it gets to “checking for clock_gettime monotonic clock…”, and then you will get the following application error prompt:
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 25 (12 by maintainers)
Commits related to this issue
- Merge #19408: doc: Windows WSL build recommendation to temporarily disable Win32 PE support 21a65756f558a2bd50e71c6dfb04143533e59f76 Add Windows WSL build recommendation to temporarily disable Win32 ... — committed to bitcoin/bitcoin by laanwj 4 years ago
- Merge #2032: doc: Windows WSL build recommendation to temporarily disable Win32 PE support 51391430d967a976c24df43a10a0d316f8c75377 Add Windows WSL build recommendation to temporarily disable Win32 P... — committed to PIVX-Project/PIVX by random-zebra 4 years ago
@billygarrison I just tested it, and can confirm that using sudo gets around it for me, as well. Hopefully someone more knowledgeable can figure out why this is the case and fix it.
There might be a way to automatically inject the dll into the proper directory at compile time, but I can’t say what exact modifications that would entail, because I think the directories are generated during the compilation process. I’m pretty sure I was just reporting that it fixed the error in the isolated sense of putting the two together in their own directory – dealing with the issue at compile time still needs a fix.
Thanks for your help so far. Yep, my Windows install and Ubuntu/WSL are up to date.
I’ve made some progress. I’ve followed your suggestion and extracted the test code and tried compiling it myself, checking the verbose compiler output and such. Nothing looks to be going wrong there – the correct library paths are being accessed.
I’ve reduced the compilation command to the bare minimum. It still results in the same error after trying to run the executable:
x86_64-w64-mingw32-gcc -o conftest.exe conftest.c -lpthread
Keep in mind that it’s an exceedingly short bit of code:
Elsewhere, people say that this error code, 0xC000007B, tends to occur when 32-bit and 64-bit libraries get mixed up, but I don’t see any evidence of that here.
For kicks, I tried compiling it with i686-w64-mingw32-gcc, and this does produce a properly executing program, but this doesn’t really provide any further illumination.
I tried installing wine, and running the 64-bit executable with:
wine64 conftest.exe
And this produces the following error:
0009:err:module:import_dll Library libwinpthread-1.dll (which is needed by L"Z:\\home\\mmortal03\\conftest_build_unix\\conftest.exe") not found
I went and grabbed the libwinpthread-1.dll from /usr/x86_64-w64-mingw32/lib/ and placed it in the same directory as the executable, which seems to fix the problem (it, in the least, suppresses the error pop-up), both through wine64, and running it natively in Windows.
I have no idea why I would have to manually do this to get it to work on my machine, whereas it “just works” ™ for @sipsorcery , and I have no idea how one would go about fixing this in the build system.