Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.

barracuda156

macrumors 65816
Original poster
Sep 3, 2021
1,456
1,106

barracuda156

macrumors 65816
Original poster
Sep 3, 2021
1,456
1,106
Custom ports for 10A190 here: https://github.com/barracuda156/macports-ports/tree/snow-ppc (fixes that will not be or unlikely to be accepted with upstream).

This is intended to be a complete replacement for the earlier archive. But not yet :)
I will verify what needs custom fixes still and update the branch.

DO NOT USE THIS BRANCH FOR ANY OTHER PPC SYSTEMS, including 10.6.x Rosetta.

P. S. As usual, if something fails for you on 10A190 – report here (not on Trac).
 
Custom ports for 10A190 here: https://github.com/barracuda156/macports-ports/tree/snow-ppc (fixes that will not be or unlikely to be accepted with upstream).

This is intended to be a complete replacement for the earlier archive. But not yet :)
I will verify what needs custom fixes still and update the branch.

DO NOT USE THIS BRANCH FOR ANY OTHER PPC SYSTEMS, including 10.6.x Rosetta.

P. S. As usual, if something fails for you on 10A190 – report here (not on Trac).

Wait.

Are you telling me you got gqrx to build successfully on 10.6PPC?!
 
  • Like
Reactions: TheShortTimer

barracuda156

macrumors 65816
Original poster
Sep 3, 2021
1,456
1,106
Wait.

Are you telling me you got gqrx to build successfully on 10.6PPC?!

Do you mean this? https://ports.macports.org/port/gqrx/details/

Given it has dependency on Qt5, not even planning to :) If it can be built with Qt4, then chances are there. This appears to be the only problematic dependency (but a big deal of, AFAIK).

P. S. The branch has all ports, you gotta look at commits in history which have 10.6 PPC. There are – and hopefully will be – very few ports which gonna require dedicated fixes for 10A190. So far, GCC and Openssl (the latter because of outdated Perl in 10A190 – and fix is trivial).

Specifically, now there are 4 commits: gcc10-bootstrap, gcc12 (+ libgcc12), openssl11 and openssl3. I just need to confirm ld64 and cctools are good as-is, and likely we are good. Most of fixes for PPC overlap with standard systems, so I can submit PR into Macports directly.

Remember, sandbox fix by @kencu (trivial change) and setting of macports.conf to libstdc++ are and will be required (at least for the time-being). Rather annoying symlinking upon port sync can be dropped once a move to gcc12 is implemented in Macports (and on 10.6 even if you do it locally – since gcc12 is default compiler and runtime for 10.6.x Intel anyway).
TBH Rosetta and ppc64 are more broken at the moment in Macports than 10.6 PPC.
 

barracuda156

macrumors 65816
Original poster
Sep 3, 2021
1,456
1,106
Quick on the current state of things:

1. Mostly everything gonna work without previous trickery.
2. You still have to make sandbox fix for Macports on 10A190 (until someone bothers to fix sandbox in 10A190).
3. Also this is required in macports.conf: cxx_stdlib libstdc++ and buildfromsource always.

Very few ports now require 10A190-specific fixes. Mostly it is GCC versions (unwinding symbols are in `libgcc_s.1`, unlike on 10.6.8, where they are in `libSystem.b`). Few other cases are rather trivial – often you can look into portfile and make the port behave as if it is 10.5. Say, openssl11 / openssl3, which require perl5 5.10 (available on stock 10.6.8, but not on 10A190). I will try to keep my GitHub tree updated.

If you move to default libgcc12 (which is Macports default for 10.6+), you won’t need relinking _resources anymore. At this stage I can say Macports works comfortably on 10A190. Only initial setup has to be done and GCC sorted out.

(Again, notice, nothing of this applies to 10A96. I have no idea how hard is it to fix anything there. I also recommend staying with Xcode from 10A190 and do not update it to 10A222. Benefits are not obvious, while some, though infrequent drawbacks are likely.)
 
  • Like
Reactions: dextructor

barracuda156

macrumors 65816
Original poster
Sep 3, 2021
1,456
1,106
I asked this elsewhere but will repeat the question: if anyone knows of a way to differentiate between release 10.6.0+ with Rosetta and 10.6 PPC (pre-release, ppc native) via macros – that is, for the compiler – let me know.
This issue prevents implementing a generally acceptable fix for GCC – since any released 10.6 does not need changes we need for 10A190.

(A better way would be to fix 10A190 to match 10.6.0, of course…)
 

joevt

Contributor
Jun 21, 2012
6,620
4,060
I asked this elsewhere but will repeat the question: if anyone knows of a way to differentiate between release 10.6.0+ with Rosetta and 10.6 PPC (pre-release, ppc native) via macros – that is, for the compiler – let me know.
This issue prevents implementing a generally acceptable fix for GCC – since any released 10.6 does not need changes we need for 10A190.

(A better way would be to fix 10A190 to match 10.6.0, of course…)
Rosetta is not a thing you can know at compile time. Rosetta is always ppc. Real ppc can be ppc or ppc64.

If you mean you are using two different SDKs and want to know when you're compiling with one SDK or the other SDK, then diff them and find something that is different between them that you can test for.
I found that 10.4u SDK defines AVAILABLE_MAC_OS_X_VERSION_10_5_AND_LATER so you can't use that alone to determine if the SDK is for 10.5 so I included TARGET_OS_EMBEDDED in my 10.5 check.
https://github.com/joevt/pciutils/blob/master/lib/MacOSMacros.h

If you are not using an SDK, and are using headers and includes from root directory, you still need to do the same thing except only compare headers and includes (from the directories that would exist in an SDK).

You can download most of the SDKs from https://github.com/phracker/MacOSX-SDKs or extract them from Xcode installs.

Maybe you want to test something in the compiler such as a version number? Maybe do strings on the compilers and see if they have different version numbers that you can test for.

If there's no compile time macro, maybe do some tests at build time. The build script can set some environment variable which you can use in the build commands.
 
  • Like
Reactions: Amethyst1

barracuda156

macrumors 65816
Original poster
Sep 3, 2021
1,456
1,106
Rosetta is not a thing you can know at compile time. Rosetta is always ppc. Real ppc can be ppc or ppc64.

If you mean you are using two different SDKs and want to know when you're compiling with one SDK or the other SDK, then diff them and find something that is different between them that you can test for.
I found that 10.4u SDK defines AVAILABLE_MAC_OS_X_VERSION_10_5_AND_LATER so you can't use that alone to determine if the SDK is for 10.5 so I included TARGET_OS_EMBEDDED in my 10.5 check.
https://github.com/joevt/pciutils/blob/master/lib/MacOSMacros.h

If you are not using an SDK, and are using headers and includes from root directory, you still need to do the same thing except only compare headers and includes (from the directories that would exist in an SDK).

You can download most of the SDKs from https://github.com/phracker/MacOSX-SDKs or extract them from Xcode installs.

Maybe you want to test something in the compiler such as a version number? Maybe do strings on the compilers and see if they have different version numbers that you can test for.

If there's no compile time macro, maybe do some tests at build time. The build script can set some environment variable which you can use in the build commands.

Perhaps I did not ask the question in a clear enough way.

Here is what GCC uses in darwin.h and what has to be changed for 10A190 (this is a general header, another is inside gcc/RS6000/config, but these fixes are not arch-specific):
Like this, it cannot be accepted into either GCC upstream or Macports, because these setting are only for pre-release 10.6 and should not be applied on 10.6.0 and later.
We need a finer grading than os.major and os.minor, because minor is the same for anything up to 10.6.0 release.

Kernel seems to have needed definitions, but it is not clear if those can be used and if yes then how.
They sit here: https://opensource.apple.com/source/xnu/xnu-2050.18.24/libkern/libkern/version.h.template.auto.html

Compiler macros __MAC_OS_X_VERSION_MIN_REQUIRED and __MAC_OS_X_VERSION_MAX_ALLOWED are useless here, as well as __POWERPC__ – even if we assume that only pre-release PPC version of 10.6 is relevant (discarding Intel case), 1060 && __POWERPC__ fits 10.6 release with Rosetta, so it cannot be used either.
 

joevt

Contributor
Jun 21, 2012
6,620
4,060
Perhaps I did not ask the question in a clear enough way.

Here is what GCC uses in darwin.h and what has to be changed for 10A190 (this is a general header, another is inside gcc/RS6000/config, but these fixes are not arch-specific):
Like this, it cannot be accepted into either GCC upstream or Macports, because these setting are only for pre-release 10.6 and should not be applied on 10.6.0 and later.
We need a finer grading than os.major and os.minor, because minor is the same for anything up to 10.6.0 release.

Kernel seems to have needed definitions, but it is not clear if those can be used and if yes then how.
They sit here: https://opensource.apple.com/source/xnu/xnu-2050.18.24/libkern/libkern/version.h.template.auto.html

Compiler macros __MAC_OS_X_VERSION_MIN_REQUIRED and __MAC_OS_X_VERSION_MAX_ALLOWED are useless here, as well as __POWERPC__ – even if we assume that only pre-release PPC version of 10.6 is relevant (discarding Intel case), 1060 && __POWERPC__ fits 10.6 release with Rosetta, so it cannot be used either.
You want to change the behaviour of gcc rather than change what gets compiled?

Isn't mmacosx-version-min just a flag you pass into gcc? So make a new flag? Or change the definition of mmacosx-version-min so that it's more useful?
Can version-compare compare versions of any length? 10.6 < 10.6.0.123 < 10.6.1? Can it compare alpha and beta version? 10.6a < 10.6b < 10.6?
 

barracuda156

macrumors 65816
Original poster
Sep 3, 2021
1,456
1,106
You want to change the behaviour of gcc rather than change what gets compiled?

Isn't mmacosx-version-min just a flag you pass into gcc? So make a new flag? Or change the definition of mmacosx-version-min so that it's more useful?
Can version-compare compare versions of any length? 10.6 < 10.6.0.123 < 10.6.1? Can it compare alpha and beta version? 10.6a < 10.6b < 10.6?

1. GCC compiles itself, so both.
2. As things stand now, no unmodified version of GCC will build on unmodified 10A190.
3. Solution: either fix 10A190 (superior but far more complex) or modify GCC to accommodate 10A190 case.
4. Problem: modifications needed are conditional on the OS version and optionally arch. No combination of these allows to target exclusively 10A190 (= 10.6 ppc).
 

barracuda156

macrumors 65816
Original poster
Sep 3, 2021
1,456
1,106
If anyone experiences failures with eigen3, install eigen3-devel instead. There was some issue with backporting PPC fix, as it turned out. eigen3-devel works fine. (No special patches for 10A190 needed.)
 

ajzimmerman

macrumors newbie
Apr 6, 2012
10
3
In one of the first posts, @barracuda156 you said that m4 compiled for you but I'm unable to get it done. This is on a G4. I am just getting started with this stuff.. I had little luck on FreeBSD building and now I'm seeing that OSX is in a similar situation with a gui.

:debug:configure Error code: POSIX ENAMETOOLONG {file name too long}
:debug:configure Backtrace: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_
devel_m4/m4/work/m4-1.4.19/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-1
4B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/
confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdi
r-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B-
--/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/con
fdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-1
4B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---: file name too long
 
  • Like
Reactions: barracuda156
In one of the first posts, @barracuda156 you said that m4 compiled for you but I'm unable to get it done. This is on a G4. I am just getting started with this stuff.. I had little luck on FreeBSD building and now I'm seeing that OSX is in a similar situation with a gui.

:debug:configure Error code: POSIX ENAMETOOLONG {file name too long}
:debug:configure Backtrace: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_
devel_m4/m4/work/m4-1.4.19/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-1
4B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/
confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdi
r-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B-
--/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/con
fdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-1
4B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---: file name too long

Oh heck, I remember that, but I cannot recall how and why that comes up, or how to redress it.
 

barracuda156

macrumors 65816
Original poster
Sep 3, 2021
1,456
1,106
In one of the first posts, @barracuda156 you said that m4 compiled for you but I'm unable to get it done. This is on a G4. I am just getting started with this stuff.. I had little luck on FreeBSD building and now I'm seeing that OSX is in a similar situation with a gui.

:debug:configure Error code: POSIX ENAMETOOLONG {file name too long}
:debug:configure Backtrace: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_
devel_m4/m4/work/m4-1.4.19/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-1
4B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/
confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdi
r-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B-
--/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/con
fdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-1
4B---/confdir-14B---/confdir-14B---/confdir-14B---/confdir-14B---: file name too long

We have seen this error!
Try this: https://trac.macports.org/ticket/62994

Notice, the issue is not specific to 10.6 PPC:
 
  • Like
Reactions: ajzimmerman

ajzimmerman

macrumors newbie
Apr 6, 2012
10
3
"Tiger is really the sweet spot for the old G4 machines."
I hope not. Lol...


"I expect that one option is to use GNU coreutils 'rm' instead of MacPorts 'rm'. Coreutils 'rm' should not have the bug you're observing."

Code:
/* Leaving behind such a deep directory is not polite.
     So clean up here, right away, even though the driving
     shell script would also clean up.  */


To quote the solution above...
Code:
$ diff -u configure.old configure
--- configure.old    2021-06-05 17:36:56.000000000 -0700
+++ configure    2021-06-05 18:48:13.000000000 -0700
@@ -36350,7 +36350,7 @@
 #else
   int bug_possible = 0;
 #endif
-  if (! bug_possible)
+  if (1)
     return 0;
 
   cwd = getcwd (NULL, 0);


I drilled down and extracted the source,
"fixed" the file and create a diff. Put that diff in, /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/devel/m4/files/
Re-ran port install m4, and of course it is still not working.

---
Place the patch destdir-variable-fix.diff in the directory ${portpath}/files and use it in a port using the patchfiles keyword. ${portpath} may be in a local Portfile repository during development, or files/ may be in a port's ${portpath} in the global MacPorts repository.

I like how vague this is. Place the file in that dir, ok. Did that. Now use it in a port using the patch files keyword.

Um what. Use it in a port? What? port patch files "unrecognized action." Be clearer Macports. ${portpath} ???
Use this while running port install?
may be in a local Portfile repository during development,
I'm not developing.

or files/ may be in a port's ${portpath} in the global MacPorts repository.

More stuff that makes no sense to me.

I understand patching a config file, running that, make, make install.
I understand, kind of, putting a diff file in there.

But what I don't understand (because it's not even documented apparently), is how I'm supposed to be using this diff file with macports. Btw I ended up trying to put my diff file into every single possible source dir and running their patch command and it doesn't work.
 
Last edited:
  • Like
Reactions: pc297

pc297

macrumors 6502
Sep 26, 2015
325
204
I hope not. Lol...




Code:
/* Leaving behind such a deep directory is not polite.
     So clean up here, right away, even though the driving
     shell script would also clean up.  */


To quote the solution above...
Code:
$ diff -u configure.old configure
--- configure.old    2021-06-05 17:36:56.000000000 -0700
+++ configure    2021-06-05 18:48:13.000000000 -0700
@@ -36350,7 +36350,7 @@
 #else
   int bug_possible = 0;
 #endif
-  if (! bug_possible)
+  if (1)
     return 0;
 
   cwd = getcwd (NULL, 0);


I drilled down and extracted the source,
"fixed" the file and create a diff. Put that diff in, /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/devel/m4/files/
Re-ran port install m4, and of course it is still not working.

---


I like how vague this is. Place the file in that dir, ok. Did that. Now use it in a port using the patch files keyword.

Um what. Use it in a port? What? port patch files "unrecognized action." Be clearer Macports. ${portpath} ???
Use this while running port install?

I'm not developing.



More stuff that makes no sense to me.

I understand patching a config file, running that, make, make install.
I understand, kind of, putting a diff file in there.

But what I don't understand (because it's not even documented apparently), is how I'm supposed to be using this diff file with macports. Btw I ended up trying to put my diff file into every single possible source dir and running their patch command and it doesn't work.
You need to delete the offending directory after applying the patch. That did it for me.
 

barracuda156

macrumors 65816
Original poster
Sep 3, 2021
1,456
1,106
But what I don't understand (because it's not even documented apparently), is how I'm supposed to be using this diff file with macports. Btw I ended up trying to put my diff file into every single possible source dir and running their patch command and it doesn't work.

You put desired patch in portname/files, like: portname/files/myfix.diff
And add the following into the portfile:

patchfiles-append myfix.diff

This should work.

(If you generate a patch via git format-patch, use --no-prefix with it, or otherwise patch.pre_args -p1 should be used in a portfile.)
 

barracuda156

macrumors 65816
Original poster
Sep 3, 2021
1,456
1,106
  • Love
Reactions: G4fanboy

barracuda156

macrumors 65816
Original poster
Sep 3, 2021
1,456
1,106
Before I forgot: I strongly advise switching to legacy-support-devel for now (I you haven’t already). The PR with the fix has been finally merged a few days back into it.
This will require to rebuild some ports (git, for example), but it will save from more trouble later.

P. S. Assuming non-devel version is installed, do this:
Code:
sudo port deactivate legacy-support
sudo port install legacy-support-devel
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.