conftest.exe error during make of depends on Windows Subsystem for Linux

mmortal03 commented at 0:21 am on October 28, 2019: none

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:

0PATH=$(echo "$PATH" | sed -e 's/:\/mnt.*//g') 
1//this strips out problematic Windows %PATH% imported var (see doc/build-windows.md)
2
3git clone https://github.com/bitcoin/bitcoin.git
4cd bitcoin/depends
5make 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: conftest

mmortal03 added the label Bug on Oct 28, 2019

fanquake added the label Windows on Oct 28, 2019

sipsorcery commented at 4:26 pm on November 4, 2019: member

I failed to replicate this with WSL and Ubuntu 18.04.

A quick Google found some articles where the conftest.exe generated by the mingw configure script gets flagged by anti-virus programs. Do you have an AV program that could be the culprit?

mmortal03 commented at 0:26 am on November 5, 2019: none

I failed to replicate this with WSL and Ubuntu 18.04.

A quick Google found some articles where the conftest.exe generated by the mingw configure script gets flagged by anti-virus programs. Do you have an AV program that could be the culprit?

No, only the regular “Windows Security” virus protection that’s built in to Windows 10. Let me do some further testing on another machine and see if I can reproduce it and compare it to the offending machine.

laanwj removed the label Bug on Nov 5, 2019

laanwj commented at 10:16 am on November 5, 2019: member

Please upload your config.log somewhere, it might give a clue why you end up with a conftest.exe instead of a Linux executable.

mmortal03 commented at 1:36 pm on November 6, 2019: none

Please upload your config.log somewhere, it might give a clue why you end up with a conftest.exe instead of a Linux executable.

Should there be a config.log? This is occurring in the make of the depends folder, before I get to the configure step.

laanwj commented at 1:47 pm on November 6, 2019: member

Should there be a config.log? This is occurring in the make of the depends folder, before I get to the configure step.

There’s always a config.log when configure runs.

Also it would be good to know what dependency is generating this error! It’s useful information at least that it’s not bitcoin’s own configure script.

mmortal03 commented at 2:39 pm on November 6, 2019: none

It seems there must be a part of the make process (of the dependencies) that removes the config.log(s) after it completes. I did a file search while it was running and did see a config.log present under, for example, a zeromq subfolder, but this file disappeared once everything was completed. I’ll capture the console output and monitor it to see if I can better pinpoint the package where this is happening.

mmortal03 commented at 3:40 pm on November 6, 2019: none

Okay, I think I found it. It’s happening during the configuring of bdb. The error happens after the following bdb config.log line 5842, where the console output is: “checking for clock_gettime monotonic clock”. I’m outside of my knowledge as far as what might be going wrong here. bdb_config.log

laanwj commented at 3:55 pm on November 6, 2019: member

that helps! berkeleydb apparently checks whether it’s cross-compiling by trying to execute the build output

0configure:4860: checking whether we are cross compiling
1configure:4868: x86_64-w64-mingw32-gcc -o conftest.exe -pipe -O2     -I/home/mmortal03/bitcoin/depends/x86_64-w64-mingw32/include   -DUNICODE -D_UNICODE   -L/home/mmortal03/bitcoin/depends/x86_64-w64-mingw32/lib     conftest.c  >&5
2configure:4872: $? = 0
3configure:4879: ./conftest.exe
4configure:4883: $? = 0
5configure:4898: result: no

this is quite unusual; it should derive this from command line settings only then again the build system for bdb 4.8 is old as the hills

mmortal03 commented at 3:43 am on November 7, 2019: none

Definitely interesting, so the next question is: why does its execution error out on my machine, whereas it doesn’t on sipsorcery’s machine?

I noticed that the line @laanwj referenced is not the only time where ./conftest.exe is run, so, might there be something specific to the “checking for clock_gettime monotonic clock” test that’s causing the executable to fail, only at this step? @sipsorcery , what version of Windows 10 are you running? I’m on 1903. I came across the following, but I don’t know if it applies or not (and it’s unclear whether it’s been fixed in the latest Windows 10 builds or not): https://github.com/microsoft/WSL/issues/3840

sipsorcery commented at 8:11 am on November 7, 2019: member

@mmortal03 I’m on Windows 10 Pro Insider Preview Build 18956.rs_prerelease.190803-1414.

I switched to the Windows Insider Ring about 6 months ago and prior to that was able to build Bitcoin Core on the standard release version of Windows 10.

Are you using WSL 1 or 2? There are some fundamental changes between them.

0 wsl -l -v
1  NAME            STATE           VERSION
2* Ubuntu-18.04    Running         1

mmortal03 commented at 8:56 am on November 7, 2019: none

@sipsorcery I just tried that from the Windows command line, as well as PowerShell, but my wsl command doesn’t have that verbose argument as an option, it only has the list argument, so I can’t provide the same output. I would suspect I’m on version 1, though.

laanwj commented at 9:11 am on November 7, 2019: member

It’d be good to ensure all updates (windows and ubuntu, and WSL) are up to date first, to avoid spending time chasing ghosts.

might there be something specific to the “checking for clock_gettime monotonic clock” test that’s causing the executable to fail, only at this step?

Could be, yes. You could try to extract test code it’s trying to compile and run at that step, compile it yourself and try to figure out why it produces an invalid exe.

mmortal03 commented at 8:11 am on November 8, 2019: none

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:

0#include <sys/time.h>
1main() {
2	struct timespec t;
3	return (clock_gettime(CLOCK_MONOTONIC, &t) != 0);
4}

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.

laanwj commented at 8:55 am on November 8, 2019: member

That’s a great analysis!

I have no idea how one would go about fixing this in the build system.

The most effective, I think, would be to add a patch in depends to berkeleydb’s build system that either:

Fix berkeleydb’s build system to properly detect a cross build in this case. In modern times of WSL, multi-arch, and qemu-user, being able to execute binaries doesn’t mean it’s not a cross build. Build systems should not try to execute anything they produce for the target.
Removes this specific test-case (but would need to investigate where the result is used, depending on what monotonic time is used for; if it’s only for benchmarking/tests, we don’t care, just hardwire it to false)
Replace this specific test case with a check that doesn’t trigger the problem. E.g. do a static link of libc so that the conftest doesn’t need an extra dll.

mmortal03 commented at 10:01 am on November 8, 2019: none

In terms of going the static linking route, I came across the suggestion of the following parameters which do seem to work around the issue of needing libwinpthread-1.dll to be present:

x86_64-w64-mingw32-gcc -o conftest.exe conftest.c -Wl,-Bstatic,--whole-archive -lwinpthread -Wl,--no-whole-archive

Source: https://stackoverflow.com/a/43402308/4438237

Also important, the following distinguishes between this issue in the mingw-w64 project and what MinGW.org does: https://github.com/metaeducation/ren-c/issues/624#issuecomment-331628363

billygarrison commented at 9:18 pm on March 8, 2020: contributor

I have the same issue, which also appears at the checking for clock_gettime monotonic clock point.

Windows 10 build 18363, WSL (not WSL 2). I upgraded Ubuntu from 16.04 to 18.04 and then followed the instructions at https://github.com/bitcoin/bitcoin/blob/master/doc/build-windows.md.

The error message that popped up was:

The code execution cannot proceed because libwinpthread-1.dll was not found. Reinstalling the program may fix this problem.

@mmortal03, which directory did you place the .dll in? (which executable are you referring to in the following?):

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

billygarrison commented at 9:25 pm on March 8, 2020: contributor

I should add that after closing the error popup, the command seemed to continue successfully.

Following the build-windows.md instructions I was able to successfully do the following commands:

0./autogen.sh
1CONFIG_SITE=$PWD/depends/x86_64-w64-mingw32/share/config.site ./configure --prefix=/
2make
3make install DESTDIR=/mnt/c/bitcoin

But when I ran make check there was a failure, which may or may not be related to the DLL error in the depends make command:

 0********* Start testing of WalletTests *********
 1Config: Using QtTest library 5.9.8, Qt 5.9.8 (x86_64-little_endian-llp64 static release build; by GCC 7.3-posix 20180312)
 2PASS   : WalletTests::initTestCase()
 3QDEBUG : WalletTests::walletTests() TransactionTablePriv::refreshWallet
 4QWARN  : WalletTests::walletTests() This plugin does not support propagateSizeHints()
 5A crash occurred in \\wsl$\Ubuntu\usr\src\bitcoin\src\qt\test\test_bitcoin-qt.exe.
 6Function time: 1440ms Total time: 1441ms
 7
 8Exception address: 0x0000000001568e55
 9Exception code   : 0xc0000005
10
11Stack:
12#  1: Unable to obtain symbol
13#  2: UnhandledExceptionFilter() - 0x00007fff0a61f4b0
14#  3: memset() - 0x00007fff0c8c3000
15#  4: _C_specific_handler() - 0x00007fff0c8ac640
16#  5: _chkstk() - 0x00007fff0c8c1100
17#  6: RtlRaiseException() - 0x00007fff0c889ef0
18#  7: KiUserExceptionDispatcher() - 0x00007fff0c8bfe60
19#  8: Unable to obtain symbol
20#  9: Unable to obtain symbol
21# 10: Unable to obtain symbol
22# 11: Unable to obtain symbol
23# 12: Unable to obtain symbol
24# 13: Unable to obtain symbol
25# 14: Unable to obtain symbol
26# 15: Unable to obtain symbol
27# 16: Unable to obtain symbol
28# 17: Unable to obtain symbol
29# 18: Unable to obtain symbol
30# 19: Unable to obtain symbol
31# 20: Unable to obtain symbol
32# 21: Unable to obtain symbol
33# 22: Unable to obtain symbol
34# 23: Unable to obtain symbol
35# 24: Unable to obtain symbol
36# 25: Unable to obtain symbol
37# 26: Unable to obtain symbol
38# 27: Unable to obtain symbol
39# 28: Unable to obtain symbol
40# 29: Unable to obtain symbol
41# 30: secp256k1_ecdsa_recover() - 0x0000000001e309a0
42# 31: Unable to obtain symbol
43# 32: Unable to obtain symbol
44# 33: BaseThreadInitThunk() - 0x00007fff0b8a7bc0
45# 34: RtlUserThreadStart() - 0x00007fff0c88ceb0
46
47FAIL qt/test/test_bitcoin-qt.exe (exit status: 5)

mmortal03 commented at 11:52 pm on March 8, 2020: none

@mmortal03, which directory did you place the .dll in? (which executable are you referring to in the following?):

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

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.

billygarrison commented at 3:08 pm on June 21, 2020: contributor

@mmortal03 @laanwj I have found a working solution to this problem in my case (https://github.com/bitcoin/bitcoin/issues/18348)

Using sudo make HOST=x86_64-w64-mingw32 instead of just make HOST=x86_64-w64-mingw32 fixes the problem. No idea why.

mmortal03 commented at 11:36 pm on June 22, 2020: none

@mmortal03 @laanwj I have found a working solution to this problem in my case (#18348)

Using sudo make HOST=x86_64-w64-mingw32 instead of just make HOST=x86_64-w64-mingw32 fixes the problem. No idea why.

Yeah, I’ve seen cases of this sort of thing working in various respects, even though people will tell you that we shouldn’t be putting sudo on such compilation commands. I haven’t tested this lately. I should try compiling 0.20.0 and see if anything different happens.

mmortal03 commented at 11:38 am on June 23, 2020: none

@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.

billygarrison commented at 6:48 pm on June 29, 2020: contributor

@sipsorcery came up with an easy-to-implement workaround #18348 (comment)

mmortal03 commented at 2:58 am on June 30, 2020: none

@sipsorcery came up with an easy-to-implement workaround #18348 (comment)

Thanks! I can confirm that this works around the the issue. @laanwj , should we close this and open a new issue for the long term, automated fix?

laanwj referenced this in commit 85a68952f8 on Jul 1, 2020

laanwj commented at 3:27 pm on July 1, 2020: member

I don’t think it’s possible to fix this on our side. #19408 (comment) is probably right that this issue is common to all autoconf projects.

mmortal03 commented at 2:07 am on July 2, 2020: none

Yep, I’ll close it, then. I guess someone could post a bug report to bug-autoconf@gnu.org, though I did a quick search through their archives regarding Windows and someone stated, “MS-Windows is not our platform of choice and questions involving it are lower priority.” Maybe it’s not up the GNU gang and it’s the Microsoft WSL people who need to come up with a more elegant default handling of binfmt_misc cases. It’s beyond my paygrade, lol.

mmortal03 closed this on Jul 2, 2020

random-zebra referenced this in commit 18a91240f6 on Dec 7, 2020

DrahtBot locked this on Feb 15, 2022

conftest.exe error during make of depends on Windows Subsystem for Linux #17277