andlabs
commented
5 years ago The goal is to reach a state where extensive C knowledge is NOT required — it should just be a standard go get package that follows standard cgo rules. 32-bit on a 64-bit system should be as easy as GOARCH=386 CGO_ENABLED=1 while running from the 32-bit MinGW shell in MSYS (or with the 32-bit MinGW in the path, or with CC= and CXX= set properly — either way, all standard cgo stuff).
First I need to go back and see which bugs are still relevant and which are outdated. libui Alpha 4 aimed to fix most of the big problems that people have reported over the years; Alpha 5 aims to eliminate them completely. Also, sadly, the rest of my answer will require some knowledge of how programming C/C++ on Windows works.
The MinGW problems are historical: gcc took its time to adopt Microsoft-style C++ exceptions and SEH support (which is a property of the generated code and thus must be done by the compiler), and so different MinGW configurations cannot be mixed and matched in a single static binary. It'd be easier if I could just ship libui as a DLL that has to be included alongside the output executables, but this would be very unpopular (especially since Go can't copy the DLL into the user's source directory). What I'm hoping is that there is a way to create a static archive that works with any configuration of MinGW-w64, but I haven't looked into whether this is possible or not.
As for -w64, that is because before -w64, all MinGW distributions were stuck with the Windows API as it was in Windows 2000, providing absolutely nothing introduced after 2001; libui requires Windows 7(-ish) at a minimum and freely uses newer APIs. Before libui, the C code lived as part of package ui itself, so attempting to build package ui with the older MinGW distributions failed. Now that libui is a binary blob that package ui links in, I'm betting that this is no longer true, unless MinGW-w64 produces object files that older MinGW linkers don't understand? If these older MinGW linkers don't look up the system DLLs but rather have their own .lib files for the system DLLs, they will also fail to link properly for the reason I stated above, as due to the way static archives work I can't list the system dependencies until the final link stage of a program that uses package ui!
As far as I could tell, most of these issues stem from people installing whatever compilers came with their IDEs. I don't know what to do about the IDEs being outdated. (And let's hope no IDE ships with either 32-bit or 64-bit but not both...)
The ideal ideal situation is that package ui could have been written in pure Go from the start (this implies libui never existed); doing that would require extreme changes to Go itself, alas.
I would have more to say but I don't have time right now. I'll definitely go back and look through the existing issues sometime today.
An observation: 20 out of 77 open issues in this project are about compiling. (>25%)
I myself spent an entire day just to figure out I actually absolutely need the specific version of MinGW that is
MingW-w64to be able to build the example projects on Windows x64. Even though it works now, there are some confusing options in the setup (POSIX vs. win32 threads and SEH vs. SJLJ vs. DWARF Exception Handling) which are unique to the C world. I am now already struggling with the next issue which is building a 32 bit executable on a 64 bit Windows.The real problem here is that there is no indication in the README.md that despite this being a Golang project, extensive C knowledge is required to use it. The README.md should do one of the following: 1) Disclaim responsibility for providing compilation instructions and explain that C knowledge is required. 2) Hand-hold users through the compilation process for at least native compilation on every OS/Arch combination.