Re: Support for unreleased beta apple operating systems (was Support for ancient machines and operating systems)
To conclude gperftools topic: The following commit drops local rosetta patch, as well as another patch, since both issues are fixed in upstream. It also fixes a broken tests target and updates the port to 2.15. https://github.com/macports/macports-ports/pull/22097/commits/005cd16fae819210578ac2ccdc9b9775dbc06b95 CMake build system does not work nicely for tests with this port, but with makefiles build of 2.15 release results are: 14.2.1 arm64: PASS: 43 FAIL: 3 10.6 ppc: PASS: 39 FAIL: 7 Looks like I did not cause any “wreckage” after all, and 10.6 ppc with makefiles (which was the system I used back then, when added support for tests for this port) performs better than Sonoma with CMake. (No exaggeration, it is literally the case: with CMake 12 tests fail on 14.2.1.) On Tue, Jan 9, 2024 at 8:34 PM Sergey Fedorov wrote: > So, to Ken’s claim re gperftools. > > > And now there it sits in the ports tree, a useless MacPorts-only patch, > just waiting to break something. > > To begin with, this is a false statement. The patch is NOT MacPorts-only > but backported from the upstream. Of course, Ken did not bother to take a > look. > Here it is in the master: > https://github.com/gperftools/gperftools/blob/365060c4213a48adb27f63d5dfad41b3dfbdd62e/src/libc_override_osx.h#L274-L283 > > > Would it still work properly on 10.6 Intel? > > Ironically, since the build system was switched to experimental CMake (not > by me), tests target is just broken. Apparently no one ever tried to run > tests for it, despite such a great concern that my fix for PPC could have > broken something. > This commit switched the build system: > > https://github.com/macports/macports-ports/commit/7375653e34deb7d53d4223fcb81cf1aaadf8f963 > > I ran tests on 10.6.8 x86_64 (default clang etc.) now from makefiles > build, with and without my patch. Some tests fail, but regardless of adding > the patch (that is, same tests fail). > I also tried to run tests with CMake build system after fixing the target, > and nearly same failures happen, though tcmalloc_unittest fails with CMake > but passes with makefiles. > In all three cases getpc_test either freezes or gonna take forever, and I > have no time to wait right now. > > So far I can see that a move to CMake did break some stuff, but my patch > is inconsequential. > > > Does it work at all on 10.6 for PPC? Who can tell? > > Certainly you could try running tests and tell us, since you somehow find > sufficient time to discourage supporting PPC. > But anyway, this is from makefiles build on 10.6.8 Rosetta: > > :info:test /usr/bin/make pprof_unittest > :info:test ./src/pprof -test > :info:test AddressAdd 32-bit tests: 5 passes, 0 failures > :info:test AddressAdd 64-bit tests: 10 passes, 0 failures > :info:test AddressSub 32-bit tests: 5 passes, 0 failures > :info:test AddressSub 64-bit tests: 10 passes, 0 failures > :info:test AddressInc 32-bit tests: 5 passes, 0 failures > :info:test AddressInc 64-bit tests: 10 passes, 0 failures > :info:test PASS > :info:test /usr/bin/make check-TESTS > :info:test ./src/pprof -test > :info:test AddressAdd 32-bit tests: 5 passes, 0 failures > :info:test AddressAdd 64-bit tests: 10 passes, 0 failures > :info:test AddressSub 32-bit tests: 5 passes, 0 failures > :info:test AddressSub 64-bit tests: 10 passes, 0 failures > :info:test AddressInc 32-bit tests: 5 passes, 0 failures > :info:test AddressInc 64-bit tests: 10 passes, 0 failures > :info:test PASS > :info:test PASS: low_level_alloc_unittest > :info:test PASS: atomicops_unittest > :info:test ./test-driver: line 112: 40951 Abort trap "$@" >> > "$log_file" 2>&1 > :info:test FAIL: stacktrace_unittest > :info:test PASS: tcmalloc_minimal_unittest > :info:test PASS: tcm_min_asserts_unittest > :info:test PASS: tcmalloc_minimal_large_unittest > :info:test PASS: tcmalloc_minimal_large_heap_fragmentation_unittest > :info:test PASS: addressmap_unittest > :info:test PASS: system_alloc_unittest > :info:test PASS: packed_cache_test > :info:test PASS: frag_unittest > :info:test PASS: markidle_unittest > :info:test PASS: current_allocated_bytes_test > :info:test PASS: malloc_hook_test > :info:test PASS: malloc_extension_test > :info:test PASS: malloc_extension_c_test > :info:test PASS: page_heap_test > :info:test PASS: pagemap_unittest > :info:test PASS: realloc_unittest > :info:test PASS: stack_trace_table_test > :info:test PASS: thread_dealloc_unittest > :info:test PASS: tcmalloc_minimal_debug_unittest > :info:test PASS: malloc_extension_debug_test > :info:test PASS: realloc_debug_unittest > :info:test rm -f debugallocation_test.sh > :info:test cp -p ./src/tests/debugallocation_test.sh > debugallocation_test.sh > :info:test FAIL: debugallocation_test.sh > :info:test rm -f tcmalloc_unittest.sh > :info:test cp -p ./src/tests/tcmalloc_unittest.sh tcmalloc_unittest.sh > :info:test FAIL: tcmalloc_unittest.sh > :info:test PASS: tcm_asserts_unittest > :info:test PASS: tcmalloc_large_unittest > :info:test PASS: tc
Re: Support for unreleased beta apple operating systems (was Support for ancient machines and operating systems)
So, to Ken’s claim re gperftools. > And now there it sits in the ports tree, a useless MacPorts-only patch, just waiting to break something. To begin with, this is a false statement. The patch is NOT MacPorts-only but backported from the upstream. Of course, Ken did not bother to take a look. Here it is in the master: https://github.com/gperftools/gperftools/blob/365060c4213a48adb27f63d5dfad41b3dfbdd62e/src/libc_override_osx.h#L274-L283 > Would it still work properly on 10.6 Intel? Ironically, since the build system was switched to experimental CMake (not by me), tests target is just broken. Apparently no one ever tried to run tests for it, despite such a great concern that my fix for PPC could have broken something. This commit switched the build system: https://github.com/macports/macports-ports/commit/7375653e34deb7d53d4223fcb81cf1aaadf8f963 I ran tests on 10.6.8 x86_64 (default clang etc.) now from makefiles build, with and without my patch. Some tests fail, but regardless of adding the patch (that is, same tests fail). I also tried to run tests with CMake build system after fixing the target, and nearly same failures happen, though tcmalloc_unittest fails with CMake but passes with makefiles. In all three cases getpc_test either freezes or gonna take forever, and I have no time to wait right now. So far I can see that a move to CMake did break some stuff, but my patch is inconsequential. > Does it work at all on 10.6 for PPC? Who can tell? Certainly you could try running tests and tell us, since you somehow find sufficient time to discourage supporting PPC. But anyway, this is from makefiles build on 10.6.8 Rosetta: :info:test /usr/bin/make pprof_unittest :info:test ./src/pprof -test :info:test AddressAdd 32-bit tests: 5 passes, 0 failures :info:test AddressAdd 64-bit tests: 10 passes, 0 failures :info:test AddressSub 32-bit tests: 5 passes, 0 failures :info:test AddressSub 64-bit tests: 10 passes, 0 failures :info:test AddressInc 32-bit tests: 5 passes, 0 failures :info:test AddressInc 64-bit tests: 10 passes, 0 failures :info:test PASS :info:test /usr/bin/make check-TESTS :info:test ./src/pprof -test :info:test AddressAdd 32-bit tests: 5 passes, 0 failures :info:test AddressAdd 64-bit tests: 10 passes, 0 failures :info:test AddressSub 32-bit tests: 5 passes, 0 failures :info:test AddressSub 64-bit tests: 10 passes, 0 failures :info:test AddressInc 32-bit tests: 5 passes, 0 failures :info:test AddressInc 64-bit tests: 10 passes, 0 failures :info:test PASS :info:test PASS: low_level_alloc_unittest :info:test PASS: atomicops_unittest :info:test ./test-driver: line 112: 40951 Abort trap "$@" >> "$log_file" 2>&1 :info:test FAIL: stacktrace_unittest :info:test PASS: tcmalloc_minimal_unittest :info:test PASS: tcm_min_asserts_unittest :info:test PASS: tcmalloc_minimal_large_unittest :info:test PASS: tcmalloc_minimal_large_heap_fragmentation_unittest :info:test PASS: addressmap_unittest :info:test PASS: system_alloc_unittest :info:test PASS: packed_cache_test :info:test PASS: frag_unittest :info:test PASS: markidle_unittest :info:test PASS: current_allocated_bytes_test :info:test PASS: malloc_hook_test :info:test PASS: malloc_extension_test :info:test PASS: malloc_extension_c_test :info:test PASS: page_heap_test :info:test PASS: pagemap_unittest :info:test PASS: realloc_unittest :info:test PASS: stack_trace_table_test :info:test PASS: thread_dealloc_unittest :info:test PASS: tcmalloc_minimal_debug_unittest :info:test PASS: malloc_extension_debug_test :info:test PASS: realloc_debug_unittest :info:test rm -f debugallocation_test.sh :info:test cp -p ./src/tests/debugallocation_test.sh debugallocation_test.sh :info:test FAIL: debugallocation_test.sh :info:test rm -f tcmalloc_unittest.sh :info:test cp -p ./src/tests/tcmalloc_unittest.sh tcmalloc_unittest.sh :info:test FAIL: tcmalloc_unittest.sh :info:test PASS: tcm_asserts_unittest :info:test PASS: tcmalloc_large_unittest :info:test PASS: tcmalloc_large_heap_fragmentation_unittest :info:test PASS: raw_printer_test :info:test PASS: sampler_test :info:test rm -f sampling_test.sh :info:test cp -p ./src/tests/sampling_test.sh sampling_test.sh :info:test FAIL: sampling_test.sh :info:test rm -f heap-profiler_unittest.sh :info:test cp -p ./src/tests/heap-profiler_unittest.sh heap-profiler_unittest.sh :info:test FAIL: heap-profiler_unittest.sh :info:test PASS: simple_compat_test :info:test PASS: tcmalloc_debug_unittest :info:test PASS: sampler_debug_test :info:test rm -f sampling_debug_test.sh :info:test cp -p ./src/tests/sampling_test.sh sampling_debug_test.sh :info:test FAIL: sampling_debug_test.sh :info:test rm -f heap-profiler_debug_unittest.sh :info:test cp -p ./src/tests/heap-profiler_unittest.sh heap-profiler_debug_unittest.sh :info:test FAIL: heap-profiler_debug_unittest.sh This is on 10.6.8 x86_64: :info:test /usr/bin/make pprof_unittest :info:test ./src/pprof -test :info:test AddressAdd 32-bit tests: 5 passes, 0 failures :info:test
Re: Support for unreleased beta apple operating systems (was Support for ancient machines and operating systems)
On Jan 9, 2024 at 03:37 +0800, Joshua Root , wrote: > On 9/1/2024 05:26, Perry E. Metzger wrote: > > On 1/8/24 12:50, Sergey Fedorov wrote: > > > 2. Standard 10.6.8 release from Apple does support building and > > > running ppc binaries via Rosetta. > > > > Why would one want to spend time and effort on doing that, though? > > You wouldn't, if you were running a public release of 10.6. The ppc libs > were put there to support existing ppc binaries, which will have been > built targeting 10.5 or older. With MacPorts, native x86_64 or i386 > builds would be far preferable. Unless, of course, you're running on a > CPU that can't run those archs, which can only be the case if you are > running an early development version of the OS. Yet gcc supports 10.6.8 Rosetta in the master. Current gcc. (And no, it is not me who brought it there.) > > So far as I can tell, the project's primary goal is to provide support > > for the millions of people who run MacOS on current hardware and > > operating systems and want up to date software for their machine. The > > goal is not (primarily) to assist in running PPC binaries on Rosetta on > > 20 year old hardware for the couple of people for whom that is > > interesting. Certainly there's nothing wrong with supporting that to the > > extent that it does not interfere with the primary goal. > > As a reminder, the project policy is (and has been virtually since the > beginning) to support the versions of macOS that are still getting > updates from Apple. That is the expectation for maintainers. Maintainers > can voluntarily support older stuff, but they are under no obligation to > so so. There is no obligation, obviously, no one claims there is, I believe. As for the policy, I can see that Macports offers distributives for older OS which do not get updates from Apple for years. This is much more than not prohibiting such builds. I did not dig through the whole of documentation, but I believe that if an installable binary for the specific OS is provided, there is an implication it should actually work. There is also no obligation to break something which a maintainer is not personally interested in.
Re: Support for unreleased beta apple operating systems (was Support for ancient machines and operating systems)
It is quite a jump from one to hundreds. I stand by my statement: you deliberately mislead everyone claiming that there are numerous 10a190-specific hacks. From memory I recall one merged fix which was not required on standard 10.6.8 but was on 10a190. There are perhaps a dozen which are not required on 10a190 but required on standard 10.6.8 Rosetta, for the reason I pointed earlier: arch gets misdetected. tcmalloc stuff, as I recall, is common and not 10a190-specific. I will check that. If the specific case is wrong (I need to look into the thing), it should be made correct, of course; I never claimed that my code is a priori flawless. Unlike some, at least I don’t commit it straight into the master without even trying to build the thing ;) On Jan 9, 2024 at 12:31 +0800, Ken Cunningham , wrote: > I think you just don't realize the wreckage you've done. > > Here is one of hundreds of your typical commits, although this is a simpler > one than most, to be honest. > > The commit below has no purpose other than to allow the port to build as PPC > on 10.6. And as that is really only of interest on 10.6-for-PPC, it is > specifically for that. You say you want to support "Rosetta" but nobody > builds for PPC on 10.6. > > Here, you've reordered a few instructions, and blocked out some code from > running on PPC (presumably because the instructions don't exist on > 10.6-for-PPC so it wouldn't compile). > > However, this changes the code. And it's not simple code, it is complicated > code. Does this change the function of the code? Would it still work properly > on 10.6 Intel? Does it work at all on 10.6 for PPC? Who can tell? I certainly > don't think you have the experience to know. I can't eyeball it as being fine. > > It used to say: > > tcmalloc_zone.version = 6; > tcmalloc_zone.free_definite_size = &mz_free_definite_size; > tcmalloc_zone.memalign = &mz_memalign; > tcmalloc_introspection.zone_locked = &mi_zone_locked; > > and now it says (I think) on Intel: > > tcmalloc_zone.version = 6; > tcmalloc_zone.memalign = &mz_memalign; > tcmalloc_zone.free_definite_size = &mz_free_definite_size; > tcmalloc_introspection.zone_locked = &mi_zone_locked; > > and on 10.6-PPC you just get this: > > tcmalloc_zone.version = 6; > tcmalloc_zone.memalign = &mz_memalign; > > Does reordering those statements change the function? Does it work at all > with the two statements removed? It would take me considerable reading to > find out. It took me 10 minutes just to figure out what your patch did. > > And now there it sits in the ports tree, a useless MacPorts-only patch, just > waiting to break something. Some poor sot might bring an issue to upstream > about this, having no idea that this is not even upstream's code any more. > > And there are HUNDREDS of these all throughout the codebase that need to be > all stripped out. > > This is unfortunately a huge mess now. > > K > > > > > https://github.com/macports/macports-ports/commit/418232ebb3d0e68579364c6246de4464f8f494c9 > > == > --- src/libc_override_osx.h.orig 2021-12-13 14:28:06.0 +0800 > +++ src/libc_override_osx.h 2023-01-19 20:14:36.0 +0800 > @@ -276,9 +276,11 @@ > MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_6 > // Switch to version 6 on OSX 10.6 to support memalign. > tcmalloc_zone.version = 6; > - tcmalloc_zone.free_definite_size = &mz_free_definite_size; > tcmalloc_zone.memalign = &mz_memalign; > +#ifndef __POWERPC__ > + tcmalloc_zone.free_definite_size = &mz_free_definite_size; > tcmalloc_introspection.zone_locked = &mi_zone_locked; > +#endif > > // Request the default purgable zone to force its creation. The > // current default zone is registered with the purgable zone for > = > > > > > On Jan 8, 2024, at 9:50 AM, Sergey Fedorov wrote: > > > > Here we go again. > > > > 1. To begin with, nobody is submitting 10A190-specific fixes to Macports. > > They are sitting in my local repo. Please, do not mislead people who are > > unaware of the matter. > > > > 2. Standard 10.6.8 release from Apple does support building and running ppc > > binaries via Rosetta. Nothing unreleased or, as you [mis]frame, “stolen”. > > While I think your opposition is completely unjustified, there has been no > > demands or even active discussion about supporting pre-released builds on > > 10.6. The point is supporting officially released 10.6.8. > > > > 3. If anyone did wonder, the whole issue with 10A190 is literally ~20 ports > > altogether, and those fixes amount to a few lines of code to adjust a few > > assumptions re SDK. Despite it being portrayed as something like half of > > the Macports tree is broken and needs tailored hacks which gonna break > > everything. This is nowhere the case. > > However, as I said above, nobody demanded 10A190 being supported in the > > master. Nobody commits 10A190-specific fixups. > > > > 4. > “The problem was that there were many fragile and sharply increasing > > *specific* workaroun
Re: Support for unreleased beta apple operating systems (was Support for ancient machines and operating systems)
I think you just don't realize the wreckage you've done. Here is one of hundreds of your typical commits, although this is a simpler one than most, to be honest. The commit below has no purpose other than to allow the port to build as PPC on 10.6. And as that is really only of interest on 10.6-for-PPC, it is specifically for that. You say you want to support "Rosetta" but nobody builds for PPC on 10.6. Here, you've reordered a few instructions, and blocked out some code from running on PPC (presumably because the instructions don't exist on 10.6-for-PPC so it wouldn't compile). However, this changes the code. And it's not simple code, it is complicated code. Does this change the function of the code? Would it still work properly on 10.6 Intel? Does it work at all on 10.6 for PPC? Who can tell? I certainly don't think you have the experience to know. I can't eyeball it as being fine. It used to say: tcmalloc_zone.version = 6; tcmalloc_zone.free_definite_size = &mz_free_definite_size; tcmalloc_zone.memalign = &mz_memalign; tcmalloc_introspection.zone_locked = &mi_zone_locked; and now it says (I think) on Intel: tcmalloc_zone.version = 6; tcmalloc_zone.memalign = &mz_memalign; tcmalloc_zone.free_definite_size = &mz_free_definite_size; tcmalloc_introspection.zone_locked = &mi_zone_locked; and on 10.6-PPC you just get this: tcmalloc_zone.version = 6; tcmalloc_zone.memalign = &mz_memalign; Does reordering those statements change the function? Does it work at all with the two statements removed? It would take me considerable reading to find out. It took me 10 minutes just to figure out what your patch did. And now there it sits in the ports tree, a useless MacPorts-only patch, just waiting to break something. Some poor sot might bring an issue to upstream about this, having no idea that this is not even upstream's code any more. And there are HUNDREDS of these all throughout the codebase that need to be all stripped out. This is unfortunately a huge mess now. K https://github.com/macports/macports-ports/commit/418232ebb3d0e68579364c6246de4464f8f494c9 == --- src/libc_override_osx.h.orig 2021-12-13 14:28:06.0 +0800 +++ src/libc_override_osx.h 2023-01-19 20:14:36.0 +0800 @@ -276,9 +276,11 @@ MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_6 // Switch to version 6 on OSX 10.6 to support memalign. tcmalloc_zone.version = 6; - tcmalloc_zone.free_definite_size = &mz_free_definite_size; tcmalloc_zone.memalign = &mz_memalign; +#ifndef __POWERPC__ + tcmalloc_zone.free_definite_size = &mz_free_definite_size; tcmalloc_introspection.zone_locked = &mi_zone_locked; +#endif // Request the default purgable zone to force its creation. The // current default zone is registered with the purgable zone for = > On Jan 8, 2024, at 9:50 AM, Sergey Fedorov wrote: > > Here we go again. > > 1. To begin with, nobody is submitting 10A190-specific fixes to Macports. > They are sitting in my local repo. Please, do not mislead people who are > unaware of the matter. > > 2. Standard 10.6.8 release from Apple does support building and running ppc > binaries via Rosetta. Nothing unreleased or, as you [mis]frame, “stolen”. > While I think your opposition is completely unjustified, there has been no > demands or even active discussion about supporting pre-released builds on > 10.6. The point is supporting officially released 10.6.8. > > 3. If anyone did wonder, the whole issue with 10A190 is literally ~20 ports > altogether, and those fixes amount to a few lines of code to adjust a few > assumptions re SDK. Despite it being portrayed as something like half of the > Macports tree is broken and needs tailored hacks which gonna break > everything. This is nowhere the case. > However, as I said above, nobody demanded 10A190 being supported in the > master. Nobody commits 10A190-specific fixups. > > 4. > “The problem was that there were many fragile and sharply increasing > *specific* workarounds added into the ports tree solely to support running > this PowerPC beta on MacPorts”. > > This accusation keeps being repeated, but it is simply not true. You will not > be able to show multiple specific workarounds for 10A190 in Macports master. > They are not there. > There were a few specific fixes for standard 10.6.8 Rosetta, largely because > the makefile build system misdetects the arch. They are not numerous either, > and verily not sharply increasing. > > It will be great not to keep repeating false statements targeting those who > are unaware of the facts. >
Re: Support for unreleased beta apple operating systems (was Support for ancient machines and operating systems)
On 9/1/2024 05:26, Perry E. Metzger wrote: On 1/8/24 12:50, Sergey Fedorov wrote: 2. Standard 10.6.8 release from Apple does support building and running ppc binaries via Rosetta. Why would one want to spend time and effort on doing that, though? You wouldn't, if you were running a public release of 10.6. The ppc libs were put there to support existing ppc binaries, which will have been built targeting 10.5 or older. With MacPorts, native x86_64 or i386 builds would be far preferable. Unless, of course, you're running on a CPU that can't run those archs, which can only be the case if you are running an early development version of the OS. So far as I can tell, the project's primary goal is to provide support for the millions of people who run MacOS on current hardware and operating systems and want up to date software for their machine. The goal is not (primarily) to assist in running PPC binaries on Rosetta on 20 year old hardware for the couple of people for whom that is interesting. Certainly there's nothing wrong with supporting that to the extent that it does not interfere with the primary goal. As a reminder, the project policy is (and has been virtually since the beginning) to support the versions of macOS that are still getting updates from Apple. That is the expectation for maintainers. Maintainers can voluntarily support older stuff, but they are under no obligation to so so. - Josh
Re: Support for unreleased beta apple operating systems (was Support for ancient machines and operating systems)
To begin with, it is not up to me to decide what Macports should or should not do, it is not my project. However solution, if you ask me, if not to dump some users, who may be few, but interested to contribute (I think no one can honestly accuse me of fixing only PowerPC stuff – well, Ken may, but commit history is public), and not to give up on one major competitive advantage over Homebrew, but rather optimize how committing is done. Give commit access to others, and no one will need to waste time approving commits. For a note, I still think that PowerPC impact is overexaggerated, and mostly because there are some members who just hate the stuff, so every once in a while we get huge threads. I did not count, of course, but I think PPC-exclusive commits are not numerous, and when PPC fixes are done, they normally are done together with fixes for Intel or together with updates, so they should not take more time to merge. There is also not much problem to maintain ppc-specific code: if it is there at all, do not touch it, and it gonna work. PPC does not change much nowadays ;) On Tue, Jan 9, 2024 at 2:26 AM Perry E. Metzger wrote: > On 1/8/24 12:50, Sergey Fedorov wrote: > > 2. Standard 10.6.8 release from Apple does support building and > > running ppc binaries via Rosetta. > > Why would one want to spend time and effort on doing that, though? > > Just to be clear about my position on almost everything here: > > I don't mind people spending lots of time and effort making old things > stay working provided it doesn't cost anyone else anything. However, > there's a lot of stuff in our tree now devoted to patching modern > software to make it work on certain old versions of MacOS. There's a > cost to that in that other people have to think about it, read through > Portfiles trying to assure themselves that they don't need to think > about certain patches, etc. It adds complexity and time to the process > of maintaining stuff that runs for most people. > > So far as I can tell, the project's primary goal is to provide support > for the millions of people who run MacOS on current hardware and > operating systems and want up to date software for their machine. The > goal is not (primarily) to assist in running PPC binaries on Rosetta on > 20 year old hardware for the couple of people for whom that is > interesting. Certainly there's nothing wrong with supporting that to the > extent that it does not interfere with the primary goal. > > I worry that the interest of a small minority in their hobby of making > certain very old and specific configurations work is taking time away > from the rest of the project. Most of the people running on Macs use > Sonoma with ARM or Intel hardware. > > Perry > > >
Re: Support for unreleased beta apple operating systems (was Support for ancient machines and operating systems)
On 1/8/24 12:50, Sergey Fedorov wrote: 2. Standard 10.6.8 release from Apple does support building and running ppc binaries via Rosetta. Why would one want to spend time and effort on doing that, though? Just to be clear about my position on almost everything here: I don't mind people spending lots of time and effort making old things stay working provided it doesn't cost anyone else anything. However, there's a lot of stuff in our tree now devoted to patching modern software to make it work on certain old versions of MacOS. There's a cost to that in that other people have to think about it, read through Portfiles trying to assure themselves that they don't need to think about certain patches, etc. It adds complexity and time to the process of maintaining stuff that runs for most people. So far as I can tell, the project's primary goal is to provide support for the millions of people who run MacOS on current hardware and operating systems and want up to date software for their machine. The goal is not (primarily) to assist in running PPC binaries on Rosetta on 20 year old hardware for the couple of people for whom that is interesting. Certainly there's nothing wrong with supporting that to the extent that it does not interfere with the primary goal. I worry that the interest of a small minority in their hobby of making certain very old and specific configurations work is taking time away from the rest of the project. Most of the people running on Macs use Sonoma with ARM or Intel hardware. Perry
Re: Support for unreleased beta apple operating systems (was Support for ancient machines and operating systems)
Here we go again. 1. To begin with, nobody is submitting 10A190-specific fixes to Macports. They are sitting in my local repo. Please, do not mislead people who are unaware of the matter. 2. Standard 10.6.8 release from Apple does support building and running ppc binaries via Rosetta. Nothing unreleased or, as you [mis]frame, “stolen”. While I think your opposition is completely unjustified, there has been no demands or even active discussion about supporting pre-released builds on 10.6. The point is supporting officially released 10.6.8. 3. If anyone did wonder, the whole issue with 10A190 is literally ~20 ports altogether, and those fixes amount to a few lines of code to adjust a few assumptions re SDK. Despite it being portrayed as something like half of the Macports tree is broken and needs tailored hacks which gonna break everything. This is nowhere the case. However, as I said above, nobody demanded 10A190 being supported in the master. Nobody commits 10A190-specific fixups. 4. > “The problem was that there were many fragile and sharply increasing *specific* workarounds added into the ports tree solely to support running this PowerPC beta on MacPorts”. This accusation keeps being repeated, but it is simply not true. You will not be able to show multiple specific workarounds for 10A190 in Macports master. They are not there. There were a few specific fixes *for standard 10.6.8* Rosetta, largely because the makefile build system misdetects the arch. They are not numerous either, and verily not sharply increasing. It will be great not to keep repeating false statements targeting those who are unaware of the facts.
Support for unreleased beta apple operating systems (was Support for ancient machines and operating systems)
There is no hiccup in MacPorts support for PowerPC systems, despite the dramatic title of the PR. Also there is no hiccup in support for older released Apple operating systems. 10.4 and 10.5 remain fully supported by MacPorts (although 10.4 might be on last legs). There is also no need (IMHO) for a fork of MacPorts to support older Apple operating systems. What there was a difference of opinion about was whether MacPorts should provide *specific* and rather extensive support for an unreleased early PowerPC beta of an Apple operating system that was a stepping stone to what became MacOSX 10.6 that had been found in an old developer's drawer and released into the wild through various websites. The problem was that there were many fragile and sharply increasing *specific* workarounds added into the ports tree solely to support running this PowerPC beta on MacPorts. These were kludgy and hard to eyeball debug. Nobody could test them very well, as the number of users of this unreleased beta PowerPC SnowLeopard OS were extremely few. They were scattered throughout the ports tree and patches in ways that made them very difficult, and time consuming, to properly vet. MacPorts has always considered 10.6 as supporting i386 and x86_64, and a great many ports and portgroups were written with this in mind. That fits very nicely into the support MacPorts provides up to 10.13, that also support i386 and x86_64, so that whole block of systems can be managed often one unit. Once legacysupport came out, the number of changes in Portfiles that were needed to support 10.6 was actually very minimal, and that was the whole idea. However, to support a 10.6 PPC beta meant redoing a large number of these assumptions to accommodate cross-compiling PowerPC code. Different compilers, different universal options -- an entire redo. In addition, the 10.6 beta is missing a number functions and capabilities that 10.6.8 Intel has, and to 10.5.8 PowerPC has further fixups and enhancements added to it by Apple that never made it into the unreleased 10.6 beta. There is no reason anyone needs to use 10.6-for-PowerPC. Of course, you can if you want, and go ahead and make some changes in ports to support that if you care to. That is a reason for someone to fork MacPorts ports tree, but there is certainly no reason those changes need to be distributed to every MacPorts user. To be honest, I can't really believe we're even having the conversation about whether we support a specific unreleased stolen Apple OS from a developer's drawer that doesn't fit into the existing structure and requires hundreds or more additions to the ports tree. It was just nuts from the beginning to allow this into MacPorts. Ken
