@barracuda156 how did you learn to do these fixes? They don't look so easy to do
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Building with Macports for 10.6 PowerPC (10A190 and 10.6.8 Rosetta)
- Thread starter barracuda156
- WikiPost WikiPost
- Start date
- Sort by reaction score
- Status
gcc10-bootstrap fixed for Rosetta: https://github.com/macports/macports-ports/pull/15801
Should build with:
sudo port -v -s build gcc10-bootstrap -universal build_arch=ppc universal_archs= cxx_stdlib=libstdc++
Should build with:
sudo port -v -s build gcc10-bootstrap -universal build_arch=ppc universal_archs= cxx_stdlib=libstdc++
Presumably I have fixed a bunch of Facebook libraries – confirmed to build on Rosetta for ppc, should build on 10.6 PPC, may build on Leopard.
folly: https://github.com/macports/macports-ports/pull/15689/files
fizz: https://github.com/macports/macports-ports/pull/15718/files
wangle: https://github.com/macports/macports-ports/pull/15724/files
fbthrift: https://github.com/macports/macports-ports/pull/15736/files
folly: https://github.com/macports/macports-ports/pull/15689/files
fizz: https://github.com/macports/macports-ports/pull/15718/files
wangle: https://github.com/macports/macports-ports/pull/15724/files
fbthrift: https://github.com/macports/macports-ports/pull/15736/files
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).
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?!
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.
For those lazy to patch sandbox file manually, pre-patched version of Macports: https://github.com/barracuda156/macports-base-10A190/tree/macports-slppc
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.)
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.)
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…)
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.
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):
darwin.h: fixes for 10A190 · iains/gcc-git@603494b
GCC Git mirror + Darwin Updates. Contribute to iains/gcc-git development by creating an account on GitHub.
github.com
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?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.
darwin.h: fixes for 10A190 · iains/gcc-git@603494b
GCC Git mirror + Darwin Updates. Contribute to iains/gcc-git development by creating an account on GitHub.
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.
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).
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.)
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
: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.
We have seen this error!
Try this: https://trac.macports.org/ticket/62994
Notice, the issue is not specific to 10.6 PPC:
#63059 (m4 failed to "filename too long") – MacPorts
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.
Last edited:
You need to delete the offending directory after applying the patch. That did it for me.
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.)
P. S. Let me see what is going on with m4 on 10.6.
UPD. The fix is already there, it was just added in a way to leave 10.6 broken ¯\_(ツ)_/¯
Just change 10 to 11 in line 37, that is all: https://github.com/macports/macports-ports/commit/ac9d831b1772b427eb7f7f4d781a3b602e4b99cd
UPD. The fix is already there, it was just added in a way to leave 10.6 broken ¯\_(ツ)_/¯
Just change 10 to 11 in line 37, that is all: https://github.com/macports/macports-ports/commit/ac9d831b1772b427eb7f7f4d781a3b602e4b99cd
Last edited:
I have made an updated 10.6 PPC branch (Snow-PowerPC) the main one: https://github.com/barracuda156/macports-ports (does not have some fixes for old gccs yet, since I want to modify those a bit; to be updated).
Rosetta fixes which are incompatible or redundant for 10.6 native will be here: https://github.com/barracuda156/macports-ports/tree/Rosetta (do not use these anywhere besides Rosetta).
Rosetta fixes which are incompatible or redundant for 10.6 native will be here: https://github.com/barracuda156/macports-ports/tree/Rosetta (do not use these anywhere besides Rosetta).
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:
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-develONLY for 10.6.8 ROSETTA
Something is broken in MacPorts 2.9.x for Rosetta: https://trac.macports.org/ticket/69301
Use 2.8.1, it works perfectly.
P. S. On any native PowerPC system, including 10.6 (10a190), 2.9.1 works for me.
Something is broken in MacPorts 2.9.x for Rosetta: https://trac.macports.org/ticket/69301
Use 2.8.1, it works perfectly.
P. S. On any native PowerPC system, including 10.6 (10a190), 2.9.1 works for me.