0

I'm trying to pack my Windows Toolchain into a container image. For that, I use WSL2 and Docker. To run Windows binaries, I use Wine. This works for many Windows tools, but unfortunately, gcc does not work:

# in WSL2, Ubuntu 20.04 LTS
jan@host:/mnt/e/gcc-arm-11.2-2022.02-mingw-w64-i686-arm-none-eabi/bin$ wine arm-none-eabi-gcc.exe -v
wine: Unhandled page fault on execute access to 004B3000 at address 004B3000 (thread 0009), starting debugger...

Debug messages:

Unhandled exception: page fault on execute access to 0x004b3000 in 32-bit code (0x004b3000).
Register dump:
 CS:0023 SS:002b DS:002b ES:002b FS:006b GS:0063
 EIP:004b3000 ESP:012fff24 EBP:012fff48 EFLAGS:00010206(  R- --  I   - -P- )
 EAX:3fff8000 EBX:3ffff000 ECX:012fff74 EDX:012fff74
 ESI:00000000 EDI:00000000
Stack dump:
0x012fff24:  004014f2 00000000 c1aacd00 012fff50
0x012fff34:  7b454882 3ffff000 7b454cfc 7b454cfc
0x012fff44:  7b454cfc 012fffd8 7b454cfc 3ffff000
0x012fff54:  004014e0 012fff74 012fff74 00000000
0x012fff64:  00000000 004014e0 3ffff000 00000000
0x012fff74:  ffffffff 7b46d850 7b434568 00000000
Backtrace:
=>0 0x004b3000 in arm-none-eabi-gcc (+0xb3000) (0x012fff48)
  1 0x7b454cfc in kernel32 (+0x34cfb) (0x012fffd8)
  2 0x7b45488e in kernel32 (+0x3488d) (0x012fffec)
0x004b3000: orb 0x0(%eax),%al
Modules:
Module  Address         Debug info  Name (10 modules)
PE    400000-  6fc000   Dwarf           arm-none-eabi-gcc
PE  7b020000-7b023000   Deferred        kernelbase
PE  7b420000-7b5db000   Export          kernel32
PE  7bc30000-7bc34000   Deferred        ntdll
PE  7f3e0000-7f3e4000   Deferred        imm32
PE  7f610000-7f614000   Deferred        version
PE  7f640000-7f644000   Deferred        advapi32
PE  7f6d0000-7f6d7000   Deferred        gdi32
PE  7f840000-7f928000   Deferred        user32
PE  7fa70000-7fa74000   Deferred        msvcrt
Threads:
process  tid      prio (all id:s are in hex)
00000008 (D) Z:\mnt\e\gcc-arm-11.2-2022.02-mingw-w64-i686-arm-none-eabi\bin\arm-none-eabi-gcc.exe
    00000029    0
    00000009    0 <==
0000000e services.exe
    00000023    0
    0000001c    0
    00000015    0
    00000010    0
    0000000f    0
00000011 plugplay.exe
    00000019    0
    00000018    0
    00000012    0
00000013 explorer.exe
    00000030    0
    0000002f    0
    0000002c    0
    00000014    0
0000001a winedevice.exe
    00000020    0
    0000001f    0
    0000001e    0
    0000001d    0
    0000001b    0
00000021 winedevice.exe
    00000025    0
    00000024    0
    00000022    0
System information:
    Wine build: wine-5.0 (Ubuntu 5.0-3ubuntu1)
    Platform: i386
    Version: Windows 7
    Host system: Linux
    Host version: 5.10.60.1-microsoft-standard-WSL2

GCC is from here: https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/downloads-1

Other tools in the directory, like gcov, readelf, etc. don't work either.

Is there anything I can do to track down the issue or is nearly impossible to run a toolchain in Wine?

The reason I have to to use the Windows Version instead the Linux version is that the toolchain is slightly modified by our supplier and Windows only :( But I'd like to avoid to run a Windows Docker Server for one image only, therefore the Wine approach.

Jan
  • 310
  • 1
  • 7
  • I don't understand, you are saying the toolchain is Windows only, and pointing to a WEB page containing a Linux X86_64 of the same gcc. Could you please elaborate on what the Windows-only (!) modifications made by your supplier are ? – Frant May 23 '22 at 13:43
  • Dear Frant, I'm sorry I can't. It's not exactly the same toolchain I've linked to, but the issue with Wine is identical. It's for certified embedded development and I was asked to put everything into a container solution. It's not exactly GCC but very similar. I could use a Windows container, but this makes maintenance much harder. – Jan May 23 '22 at 16:52
  • In this case, since your were put in this uncomfortable situation by your requirements/supplier/management, you should just ask for the proper Docker license so that your container will be a Window container. If you are working on a commercial project, the time you will avoid spending on a different/tricky solution, as well as fixing the issues you will certainly face, will for sure pay for the Docker license - my two cents. – Frant May 23 '22 at 17:46
  • I just tried, and I got the exact same error using Windows 10.0.19044.1706, WSL2, Ubuntu 22.04 and wine-6.0.3. – Frant May 23 '22 at 18:09
  • Thank you very much for your confirmation, Frant. We do have licenses, for Docker, for Windows Server, and for the toolchain. But we'd like to avoid additional maintenance efforts of the Windows Servers if somehow possible. The toolchain unfortunately does not exist for Linux, and it's over 100 k$ license fees invested, we have to use that one :( – Jan May 23 '22 at 18:53
  • You are welcome, and I understand. In this case, I would probably go for a Windows 10 virtual machine hosted by an already maintained server, and the native Windows openssh server installed. If you don' t use USB, VirtualBox would do the job at no cost, and you probably already spent the cost for the extra Windows 10 license.Exporting/importing a VM in a standard format is less convenient than using Docker, but is still a workable solution (I guess). I sincerely wish you good luck in your endeavours. – Frant May 23 '22 at 19:26

0 Answers0