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 <vital....@gmail.com> 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: 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 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 PASS: 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 ./test-driver: line 112: 38625 Abort trap "$@" >> > "$log_file" 2>&1 > > :info:test FAIL: tcmalloc_minimal_debug_unittest > > :info:test ./test-driver: line 112: 38645 Abort trap "$@" >> > "$log_file" 2>&1 > > :info:test FAIL: malloc_extension_debug_test > > :info:test ./test-driver: line 112: 38664 Abort trap "$@" >> > "$log_file" 2>&1 > > :info:test FAIL: 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 PASS: 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 PASS: 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 PASS: heap-profiler_unittest.sh > > :info:test PASS: simple_compat_test > > :info:test ./test-driver: line 112: 39897 Abort trap "$@" >> > "$log_file" 2>&1 > > :info:test FAIL: 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 PASS: 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 PASS: heap-profiler_debug_unittest.sh > > So it seems to perform somewhat worse on PPC, no real surprise here, but > it does not perform perfectly on Intel either, with my patch removed. > I do not see anything broken by my patch so far. > > Since I have been in touch with upstream, I will bring the problem to > their attention. > > On Tue, Jan 9, 2024 at 12:31 PM 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. >> > >> >>
