xpack-dev-tools/windows-build-tools-xpack

make Error -1073741819

DaPa opened this issue · 7 comments

DaPa commented

With previous xpack-windows-build-tools-4.2.1-2-win32-x64.zip I was able to build nice (on Win10.1909.x64).
With new version v4.2.1-3 it fails with strange error code: -1073741819. Some suggest that this -1073741819 is 0xC0000005 = ERROR_ACCESS_DENIED? Anyone else, get same behaviour? For now reverted to previous 4.2.1-2 which works fine.

Example for "make clean":
...
make[1]: Leaving directory 'D:/.../docs'
make -C src/utils/unittests clean; make -C src/algorithm/unittests clean; make -C src/bluetooth/unittests clean;
make: *** [Makefile:10: clean] Error -1073741819

Example for "make target":
...
make[1]: *** [Makefile:39: target] Error -1073741819
make[1]: Leaving directory 'D:/.../build'
make: *** [Makefile:13: target] Error 2

ilg-ul commented

Thank you for the report.

Release 4.2.1-3 uses the same make source code as 4.2.1-2, but upgrades to the latest mingw-w64 9.0 runtime with UCRT, vs the old msvcrt.

I have almost no Windows experience, but unless you hit a bug, it might be possible that the new run-time to be less permissive than the old one.

I don't know where ERROR_ACCESS_DENIED can come from.

I know that it is not easy, but a simple test case that I can use to reproduce the issue would help.

ilg-ul commented

I was able to reproduce the problem.

It seems to be in sh.exe, since removing it (which forces make to use cmd.exe) or copying it from a previous release avoids the problem.

The sh.exe is built from the latest BusyBox sources; it either introduced a bug since the last release, or rather my new build environment (which uses UCRT), requires more tweaks.

I'll further investigate and find a solution.

  • 👍1
DaPa commented

or copying it from a previous release avoids the problem.

Confirming: using all other 4.2.1-3 binaries, but keeping sh.exe from 4.2.1-2 works fine.

ilg-ul commented

Thank you.

I'm working right now to identify what changes caused this.

ilg-ul commented

The problem seems related to building BusyBox with the new mingw-w64.

I entered a ticket to BusyBox: rmyorston/busybox-w32#234

As a workaround, I'll try to temporarily revert to the previous build environment, and make a maintenance release.

  • 👍2
ilg-ul commented

rmyorston/busybox-w32#234

Fixed in v4.3.0-1 on 2022-03-05.

  • 👍1