
<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<title></title>

</head>

<body>

<div name="messageBodySection">

<div dir="auto">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.<br />

<br />

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.<br />

<br />

tcmalloc stuff, as I recall, is common and not 10a190-specific. I will check that.<br />

<br />

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.<br />

<br />

Unlike some, at least I don’t commit it straight into the master without even trying to build the thing ;) </div>

</div>

<div name="messageReplySection">On Jan 9, 2024 at 12:31 +0800, Ken Cunningham <ken.cunningham.webuse@gmail.com>, wrote:<br />

<blockquote type="cite" style="border-left-color: grey; border-left-width: thin; border-left-style: solid; margin: 5px 5px;padding-left: 10px;">I think you just don't realize the wreckage you've done.<br />

<br />

Here is one of hundreds of your typical commits, although this is a simpler one than most, to be honest.<br />

<br />

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.<br />

<br />

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).<br />

<br />

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.<br />

<br />

It used to say:<br />

<br />

tcmalloc_zone.version = 6;<br />

tcmalloc_zone.free_definite_size = &mz_free_definite_size;<br />

tcmalloc_zone.memalign = &mz_memalign;<br />

tcmalloc_introspection.zone_locked = &mi_zone_locked;<br />

<br />

and now it says (I think) on Intel:<br />

<br />

tcmalloc_zone.version = 6;<br />

tcmalloc_zone.memalign = &mz_memalign;<br />

tcmalloc_zone.free_definite_size = &mz_free_definite_size;<br />

tcmalloc_introspection.zone_locked = &mi_zone_locked;<br />

<br />

and on 10.6-PPC you just get this:<br />

<br />

tcmalloc_zone.version = 6;<br />

tcmalloc_zone.memalign = &mz_memalign;<br />

<br />

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.<br />

<br />

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.<br />

<br />

And there are HUNDREDS of these all throughout the codebase that need to be all stripped out.<br />

<br />

This is unfortunately a huge mess now.<br />

<br />

K<br />

<br />

<br />

<br />

<br />

https://github.com/macports/macports-ports/commit/418232ebb3d0e68579364c6246de4464f8f494c9<br />

<br />

======<br />

--- src/libc_override_osx.h.orig 2021-12-13 14:28:06.000000000 +0800<br />

+++ src/libc_override_osx.h 2023-01-19 20:14:36.000000000 +0800<br />

@@ -276,9 +276,11 @@<br />

MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_6<br />

// Switch to version 6 on OSX 10.6 to support memalign.<br />

tcmalloc_zone.version = 6;<br />

- tcmalloc_zone.free_definite_size = &mz_free_definite_size;<br />

tcmalloc_zone.memalign = &mz_memalign;<br />

+#ifndef __POWERPC__<br />

+ tcmalloc_zone.free_definite_size = &mz_free_definite_size;<br />

tcmalloc_introspection.zone_locked = &mi_zone_locked;<br />

+#endif<br />

<br />

// Request the default purgable zone to force its creation. The<br />

// current default zone is registered with the purgable zone for<br />

=========<br />

<br />

<br />

<br />

<blockquote type="cite">On Jan 8, 2024, at 9:50 AM, Sergey Fedorov <vital.had@gmail.com> wrote:<br />

<br />

Here we go again.<br />

<br />

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.<br />

<br />

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”.<br />

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.<br />

<br />

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.<br />

However, as I said above, nobody demanded 10A190 being supported in the master. Nobody commits 10A190-specific fixups.<br />

<br />

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”.<br />

<br />

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.<br />

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.<br />

<br />

It will be great not to keep repeating false statements targeting those who are unaware of the facts.<br />

<br /></blockquote>

<br /></blockquote>

</div>

</body>

</html>