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 <ken.cunningham.web...@gmail.com>, 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.000000000 +0800 > +++ src/libc_override_osx.h 2023-01-19 20:14:36.000000000 +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 <vital....@gmail.com> 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. > > >
