skeeto/w64devkit

Portable C and C++ Development Kit for x64 (and x86) Windows

Portable C and C++ Development Kit for x64 Windows

w64devkit is a Dockerfile that builds from source a small, portable development suite for creating C and C++ applications on and for x64 Windows. See "Releases" for pre-built, ready-to-use kits.

Included tools:

• Mingw-w64 GCC : compilers, linker, assembler
• GDB : debugger
• GNU Make : standard build tool
• busybox-w32 : standard unix utilities, including sh
• Vim : powerful text editor
• Universal Ctags : source navigation
• NASM : x86 assembler
• Cppcheck : static code analysis

The toolchain includes pthreads, C++11 threads, and OpenMP. All included runtime components are static. Docker/Podman is not required to use the development kit. It's merely a reliable, clean environment for building the kit itself.

Build

First build the image, then run it to produce a distribution .zip file:

docker build -t w64devkit .
docker run --rm w64devkit >w64devkit.zip

This takes about half an hour on modern systems. You will need an internet connection during the first few minutes of the build. Note: Do not use PowerShell because it lacks file redirection.

Usage

The final .zip file contains tools in a typical unix-like configuration. Unzip the contents anywhere. Inside is w64devkit.exe, which launches a console window with the environment configured and ready to go. It is the easiest way to enter the development environment, and requires no system changes. It also sets two extra environment variables: W64DEVKIT_HOME to the installation root and W64DEVKIT to the version.

Alternatively, add the bin/ directory to your path. For example, inside a cmd.exe console or batch script:

set PATH=c:\path\to\w64devkit\bin;%PATH%

Then to start an interactive unix shell:

sh -l

Main features

• No installation required. Run it anywhere as any user. Simply delete when no longer needed.

• Fully offline. No internet access is ever required or attempted.

• A focus on static linking all runtime components. The runtime is optimized for size.

• Trivial to build from source, meaning it's easy to tweak and adjust any part of the kit for your own requirements.

• Complements Go for cgo and bootstrapping.

Optimized for size

Runtime components are optimized for size, leading to smaller application executables. Unique to w64devkit, libmemory.a is a library of memset, memcpy, memmove, memcmp, and strlen implemented as x86 string instructions. When not linking a CRT, linking -lmemory provides tiny definitions, particularly when GCC requires them.

Also unique to w64devkit, libchkstk.a has a leaner, faster definition of ___chkstk_ms than GCC (-lgcc), as well as __chkstk, sometimes needed when linking MSVC artifacts. Both are in the public domain and so, unlike default implementations, do not involve complex licensing. When required in a -nostdlib build, link -lchkstk.

Unlike traditional toolchains, import tables are not populated with junk ordinal hints. If an explicit hint is not provided (i.e. via a DEF file), then the hint is zeroed: "no data." Eliminating this random data makes binaries more compressible and theoretically faster loading. See also: peports.

Fortran support

Only C and C++ are included by default, but w64devkit also has full support for Fortran. To build a Fortran compiler, add fortran to the --enable-languages lines in the Dockerfile.

Recommended downloadable, offline documentation

With a few exceptions, such as Vim's built-in documentation (:help), w64devkit does not include documentation. However, you need not forgo offline documentation alongside your offline development tools. This is a list of recommended, no-cost, downloadable documentation complementing w64devkit's capabilities. In rough order of importance:

• cppreference (HTML), friendly documentation for the C and C++ standard libraries.

• GCC manuals (PDF, HTML), to reference GCC features, especially built-ins, intrinsics, and command line switches.

• Win32 Help File (CHM) is old, but official, Windows API documentation. Unfortunately much is missing, such as Winsock. (Offline Windows documentation has always been very hard to come by.)

• C and C++ Standards (drafts) (PDF), for figuring out how corner cases are intended to work.

• Intel Intrinsics Guide (interactive HTML), a great resource when working with SIMD intrinsics. (Search for "Download" on the left.)

• GNU Make manual (PDF, HTML)

• GNU Binutils manuals (PDF, HTML), particularly ld and as.

• GDB manual (PDF)

• BusyBox man pages (TXT), though everything here is also available via -h option inside w64devkit.

• NASM manual (PDF)

• Intel Software Developer Manuals (PDF), for referencing x86 instructions, when either studying compiler output with objdump, or writing assembly with nasm or as.

Library installation

Except for the standard libraries and Win32 import libraries, w64devkit does not include libraries, but you can install additional libraries such that the toolchain can find them naturally. There are three options:

1. Install it under the sysroot at w64devkit/$ARCH/. The easiest option, but will require re-installation after upgrading w64devkit. If it defines .pc files, the pkg-config command will automatically find and use them.

2. Append its installation directory to your CPATH and LIBRARY_PATH environment variables. Use ; to delimit directories. You would likely do this in your .profile.

3. If it exists, append its pkgconfig directory to the PKG_CONFIG_PATH environment variable, then use the pkg-config command as usual. Use ; to delimit directories

Both (1) and (3) are designed to work correctly even if w64devkit or the libraries have paths containing spaces.

Unique command-line programs

• peports: displays export and import tables of EXEs and DLLs. Like MSVC dumpbin options /exports and /imports; narrower and more precise than Binutils objdump -p. Useful for checking if exports and imports match your expectations. Complemented by c++filt and vc++filt, i.e. in a pipeline. Pronounced like purports.

• vc++filt: a c++filt for Visual C++ name decorations. Used to examine GCC-incompatible binaries, potentially to make some use of them anyway.

• debugbreak: causes all debugee processes to break in the debugger, like using Windows' F12 debugger hotkey. Especially useful for console subsystem programs.

Cppcheck tips

Use --library=windows for programs calling the Win32 API directly, which adds additional checks. In general, the following configuration is a good default for programs developed using w64devkit:

$ cppcheck --quiet -j$(nproc) --library=windows \
           --suppress=uninitvar --enable=portability,performance .

A "strict" check that is more thorough, but more false positives:

$ cppcheck --quiet -j$(nproc) --library=windows \
      --enable=portability,performance,style \
      --suppress=uninitvar --suppress=unusedStructMember \
      --suppress=constVariable --suppress=shadowVariable \
      --suppress=variableScope --suppress=constParameter \
      --suppress=shadowArgument --suppress=knownConditionTrueFalse .

Notes

$HOME can be set through the adjacent w64devkit.ini configuration, and may even be relative to the w64devkit/ directory. This is useful for encapsulating the entire development environment, with home directory, on removable, even read-only, media. Use a .profile in the home directory to configure the environment further.

I'd love to include Git, but unfortunately Git's build system doesn't quite support cross-compilation. A decent alternative would be Quilt, but it's written in Bash and Perl.

Neither Address Sanitizer (ASan) nor Thread Sanitizer (TSan) has been ported to Mingw-w64 (also), but Undefined Behavior Sanitizer (UBSan) works perfectly under GDB. With both -fsanitize=undefined and -fsanitize-trap, GDB will break precisely on undefined behavior, and it does not require linking with libsanitizer.

Since the build environment is so stable and predicable, it would be great for the .zip to be reproducible, i.e. builds by different people are bit-for-bit identical. There are multiple reasons why this is not currently the case, the least of which are timestamps in the .zip file.

Licenses

When distributing binaries built using w64devkit, your .exe will include parts of this distribution. For the GCC runtime, including OpenMP, you're covered by the GCC Runtime Library Exception so you do not need to do anything. However the Mingw-w64 runtime has the usual software license headaches and you may need to comply with various BSD-style licenses depending on the functionality used by your program: MinGW-w64 runtime licensing and winpthreads license. To make this easy, w64devkit includes the concatenated set of all licenses in the file COPYING.MinGW-w64-runtime.txt, which should be distributed with your binaries.

w64devkit's Issues

Antivirus marks w64devkit-1.17.0.zip and w64devkit-mini-1.17.0.zip as thread.

Bitdefender marks w64devkit-1.17.0.zip and w64devkit-mini-1.17.0.zip as threads saying:
w64devkit-(mini-)1.17.0.zip tried to load a malicious resource detected as Gen:Variant.Ransom.Hive.9 and was blocked. Suspicious activity blocked.

Feature:
Antivirus

Blocking the downloads of the files themselves through browsers.

I don't know if it happens also with other antivirus or smart screens.

Windows XP Support ?

Windows XP is the earliest target that most devs care that their executable build for. It's still very widely used and simply abandoning anything older than Vista/7 is not a great option.

It's also an incredibly easy to run in a VM for a *nix user to test/compile for Windows platforms. Not to mention nearly anything that runs on XP will run on the latest Windows just fine. So it would be incredibly useful if w64devkit binaries ran on XP.

So, would it be possible to release XP-compatible binaries ? Or are there major impediments in achieving this ...

Running on a XP Pro SP3 Version 2002 VM gives :

Reliably targeting CRT's other than msvcrt?

Toying with w64devkit to see if it creates plugin DLL's that work with a 3rd party app that appears to have been compiled with VC++ 2010/11. The following trivial experiment indicates it will avoid these types of problems, but do you recommend something else when using w64devkit other than spec file tweaks to force a CRT link with msvcr{80,90,100,110,120} if truly needed?

Haven't tried UCRT with w64devkit but this and what I see in <INSTALL>/x86_64-w64-mingw32/lib looks promising.

OT...like your blog, this one was great.

$ gcc --version | head -1 && gcc -dumpspecs | grep -C 1 msvc
gcc (GCC) 11.1.0
*libgcc:
%{mthreads:-lmingwthrd} -lmingw32     -lgcc     -lmoldname -lmingwex -lmsvcrt -lkernel32

$ cat msvcr100.spec
*libgcc:
%{mthreads:-lmingwthrd} -lmingw32     -lgcc     -lmoldname -lmingwex -lmsvcr100 -lkernel32

$ gcc -Wall -Wextra -O2 -s -specs=msvcr100.spec -o min.exe min.c
min.c: In function 'main':
min.c:3:14: warning: unused parameter 'argc' [-Wunused-parameter]
    3 | int main(int argc, char *argv[])
      |          ~~~~^~~~
min.c:3:26: warning: unused parameter 'argv' [-Wunused-parameter]
    3 | int main(int argc, char *argv[])
      |                    ~~~~~~^~~~~~

$ ./min.exe
Hello min!

$ objdump -x min.exe | grep -i 'dll name'
        DLL Name: KERNEL32.dll
        DLL Name: msvcr100.dll

Fortran removed?

Just curious why Fortran was removed? I would guess that the reason for removal was just size and relatively low interest, but I'm not sure if there are deeper reasons than that. Is re-enabling Fortran as simple as adding it to the enabled languages and then dealing with libquadmath, or is it more difficult than that?

fails with incompatible $HOME/.profile

very cool project (and impressive blog)!

clicking activate.bat fails for me, if i have a custom $HOME/.profile, for an existing msys2 setup.

In my case the problem is paths (msys2 /c/.../ vs busybox /.../)
But the general question is:
Should your self-contained system read configs at all?

Generic alias for BusyBox

Currently w64devkit has 148 tiny alias files for the BusyBox applets. These are all the same apart from the hardcoded name of the applet.

If the applet name were obtained from the command line you'd only need to build one binary and make 148 copies of it with different names.

This special case might be specified by giving an empty command name at build time (gcc -DEXE=busybox.exe -DCMD= ...).

Then, with details left as an exercise for the reader:

    if (COUNTOF(LCMD) != 1) {
        append(&cmd, LCMD, COUNTOF(LCMD)-1);
    } else {
        char16_t *appname = ...
        int applen = ....
        append(&cmd, appname, applen);
    }

Since COUNTOF(LCMD) is known at build time only one branch of the if should be compiled.

New mingw-w64 8.0

A new mingw version was released recently so I was wondering if you planned on updating the Dockerfile appropriately ?

I did so myself and tried building it with the Dockerfile as is but I got a compilation error related to some cryptic header file which I don't think could solve by myself. If you could look into it, it would be greatly appreciated !

in windows shell running make clean give "del: not found" error

Running make clean command gives error in windows 10
While trying to clean the lib from source

1. open windows shell in raylib dir
2. C:\raylib\w64devkit>set PATH=C:\raylib\w64devkit\bin;%PATH%
3. cd c:\dev\my\raylib\raylib_git\raylib-4.0.0\src
   Then :

c:\dev\my\raylib\raylib_git\raylib-4.0.0\src>make clean                                                                                                                                                                                      del *.o /s                                                                                                                                                                                                                                   sh: del: not found                                                                                                                                                                                                                           make: *** [Makefile:685: clean] Error 127

By the way solution is to convert to rm command in makefile :

Use a `diff` version that can ignore CR/LF differences

As it turns out, no matter the -w and friends, diff just won't get over differences only between LF and CR+LF.

It can be a real interop. issue in a mixed env like this (at least it cost me quite some time today to finally realize what the trouble was), so maybe we could somehow use a different diff, with more muscle (like --strip-trailing-cr), or -- better yet -- we could get the nice BusyBox-w32 upstream guy to add this life-saver of a feature.

(Honestly, after some googling, I'm kinda puzzled that I seem to be the only one toppling over this. :) Maybe I'm doing something wrong.)

Issues with `ld` crashing

I've had issues with ld crashing on invocation, which I resolved using a linker from another MinGW binary distribution. Unfortunately, I can't share the setup or the files involved, then I understand how vague is all this, even though I started a tentative explanatory question on StackOverflow.

I replicated the problem in a couple of environments. It appeared/disappeared even after changing a few instructions in the sources. Something suggests an issue with the kind of initialization of the memory, as at a certain point I had also different results in different command processors (cmd.exe, TCCle).

just a question

why?: sed -ri 's/(static bool insert_timestamp = )/\1!/' ld/emultempl/pe*.em

I googled but could not find any sources other than your Dockerfile. I understand it replaces "static bool insert_timestamp =" with "static bool insert_timestamp = !" I just don't understand what this does.

How to build win32 exe

First, this is a good project. It helps me much. But, I used to try to build win32 exe by "gcc test.cpp -m32". It can't work. I have seeked many methods, but there is not a useful method. Hopefully there will be a method.

Wildcard expansion

First, thanks for this project :)

Unlike the msys2 build, the GCC/G++ build in this project does not seem to expand glob patterns.
For example, if I run g++ -o test.exe src\*.cc, it fails:

g++: error: src\*.cc: Invalid argument
g++: fatal error: no input files

This works with msys2. This is not a deal breaker but it would be nice to have. This is not just about msys2; Clang and MSVC (cl) also perform expansion.

GDB doesn't have pretty-print

Being pretty-print one of the essential tools at time of debugging, since it makes the variables easy to read.

I would like to know if in a future version pretty-print would be implemented within gdb of w64devkit?

w64devkit is a powerful portable tool and easy to install: if it will has pretty-print it would be even more wonderful.

Custom entry point

So, like the title says, is there a way to create a custom entry point instead of always being main() ?

Add libraries to VSCode

Excelent tool, gcc and make are working as expected, but in VSCode I get errors about stdio.h and relatives libraries (VSCode complains about not finding them), how can I add w64devkit to the VSCode include path?, I alreay added the include and derivates folders but looks like VSCode is missing something...

Using UTF-8 code page

In cmd.exe one can use chcp 65001 to temporarily change the code page to utf-8. This doesn't seem to work in w64devkit.exe. Running chcp 65001 inside cmd.exe and then starting busybox sh -l doesn't work either. Is it possible to make this work?

Bat support

Why use such an old "less" version? It's incompatible with things like https://github.com/sharkdp/bat

If there's a reason for it, then no worries.

possible gcc problem with w64devkit-1.19.0 and win_flex

Most likely a user error, but I've spent a couple of hours trying to find a solution. I am on Windows 11 in a command window. I have run win_flex on a simple flex input file:
%{
#include "token.h"
%}
DIGIT [0-9]
LETTER [a-zA-Z]
%%
(" "|\t|\n) /* skip whitespace */
+ { return TOKEN_ADD; }
while { return TOKEN_WHILE; }
{LETTER}+ { return TOKEN_IDENT; }
{DIGIT}+ { return TOKEN_NUMBER; }
. { return TOKEN_ERROR; }
%%
int yywrap() { return 1; }

Using w64devkit-1.19.0 I run: gcc lex.yy.c
I get the following error:
D:\JonProjects\w64devkit-1.19.0\w64devkit\bin/ld.exe: D:/JonProjects/w64devkit-1.19.0/w64devkit/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/../../../../x86_64-w64-mingw32/lib/../lib/libmingw32.a(lib64_libmingw32_a-crtexewin.o):crtexewin.c:(.text.startup+0xb1): undefined reference to `WinMain'
collect2.exe: error: ld returned 1 exit status

I suspect an option must be turned off or on or need to add a library, but am unable to determine the solution.

Error when trying to build containers

doing this on a WSL linux distro in windows 10
podman build -t w64devkit .
gets me this error.
Error: error building at STEP "ARG VERSION=1.10.0 PREFIX=/w64devkit BINUTILS_VERSION=2.37 BUSYBOX_VERSION=FRP-4264-gc79f13025 CTAGS_VERSION=20200824 GCC_VERSION=11.2.0 GDB_VERSION=10.2 GMP_VERSION=6.2.1 MAKE_VERSION=4.2 MINGW_VERSION=8.0.2 MPC_VERSION=1.2.1 MPFR_VERSION=4.1.0 NASM_VERSION=2.15.05 VIM_VERSION=8.2": ARG requires exactly one argument definition

Doing it as docker
docker build -t w64devkit .
I get this error.
#9 0.873 sha256sum: WARNING: 1 computed checksum did NOT match

executor failed running [/bin/sh -c sha256sum -c $PREFIX/src/SHA256SUMS && tar xJf binutils-$BINUTILS_VERSION.tar.xz && tar xzf busybox-w32-$BUSYBOX_VERSION.tgz && tar xzf universal-ctags_0+git$CTAGS_VERSION.orig.tar.gz && tar xJf gcc-$GCC_VERSION.tar.xz && tar xJf gdb-$GDB_VERSION.tar.xz && tar xJf gmp-$GMP_VERSION.tar.xz && tar xzf mpc-$MPC_VERSION.tar.gz && tar xJf mpfr-$MPFR_VERSION.tar.xz && tar xzf make-$MAKE_VERSION.tar.gz && tar xjf mingw-w64-v$MINGW_VERSION.tar.bz2 && tar xJf nasm-$NASM_VERSION.tar.xz && tar xjf vim-$VIM_VERSION.tar.bz2]: exit code: 1

Results, the containers aren't building.

Would it be possible to support the 32bit toolchain?

I've been looking for a minimal MinGW 32bit toolchain for long time and this project looks perfect.

Every time I release a new version of raylib I create a small installer containing a portable self-contained environment to allow raylib C development on any Windows machine, mostly intended for my students but also for anyone that wants to develop in old computers (usually with a 32bit Window OS).

I already have a TCC package in under 40MB (raylib +120 examples resources are the bigger part in that package) but current MinGW-w64 package is around 100MB and I think your optimized toolchain can reduce that size providing an updated compiler version and toolset.

w64devkit and GNU Autotools

Over at rmyorston/busybox-w32#297 we've been working on getting stuff that uses a configure script to build with w64devkit.

With a bit of hackery I've managed to get Expat to build. (Chosen as a guinea pig because it's included with w64devkit and it's quite small.)

GNU Autotools support for Windows platforms is mostly restricted to Cygwin/MSYS2. This sort of works for w64devkit (hence the hackery) but what's really needed is proper support for the w64devkit build environment.

Is there any interest in prodding the GNU Autotools people to do this?

At step #5 sha256sum "no such file or directory" caused by linefeed compatability

Wow thanks for this awesome work. Exactly what I needed today. I've recently switched to Windows after almost a decade solely in Linux. Stepped into Windows 11 beta channel test this week. This project is the first Docker setup I've tried in this fresh instance.

In this new setup there seems to be an interoperability issue surrounding linefeeds in the old Unix vs Windows battle for how to do things right. When the dockerfile hit sha256sum checks across the packages it spits out an error no such file or directory. Might be dense of me but, you know, a decade's some time hey.

The only way I could resolve it to proceed with the build was to use the following in GIT config command before cloning this repo:
git config --global core.autocrlf false

A heads-up for you as it could go a little way to improving the documentation in your README for anyone not already tweaked GIT in this way and spare them a headache. Build just completed WAHOOOO!

Generate-mapfile does not seem to be supported

normal after using cmd

CHECKSUM of expat-2.4.8.tar.xz failed.

I need some help resolving the following during my build of 1.16.1. Apparently the checksum check for expat-2.4.8.tar.xz failed.

[ 5/67] RUN sha256sum -c /w64devkit/src/SHA256SUMS && tar xJf binutils-2.39.tar.xz && tar xzf busybox-w32-FRP-4716-g31467ddfc.tgz && tar xzf universal-ctags_0+git20200824.orig.tar.gz && tar xJf gcc-12.2.0.tar.xz && tar xJf gdb-11.1.tar.xz && tar xJf expat-2.4.8.tar.xz && tar xJf gmp-6.2.1.tar.xz && tar xzf mpc-1.2.1.tar.gz && tar xJf mpfr-4.1.0.tar.xz && tar xzf make-4.2.tar.gz && tar xjf mingw-w64-v10.0.0.tar.bz2 && tar xJf nasm-2.15.05.tar.xz && tar xjf vim-9.0.tar.bz2 && tar xzf cppcheck-2.8.tar.gz:
#10 0.481 binutils-2.39.tar.xz: OK
#10 0.499 busybox-w32-FRP-4716-g31467ddfc.tgz: OK
#10 0.516 cppcheck-2.8.tar.gz: OK
#10 0.516 expat-2.4.8.tar.xz: FAILED
#10 0.859 gcc-12.2.0.tar.xz: OK
#10 0.951 gdb-11.1.tar.xz: OK
#10 0.960 gmp-6.2.1.tar.xz: OK
#10 0.969 make-4.2.tar.gz: OK
#10 1.009 mingw-w64-v10.0.0.tar.bz2: OK
#10 1.013 mpc-1.2.1.tar.gz: OK
#10 1.020 mpfr-4.1.0.tar.xz: OK
#10 1.025 nasm-2.15.05.tar.xz: OK
#10 1.033 universal-ctags_0+git20200824.orig.tar.gz: OK
#10 1.092 vim-9.0.tar.bz2: OK
#10 1.092 sha256sum: WARNING: 1 computed checksum did NOT match

`test -e` fails on (healthy) symlink

$ pwd
C:/sz/prj/Args/test

$ busybox test -e tmp/symlink && echo ok
ok
$ test -e tmp/symlink && echo ok

:-o

$ which busybox
C:/SW/devel/tool/w64devkit/w64devkit-32/bin/busybox.exe
$ which test
test

But wait, there's more:

$ cd tmp && test -e symlink && echo ok
ok

:-oo

$ readlink symlink
C:/sz/prj/Args/test/tmp/README.out
$ test -f README.out && echo ok
ok

Any idea, what can cause this?

Create winget package

Greate work! I have just started using and playing around with it. I found it very helpful. I'm using it inside of windows terminal preview and it works realy nice. Thank you!

Maybe it's possible to distribute this as a winget package? Installation and updates would be so much easier.

workaround to make ctrl+z work?

At least on my machine, using the default command prompt terminal, Ctrl-Z to suspend VIM also seems to suspend the shell, dropping me back into the windows command prompt. Do you experience this same behavior and if so, do you know of a workaround?

Tip: busybox-w32 shell option -d allows you to specify the current directory of the new shell

A helpful feature I just found:

busybox-w32 has an undocumented shell option -d which allows you to specify the current directory of the new shell. This has to appear before the -s or -c options.

Source: rmyorston/busybox-w32#211 (comment)

With ..\w64devkit\bin in your PATH you could do the following in Windows PowerShell or cmd :

> sh -d \path\to\working\folder

and get in your busybox-w32 session:

/path/to/working/folder $ 

docker for windows or linux and a line ending problem?

Hi sorry to be so thick. Four questions probably all with obvious answers:

1. Is the docker container to be built on Windows or Linux? I assumed Windows.
2. If Windows, in a Windows container or a Linux container?
3. What if Docker, which I've just re-installed, tells me that it now uses wsl2 for the backend?
4. If you look at the snippet I've attached it looks to me like an old-fashioned Unix/Linux vs. DOS.Win line endnig problem when it's doing the sha256sum's but what are the '$' signs all about? They''re not in the Dockerfile.

Please forgive a Docker newbie for asking daft questions.

BTW, I'm a fan of your work. I've been folllowinng you for over a year. If you knew anything about me at all you would know that that statement is not a lame attempt to ingratiate myself.

Thanks very much in advance
Mike
sha256sums log.txt

Error while using mingw as a linker for rust

OS: Windows 11 Pro x64
Rust version: stable
Rust target: x86_64-pc-windows-gnu
mingw build: https://github.com/skeeto/w64devkit/releases/download/v1.18.0/w64devkit-1.18.0.zip

I have extracted the zip and added the binaries folder to my path.
Compiling a simple hello world in rust gives this error

error: linking with `x86_64-w64-mingw32-gcc` failed: exit code: 1
  |
  = note: "x86_64-w64-mingw32-gcc" "-fno-use-linker-plugin" "-Wl,--dynamicbase" "-Wl,--disable-auto-image-base" "-m64" "-Wl,--high-entropy-va" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsbegin.o" "C:\\Users\\Akshit\\AppData\\Local\\Temp\\rustc48wzX5\\symbols.o" "test.test.46b17e96-cgu.0.rcgu.o" "test.test.46b17e96-cgu.1.rcgu.o" "test.test.46b17e96-cgu.2.rcgu.o" "test.test.46b17e96-cgu.3.rcgu.o" "test.test.46b17e96-cgu.4.rcgu.o" "test.test.46b17e96-cgu.5.rcgu.o" "test.25wfbagu9nfc8nrd.rcgu.o" "-L" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "-Wl,-Bstatic" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libstd-58a0209155176750.rlib" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libpanic_unwind-d3a377f51a08e93b.rlib" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libobject-2b68121d5c691854.rlib" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libmemchr-e02210087fd130a4.rlib" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libaddr2line-c97c235d6ae1d402.rlib" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libgimli-5103cff433e42c31.rlib" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\librustc_demangle-10733230008649ea.rlib" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libstd_detect-eae72c8f03b720e5.rlib" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libhashbrown-4fe1ee9fb3f485f8.rlib" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libminiz_oxide-73030570e1b9e0b1.rlib" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libadler-2aebe113ee2dfa73.rlib" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\librustc_std_workspace_alloc-e87307e69a4828fe.rlib" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libunwind-948f80140ec626cf.rlib" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcfg_if-e7aed41dc626fc71.rlib" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liblibc-6df096732a8d89e9.rlib" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liballoc-2177fe373b363538.rlib" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\librustc_std_workspace_core-01b9d3625613d463.rlib" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcore-1d81dec6a35b3eaf.rlib" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcompiler_builtins-fedbd73de1b5211b.rlib" "-Wl,-Bdynamic" "-lkernel32" "-ladvapi32" "-luserenv" "-lkernel32" "-lws2_32" "-lbcrypt" "-lgcc_eh" "-l:libpthread.a" "-lmsvcrt" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-luser32" "-lkernel32" "-Wl,--nxcompat" "-L" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "-o" "test.exe" "-Wl,--gc-sections" "-no-pie" "-nodefaultlibs" "C:\\Users\\Akshit\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsend.o"
  = note: C:\Users\Akshit\Downloads\w64devkit-1.18.0\w64devkit\bin/ld.exe: cannot find -lgcc_eh: No such file or directory
          collect2.exe: error: ld returned 1 exit status


error: aborting due to previous error

g++ -g not working in cmd.exe

A command like:

~ $ g++ a.cpp -o a.exe -g

works properly in w64devkit.exe. But in cmd.exe, this command prints

> g++.exe a.cpp -o a.exe -g
as: unknown option -- gdwarf-5

In cmd.exe, commands like:

> g++.exe a.cpp -o a.exe 
> g++.exe a.cpp -o a.exe -g -S

works, and

> g++.exe a.cpp -o a.exe -g -c

doesn't.

I had never met such a problem with an old version w64devkit, I can't get more details from it. Hope the issue would be useful. Please tell me if I do anything wrong.

Unsolved issues: a call for assistance

Recent GCC and GDB updates have led to issues that currently have no solutions. I'm also stumped and have run out of avenues to search.

GCC 13.1 does not work on Windows XP (SOLVED)

As of 7256915, GCC no longer runs on Windows XP. Every other program works, just not cc1.exe. When attempting to run this program, (x86) Windows XP reports "The system cannot execute the specified program." with no further details. The same binary works fine on Windows 7 and later. To build your own test:

$ ./multibuild.sh -4q

advzip-compressed GDB 13.1 cannot be decompressed on x64 Windows

The problems began with fdac8e3. I normally advzip -z4 releases to shave about 5% off their size, but after I do this x64 Windows fails to decompress gdb.exe with error 0x80004005. No further information is provided by Windows. It still works on x86 Windows, and so I believe this is an old x64 Windows bug. It dates back at least as far as Windows 7. Until this is solved releases will be a few MiB larger.

More details, including a reduced sample file (advzip.sample) in 2cf762a. To reproduce: Place advzip.sample in a zip file, advzip -z4 that file, then try to decompress using x64 Windows's built-in ZIP support.

It is not feasible to compile GCC 13.1 on a Raspberry Pi 4

As of 13.1, GCC has become so large and complex that it runs out of memory during the bootstrap. So far I've built all the releases on this Raspi4. Not a big deal, but it is sad.

w64devkit-i686-1.18.0 dll linking in win10 64bit

Hi :)
This is a great compiler (w64devkit-i686-1.18.0) it runs great in windows XP and the generated executable are portable to newer 64bit windows!

And I know I'm probably pushing my luck, but thought I would ask, just in case.

I thought I would try the same compiler and same simple code and makefile, from winXP to win10 64bit, it compiles but fails to link with sdl2.dll (i686-w64-mingw32)

./SDL2.dll: file not recognized: file format not recognized
collect2.exe: error: ld returned 1 exit status

Using the typical "-L. -lSDL2" works in XP, not in win10.

I tried linking with the dll.a files, but that gives a lot of SDL undefined references.

Looks like it compiles and links fine, I tested a simple printf("a %f \n",sin(1.5) ) program, and it works fine.

Which makes me think, it's a "just me" thing?

Compiler unable to compile simple program

I'm on Windows 7 SP1 x64 and something above happens after couple successful compiles from Windows start. Compiling the same again and again and at some point compiler breaks. Or can compile all day and just at the evening it breaks finally. Doesn't matter if using cmake-G "Ninja" or cmake-G "CodeBlocks - MinGW Makefiles" or just configure CLion. Simple gcc works. Example code, Waveshare LCD display - error:

PICO_SDK_PATH is C:/DEV/SDK
PICO platform is rp2040.
Build type is Release
PICO target board is pico.
Using board configuration from C:/DEV/SDK/src/boards/include/boards/pico.h
TinyUSB available at C:/DEV/SDK/lib/tinyusb/src/portable/raspberrypi/rp2040; enabling build support for USB.
BTstack available at C:/DEV/SDK/lib/btstack
cyw43-driver available at C:/DEV/SDK/lib/cyw43-driver
Pico W Bluetooth build support available.
lwIP available at C:/DEV/SDK/lib/lwip
mbedtls available at C:/DEV/SDK/lib/mbedtls
-- Configuring done
-- Generating done
-- Build files have been written to: W:/c
[2/446] Performing configure step for 'PioasmBuild'
FAILED: pico-sdk/src/rp2_common/pico_cyw43_driver/pioasm/src/PioasmBuild-stamp/PioasmBuild-configure
cmd.exe /C "cd /D W:\c\pioasm && C:\DEV\CMake\bin\cmake.exe -DCMAKE_MAKE_PROGRAM:FILEPATH=C:/DEV/ARM/bin/ninja.exe -GNinja -CW:/c/pico-sdk/src/rp2_com
mon/pico_cyw43_driver/pioasm/tmp/PioasmBuild-cache-Release.cmake C:/DEV/SDK/tools/pioasm && C:\DEV\CMake\bin\cmake.exe -E touch W:/c/pico-sdk/src/rp2_
common/pico_cyw43_driver/pioasm/src/PioasmBuild-stamp/PioasmBuild-configure"
loading initial cache file W:/c/pico-sdk/src/rp2_common/pico_cyw43_driver/pioasm/tmp/PioasmBuild-cache-Release.cmake
-- The CXX compiler identification is unknown
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Check for working CXX compiler: C:/DEV/w64devkit/bin/c++.exe
-- Check for working CXX compiler: C:/DEV/w64devkit/bin/c++.exe - broken
CMake Error at C:/DEV/CMake/share/cmake-3.19/Modules/CMakeTestCXXCompiler.cmake:59 (message):
  The C++ compiler

    "C:/DEV/w64devkit/bin/c++.exe"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: W:/c/pioasm/CMakeFiles/CMakeTmp

    Run Build Command(s):C:/DEV/ARM/bin/ninja.exe cmTC_577fa && [1/2] Building CXX object CMakeFiles\cmTC_577fa.dir\testCXXCompiler.cxx.obj
    FAILED: CMakeFiles/cmTC_577fa.dir/testCXXCompiler.cxx.obj
    C:\DEV\w64devkit\bin\c++.exe    -o CMakeFiles\cmTC_577fa.dir\testCXXCompiler.cxx.obj -c testCXXCompiler.cxx
    ninja: build stopped: subcommand failed.





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:2 (project)


-- Configuring incomplete, errors occurred!
See also "W:/c/pioasm/CMakeFiles/CMakeOutput.log".
See also "W:/c/pioasm/CMakeFiles/CMakeError.log".

FAILED: elf2uf2/src/ELF2UF2Build-stamp/ELF2UF2Build-configure
cmd.exe /C "cd /D W:\c\elf2uf2 && C:\DEV\CMake\bin\cmake.exe -DCMAKE_MAKE_PROGRAM:FILEPATH=C:/DEV/ARM/bin/ninja.exe -GNinja C:/DEV/SDK/tools/elf2uf2 &
& C:\DEV\CMake\bin\cmake.exe -E touch W:/c/elf2uf2/src/ELF2UF2Build-stamp/ELF2UF2Build-configure"
-- The C compiler identification is unknown
-- The CXX compiler identification is unknown
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - failed
-- Check for working C compiler: C:/DEV/w64devkit/bin/cc.exe
-- Check for working C compiler: C:/DEV/w64devkit/bin/cc.exe - broken
CMake Error at C:/DEV/CMake/share/cmake-3.19/Modules/CMakeTestCCompiler.cmake:66 (message):
  The C compiler

    "C:/DEV/w64devkit/bin/cc.exe"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: W:/c/elf2uf2/CMakeFiles/CMakeTmp

    Run Build Command(s):C:/DEV/ARM/bin/ninja.exe cmTC_61015 && [1/2] Building C object CMakeFiles\cmTC_61015.dir\testCCompiler.c.obj
    FAILED: CMakeFiles/cmTC_61015.dir/testCCompiler.c.obj
    C:\DEV\w64devkit\bin\cc.exe    -o CMakeFiles\cmTC_61015.dir\testCCompiler.c.obj -c testCCompiler.c
    ninja: build stopped: subcommand failed.





  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:2 (project)


-- Configuring incomplete, errors occurred!
See also "W:/c/elf2uf2/CMakeFiles/CMakeOutput.log".
See also "W:/c/elf2uf2/CMakeFiles/CMakeError.log".
ninja: build stopped: subcommand failed.

Error logs below. 1.17, 1.18 the same result.
CMakeError.log
CMakeError.log
From CLion settings:

-- The C compiler identification is GNU 12.2.0
-- The CXX compiler identification is GNU 12.2.0
-- Check for working C compiler: C:/DEV/w64devkit/bin/gcc.exe
CMake Error: Generator: execution of make failed. Make command was: C:/DEV/w64devkit/bin/mingw32-make.exe cmTC_3c64e/fast && 
-- Check for working C compiler: C:/DEV/w64devkit/bin/gcc.exe - broken
CMake Error at C:/DEV/CLion/bin/cmake/win/share/cmake-3.17/Modules/CMakeTestCCompiler.cmake:60 (message):
  The C compiler

    "C:/DEV/w64devkit/bin/gcc.exe"

  is not able to compile a simple test program.

  It fails with the following output:

    Change Dir: C:/Users/Mateusz/AppData/Local/Temp/cmake_check_environment/_build4737323436450688909/CMakeFiles/CMakeTmp
    
    Run Build Command(s):C:/DEV/w64devkit/bin/mingw32-make.exe cmTC_3c64e/fast && Access violation
    Generator: execution of make failed. Make command was: C:/DEV/w64devkit/bin/mingw32-make.exe cmTC_3c64e/fast && 
    

  

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:1 (project)


-- Configuring incomplete, errors occurred!
See also "C:/Users/Mateusz/AppData/Local/Temp/cmake_check_environment/_build4737323436450688909/CMakeFiles/CMakeOutput.log".
See also "C:/Users/Mateusz/AppData/Local/Temp/cmake_check_environment/_build4737323436450688909/CMakeFiles/CMakeError.log".

Error code: 1

Other from https://www.mingw-w64.org/downloads/ work: LLVM-MinGW, MingW-W64-builds, WinLibs.com.

GDB crashes

Hi,

I downloaded w64devkit-1.7.0.zip and typing "GDB" brings up an appcrash dialog box saying "gdb.exe has stopped working".

The w64devkit shell still remains open after I close this box. I can get as far as the GDB welcome screen by directly clicking on the gdb.exe file from Windows Explorer, and it opens up a command prompt, but the crash window still appears if I type in anything.

I'm running on Windows-7 Ultimate SP1, 64-bit. Other functions in this devkit seem to be working ok: so far I've tried vim, gvim, cc, make, and compiled the Asteroids demo.

========
Thanks for your efforts. I'm trying this out as a step-up from running Turbo-C++ 3.0 under DosBox, and I'm loathe to download many gigabytes of VS Community just to continue the beginner exercises from the "K&R" & "Modern Approach" C books.

========

add libcsptr?

https://github.com/Snaipe/libcsptr

Running w64devkit.exe from an existing cmd.exe prompt

(This might be an odd question.)

Can I run w64devkit.exe from an existing cmd.exe prompt? Or it's meant to be run standalone by simply executing w64devkit.exe?

collect2.exe: fatal error: cannot find 'ld' compilation terminated.

Support Guile scripts for gdb?

Currently, the GDB provided doesn't have support for either of the scripting languages GDB supports (Python and Guile)

Python isn't currently supported, because CPython isn't supporting cross-compilation with a windows target, but it seems Guile does. At least, here is one repository claiming to do just that:

https://github.com/Madsy/guile-automatic-build

https://sourceware.org/gdb/current/onlinedocs/gdb.html/Writing-a-Guile-Pretty_002dPrinter.html
Here, it's also documented that you can write gdb pretty-printers using Guile. This could potentially be a solution for #16, though I'm not certain about this.

I think it's worth some investigation either way, I figured I'd open this issue in case anyone else has already discovered some info regarding why this may or may not be possible.

Make tool Windows 11 CreateProcess stucks

Trying to compile llama.cpp https://github.com/ggerganov/llama.cpp

What come across , checked the Makefile , there are some (uname ) e.t.c. none of them work well (stuck )

make tool , is invoking CreateProcess ( and it's never quit :( ) ,manually terminating process(uname ) bring another e.t.c. so never works well for spawning proceses.

1.17 ,1.18,1.19 , no luck same issue with make tool :(

C:/Development/ML/llama.cpp $ make --no-silent -d
GNU Make 4.4
Built for x86_64-w64-mingw32
Copyright (C) 1988-2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later https://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
find_and_set_shell() path search set default_shell = C:/Development/ML/w64devkit/bin/sh.exe
Reading makefiles...
Reading makefile 'Makefile'...
CreateProcess(C:\Development\ML\w64devkit\bin\uname.exe,uname -s,...)

Simple application "hello-world.c" can compile.. I suspect something has been "changed" with "CreateProcess" since make tool not works well...

Add ability to choose shell for running build rules

Certain Makefiles, like the one raylib has use the cmd.exe builtin command del to delete files for targets like make clean. That means these targets fail while running under w64devkit's make and mingw32-make

make clean
del *.o /s
sh: del: not found
make: *** [Makefile:734: clean] Error 127

https://github.com/raysan5/raylib/blob/1e436be51d4f8853c3494a0753eabe7628ac6d90/src/Makefile#L733
Is there any way that you would suggest to deal with this from the perspective of the Makefile? Because I can't really think of a solution to the problem as-is.
Perhaps mingw32-make should run build rules under cmd.exe, as is the behavior for most other distributions of mingw-w64, while make should run build rules under the busybox shell, for a user expecting to use unix commands in his Makefile.

Any Luck building Emacs?

[BUG] make v4.4 seems to be picking binaries located last in my %PATH% order

Assuming it was the make upgrade.

Trying to compile https://github.com/andrei-drexler/ironwail/ ends with an error[0] but once I export a trimmed down PATH envvar[1], removing the cygwin compiled lftp dir from it, ironwail compilation succeeds.

To replicate: grab https://f001.backblazeb2.com/file/nwgat-cdn/lftp/win64/lftp-4.9.2.win64-openssl.zip, unzip it somewhere, add the path of the unzipped included ./bin/ dir to your %PATH%, restart/refresh your environment; grab ironwail's zipped src from the above linked repo, unzip, cd to the ./Quake subdir, and issue make -f Makefile.w64

This is not an issue in version 1.16.1.

[0]: https://i.imgur.com/u22hfZu.png
[1]: https://i.imgur.com/HnNuxnF.png

The lftp binary I use ships with cygwin pre-compiled bins for sh.exe, bash.exe and ssh.exe.

Issue of `x86_64-w64-mingw32-windres'

I used w64devkit to compile latest busybox-w32 of master branch. And I got an error when I execute this command as below:

x86_64-w64-mingw32-windres -D"KBUILD_STR(s)=#s" -D"BB_VER=KBUILD_STR(1.36.0.git)" -D"BB_VERSION=1" -D"BB_PATCHLEVEL=36" -D"BB_SUBLEVEL=0" -D"BB_EXTRAVERSION=0" --include-dir=/busybox-w32-master/include --include-dir=/busybox-w32-master/win32/resources win32/resources/resources.rc win32/resources/resources.o

I got error as below:

<command-line>: warning: ISO C99 requires whitespace after the macro name x86_64-w64-mingw32-windres: win32/resources/resources.rc:21: syntax error

When I substitue x86_64-w64-mingw32-windres.exe(3KB) with msys2 windres.exe(2.3MB), and execute again, it works without any error.

So I think there's some issue about windres in w64devkit. If this issue is solved, w64devkit is able to build latest busybox-w32.

pacman?

I'm not sure if it fits with your design goals or not, but have you considered including pacman? I think that would make it a lot easier to add other tools.

`ar` archiver issue

When using w64devkit ar tool, I got a popup about an errors on libdep.a. The popup appears twice and after accepting it both times the library is correctly archived and works on further compilations with no error. It happens with both i686 and x86_64 versions.

Environment:

  CPU: Intel(R) Core(TM) i7-3537U CPU @ 2.00GHz
  RAM: 8 GB
  OS: Windows 10 Pro 64bit (21H1, 19043.1165)

  Command line: 
    C:\raylib\w64devkit\bin\ar.exe rcs libraylib.a rcore.o rglfw.o rshapes.o rtextures.o rtext.o rmodels.o raudio.o utils.o

I'll try on a second computer to see if it happens the same.

heads up - possible issues with gcc 13.1

I've compiled wasm3 in w64dekvit (using standard cmake for windows, used with -G "MinGW Makefiles" to generate makefiles which use cmd.exe instead of sh because it doesn't quite work with busybox-w32 sh), and I'm noticing random errors while running wasm files with wasm3 compiled with w64devkit 1.19.0 (x86-64) but no issues with 1.18.0 (also 64), and also no issues with the same wasm file with other wasi runners, like wasmer and wasmtime.

So I'm suspecting either some issue with gcc 13.1 (w64dekvit 1.19) compared to 12.2 (w64dk 1.18), or, probably not unimaginable, some dodgy code in wasm3 which happens to work with gcc 12.2 but not 13.1. The compilation does have quite a few warnings, and the code does try to squeeze performance where possible, I think.

That's the only evidence I have so far, and I've not explored it further, so this is just a heads up.

I can provide the wasm3 binaries and test files if needed.

zip error: Invalid command arguments (cannot write zip file to terminal)

Dockerfile:481 CMD zip -qXr - $PREFIX

When you use "-" as the destination file for the zip command, it tells zip to write the output to the standard output (i.e. the terminal)

suggested:

CMD zip -qXr w64devkit.zip $PREFIX

Busybox only environment bootstrapping

For the record, you'll find here:

https://gist.github.com/d-faure/5f89d9d2692f24d54cf336a8c12dda98

my way to start a portable busybox environment "from scratch"