Restore 10.6 support into 1.5.0 but mark it community-maintained #1426
Replies: 4 comments 1 reply
|
This "Issue" was converted to a "Discussion" in section "Development" where it belongs. @barracuda156 Restoring the code to build under 10.6 would be a lot of work, and despite your statement above, making this code conditional would also imply more maintenance work, particularly if (most of) FLTK devs can't test it. The decision to remove support of macOS < 10.7 was discussed thoroughly and decided by the FLTK Team, and this is not going to be changed. We're sorry, if you need macOS 10.6 or earlier (10.6.8 is now almost 15 years old), you need to use FLTK 1.4.x (or patch later versions yourself). This is in parts caused by Apple changing their internals very often such that supporting older macOS versions together with modern macOS needs a lot of changes and conditional code. BTW: a quick check of commits reveals that removing macOS support prior to 10.7 needed 9 commits or maybe more, doing it safely step by step, not all at once. Overall more than 1,100 lines of code could be removed by that decision. |
|
@barracuda156 But, if I attempt to build the same source code with the 10.6 SDK, CMake says the compiler is unable to compile any code. That is the evidence I have that 10.7 is the earliest macOS version supporting c++11. I would be curious to know how is it possible to compile c++11 code with the MacOS 10.6 SDK and the ppc architecture. I would also need to understand what use of a MacOS application for the ppc architecture and the 10.6 SDK can be done today, many years after Apple stopped making hardware under this architecture. |
|
@ManoloFLTK If you use modern gcc with its default libraries, everything works just fine. I can compile newer C++ on my 10.6 ppc than on 10.15 x86_64. One-step bootstrap from Xcode gcc is to build gcc10 specifically (later ones require bootstrap compiler to support C++11, which Xcode gcc does not). If you have x86_64 Apple hardware, you could install 10.6 in a VM, which will support ppc via its Rosetta. It won’t be blazing fast, but it is usable, so you could build FLTK locally. Besides, 10.6 with Rosetta allows to use my PPCPorts out of the box, so you get complete toolchain pre-built (or buildable from sources without manual hacking). Alternatively, Iain’s branches should be buildable without issues starting from vanilla Xcode (bootstrap sequence for 10.5/10.6 is gcc-4.2 > gcc-10 > gcc-whatever-the-latest).
If you mean cross-compiling (not via Rosetta), I think @Jazzzny has an experience of that, including builds for much earlier SDKs.
Physical scarcity is a real issue with no real solution, however Apple produced enough of PowerPC hardware for it to last for some years to come. G5’s are perfectly usable for a lot of modern tasks (not in a power-efficient manner, admittedly), and of course for software of the period, which is still used. So if the question is whether an app can be used normally on PowerMacs – yes, it can, unless we talk about some high-end visualization software (that won’t work due to old proprietary OpenGL). And IMO lightweight GUI toolkits are more meaningful on systems, where KDE6 is not a feasible choice. |
|
@barracuda156 I've managed to build gcc 16.1.0 for the MacOS 10.6 SDK here. With it, I can build FLTK's master branch for the 10.6 SDK and the |
|
The build works just fine with the patch applied, but I get a crash on launch (like earlier) in some ObjC++ stuff: I will look into this. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
@ManoloFLTK A few recent commits removed support for macOS 10.6, which makes FLTK unusable on powerpc, since 10.6 is the last OS to support it (unofficially natively, officially via Rosetta). It is undesirable, since even testing will be impossible, and carrying a local patch will be pretty troublesome, given a need of constant rebases (even when unrelated code is changed which modifies patch context lines).
Is it acceptable instead to restore the code, making it conditional, but explicitly state that no upstream testing for < 10.7 is done and maintenance is community-based? So that there is little to none maintenance burden for you, but FLTK remains usable for us.
Then I can verify the code still builds and works on every release, and submit fixes if needed.
P. S. This does not imply any changes to C++ standard requirement. C++23 works on 10.5.8, there is no problem about C++.
All reactions