Oolite Bulletins

I have now changed the dependency and installer setup GitHub repositories to build UCRT64 Clang and MinGW64 GCC builds of dependencies and Oolite. The UCRT64 Clang installers are here: https://github.com/mcarans/oolite_windo ... /tag/0.0.6

I've updated the READMEs of both repositories to make it clear how to set things up locally.
https://github.com/mcarans/oolite_windows_installer
https://github.com/mcarans/oolite_windeps_build (renamed from oolite_mingw64_environment)

Changes were needed to Oolite to remove hardcodings to /mingw64.

Also the builds now use MSYS2 standard pcaudiolib and espeak-ng packages instead of building them.

The : 1 issue is fixed in latest libobjc2, so I reverted the change to remove : 1 in entity.h ie. I changed it back to:
Note that while the install.sh changes are well tested (not least by the GitHub Actions workflows), I haven't tested the local setups from scratch via setup.cmd changes, but they were simple enough so hopefully I didn't make any mistakes. Please let me know if you try them out.

I tried to set up the clang environment by running RunMe.lnk and it failed - these are the last messages leading to failure:



List of packages in the packages folder:

Never mind, I'm dumb. I had checked out the wrong branch from the installer repo. Clang UCRT64 works fine. Good stuff.

another_commander wrote: ↑Sun Dec 07, 2025 1:53 am

Never mind, I'm dumb. I had checked out the wrong branch from the installer repo. Clang UCRT64 works fine. Good stuff.

Thanks for clarifying.

Just a note that although the GNUMakefile contains this for clang,: it appears that the flag -fobjc-runtime=gnustep-2.2, at least on the Windows build, is passed to the compiler and linker regardless. This means that apparently setting cc=/ucrt/bin/clang and cxx=/ucrt/bin/clang++ is not a requirement for Windows. The resulting binary is exactly the same whether cc and cxx are set or not and this has been also confirmed by checking the output of the build using messages=yes in the build command and analyzing the binaries with Executable File Explorer.

Oh and one more thing. With the modern build (especially the Clang variant) the minimum OS requirement for Oolite on Windows now becomes Windows 10.

I am perfectly fine with this. Windows 7 is now out of circulation for many years and anyone using it to connect to the internet and download Oolite should be aware that just by connecting to the web they have already compromised their systems from a security standpoint. Windows 10 has also just reached its end of life. Keeping support for Windows 10 and 11 only seems just the sensible thing to do.

another_commander wrote: ↑Sun Dec 07, 2025 12:43 pm

Just a note that although the GNUMakefile contains this for clang,:

Code: Select all

# Add flag if building with GNUStep and Clang
ifneq '' '$(GNUSTEP_HOST_OS)'
    ifneq '' '$(findstring clang++,$(CXX))'
        ADDITIONAL_OBJCFLAGS += -fobjc-runtime=gnustep-2.2
    endif
endif

it appears that the flag -fobjc-runtime=gnustep-2.2, at least on the Windows build, is passed to the compiler and linker regardless. This means that apparently setting cc=/ucrt/bin/clang and cxx=/ucrt/bin/clang++ is not a requirement for Windows. The resulting binary is exactly the same whether cc and cxx are set or not and this has been also confirmed by checking the output of the build using messages=yes in the build command and analyzing the binaries with Executable File Explorer.

I can confirm the same is true in Linux. It makes sense as I suppose the flag gets added and the compiler set by the sourcing of the GNUStep config and/or the GNUStep make mechanism. I must have been overriding it before when I was setting it to gnustep-1.9 but that override isn't needed when the GNUStep make build is configured with the correct objc runtime value.

On the Windows 10 minimum requirement, I don't think it would be realistic to support Windows 7 and it seems unlikely anyone is using it to play Oolite so it seems reasonable to me.