Difficulties creating a static executable on Windows

[atricap]

Hey all,

first, it's quite impressive what you pulled up with Janet. Me myself, I really love Clojure and its variants, and being able to use that to create a stand-alone binary to distribute it to non-developer colleagues or friends using Windows seemed a great idea. I also wanted to integrate GUI possibilities for small tools.

Now, I'm used to write some lines of host language code (Java) to bootstrap Clojure. But unfortunately with Janet, that bit turned out to be way too much ceremony in the end.

I recorded my tries to get a statically linked executable in my repo in the hope that it could be useful to improve JPM, which seemed to totally ignore my LDFLAGS and static linking wishes. Additionally I'll provide you with the discussion with Gemini, trying to get a working stand-alone .exe. You can see that it's rather long-winded, but logically organized, and was quite a journey.

I'm also willing to test out a few changes to JPM and the build process, if that helps. Though I have to admit, I'm not into the nitty-gritty details of linking, makefiles, and C in general, and didn't get deep into the JPM sources, but I know C99 and some of the backgrounds.

Cheers!

[strangepete]

What was the output of jpm --verbose when you build using your project.janet? Have you tried :ldflags?

I've only used jpm on Windows using VS build tools, not mingw, so I probably can't help much otherwise. I do need to use the 'Developer Command Prompt' to build, not sure if that applies to mingw.

[atricap]

Ok, I've removed the Makefile and bootstrap.c, and moved build.janet into the project dir.

$ jpm --verbose build
generating executable c source build/j1.exe.c from main.janet...
compiling build/j1.exe.c to build/build___j1.exe.o...
cc -c build/j1.exe.c -DJANET_BUILD_TYPE=release -std=c99 -IC:/msys64/usr/local/include/janet -IC:/Users/mx/janet -O2 -o build/build___j1.exe.o
linking build/j1.exe...
cc -std=c99 -IC:/msys64/usr/local/include/janet -IC:/Users/mx/janet -O2 -o build/j1.exe build/build___j1.exe.o C:/msys64/usr/local/lib/libjanet.lib -static -static-libgcc -LC:/msys64/usr/local/lib -ljanet -lws2_32 -lpsapi -lshlwapi -luserenv -lws2_32 -lwsock32 -lpsapi

$ ldd build/j1.exe
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffe03280000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffe01a70000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffe00b70000)
        ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ffdffcd0000)
        api-ms-win-crt-environment-l1-1-0.dll => not found
        api-ms-win-crt-heap-l1-1-0.dll => not found
        api-ms-win-crt-locale-l1-1-0.dll => not found
        api-ms-win-crt-math-l1-1-0.dll => not found
        api-ms-win-crt-private-l1-1-0.dll => not found
        api-ms-win-crt-runtime-l1-1-0.dll => not found
        api-ms-win-crt-stdio-l1-1-0.dll => not found
        api-ms-win-crt-string-l1-1-0.dll => not found
        libjanet.so => not found

$ jpm clean
Deleted build directory build

Now with :ldflags instead of :lflags:

$ jpm --verbose build
generating executable c source build/j1.exe.c from main.janet...
compiling build/j1.exe.c to build/build___j1.exe.o...
cc -c build/j1.exe.c -DJANET_BUILD_TYPE=release -std=c99 -IC:/msys64/usr/local/include/janet -IC:/Users/mx/janet -O2 -o build/build___j1.exe.o
linking build/j1.exe...
cc -std=c99 -IC:/msys64/usr/local/include/janet -IC:/Users/mx/janet -O2 -o build/j1.exe build/build___j1.exe.o -static -static-libgcc -LC:/msys64/usr/local/lib -ljanet -lws2_32 -lpsapi -lshlwapi -luserenv C:/msys64/usr/local/lib/libjanet.lib -lws2_32 -lwsock32 -lpsapi

$ ldd build/j1.exe
        ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffe03280000)
        KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ffe01a70000)
        KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll (0x7ffe00b70000)
        ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ffdffcd0000)
        PSAPI.DLL => /c/WINDOWS/System32/PSAPI.DLL (0x7ffe02e40000)
        WS2_32.dll => /c/WINDOWS/System32/WS2_32.dll (0x7ffe02db0000)
        RPCRT4.dll => /c/WINDOWS/System32/RPCRT4.dll (0x7ffe01ea0000)
        WSOCK32.dll => /c/WINDOWS/SYSTEM32/WSOCK32.dll (0x7ffdf8fa0000)
        msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ffe013a0000)
        MSWSOCK.DLL => /c/WINDOWS/SYSTEM32/MSWSOCK.DLL (0x7ffdfee10000)

$ build/j1.exe a b "c d"
hello, world!C:\Users\mx\Projects\janet1\build\j1.exeabc d

Wow, :ldflags seems to have been the trick! :lflags was proposed by Gemini, which isn't always flawless of course. And me having no experience with gcc, could not recognize the mistake. Actually, now that I've read about it, it is apparent to me, that we should not bother "Lex", but the linker. So great hint, thanks! According to ldd output, I also assume that j1.exe should be runnable on a system without the build tools, too.

Nevertheless, I further would have liked to include Puny GUI. But that seems to need me to clone and build iup, im-toolkit, SQLite, and who knows what (not yet looked at, what things are really needed), and then having to stitch together the whole build process of all involved libraries. So I'll take the opportunity, and in the meantime will learn some Rust to compile a standalone GUI binary. Now that the "hello world" build process runs, I always can come back and do some further tinkering.

In case it wasn't apparent, I'd like to highlight that when trying to get the "hello world" to build, I was having trouble to find in the Janet and JPM docs information about how to setup things. E.g. I couldn't find documentation and samples for the build.janet file. If it had been 5 years ago, when Gemini didn't even exist yet, I wouldn't have come this far.

[strangepete]

I was less confident in the differences between ldflags and lflags after looking at an old project of mine (which was also a module, not an exe) so I ran it by both claude and chatgpt and they gave exactly opposite answers 😂 LLMs don't do well with Janet, especially writing it. Best to ask on the Zulip chat

The docs are definitely improving, but I believe mingw support is a fairly recent addition, and only a few people here have discussed static builds as there are some downsides.

That said, there is a newer bundle/build system in the works, that you could tryout instead of jpm

[sogaiu]

For future readers...

• Another alternative to having some GUI bits might be this.
• Here is a relatively recent (2025-12) interview with bakpakin that touches on the state of things a bit.
• Here is an older discussion about the goals of the project and some other background for some context. Note that it's from over 5 years ago (2021-01).