Ah, yes -- I did try that patchset back there in 2017. Thanks for the reminder! I will look over the additions you made.
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.
Resolved Darwin10/Snow Leopard on PowerPC (ppc7450/G4) — how to get irssi working… via ports, from source, or mix of both [solved]
- Thread starter B S Magnet
- Start date
-
- Tags
- architectures compiling gcc powerpc
- Sort by reaction score
https://github.com/ioquake/ioq3/pull/508 I used Panther_SDL2 to bring back both Tiger and 10.3.9 support to IOQuake3 as well: https://alex-free.github.io/ioq3-panther/
Circling back around, this build attempt didn’t go far with the newer ld moved into place:
mkdir objdir
cd objdir
set +v
checking build system type... powerpc-apple-darwin10.0.0d1
checking host system type... powerpc-apple-darwin10.0.0d1
checking target system type... powerpc-apple-darwin10.0.0d1
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... /usr/bin/sed
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking for libatomic support... yes
checking for libcilkrts support... no
checking for libitm support... yes
checking for libsanitizer support... no
checking for libvtv support... no
checking for libmpx support... no
checking for libhsail-rt support... no
checking for gcc... gcc
checking for C compiler default output file name...
configure: error: in `/opt/gcc_kencu/gcc-7.5.0/objdir':
configure: error: C compiler cannot create executables
See `config.log' for more details.
sh-4.3#So I looked at the config.log in objdir and found this error, which resembles the errors I see when trying to install new ports on here:
configure:4314: $? = 0
configure:4303: gcc -v >&5
Using built-in specs.
Target: powerpc-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5610~2/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/usr/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-gxx-include-dir=/usr/include/c++/4.2.1 --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix= --host=powerpc-apple-darwin10 --target=powerpc-apple-darwin10
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5610)
configure:4314: $? = 0
configure:4303: gcc -V >&5
gcc-4.2: argument to `-V' is missing
configure:4314: $? = 1
configure:4303: gcc -qversion >&5
powerpc-apple-darwin10-gcc-4.2.1: no input files
configure:4314: $? = 1
configure:4334: checking for C compiler default output file name
configure:4356: gcc conftest.c >&5
collect2: error trying to exec '/usr/libexec/gcc/powerpc-apple-darwin10/4.2.1/ld': execvp: Bad CPU type in executable
collect2: ld returned 255 exit status
configure:4360: $? = 1
configure:4397: result:
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:4403: error: in `/opt/gcc_kencu/gcc-7.5.0/objdir':
configure:4407: error: C compiler cannot create executables
See `config.log' for more details.
I would try uninstalling Xcode 3.2 and installing Xcode 3.1.4, then restarting the entire build.
If I can install 3.1.4 non-destructively on this test box (even if that amounts to renaming /Developer to /Developer_3.2), I may try to do it (even if I have to use Pacifist), but I should note that others on the big SL-PPC thread found only this specific version of Xcode 3.2 which came bundled with 10A96 actually installs properly in the 10A96 or 10A190 environments. So I’m not sure I’ll have installation success using the standard Installer.
I would leave everything as you had it at first, but before the build of gcc actually starts, edit
gcc/config/darwin.h
and remove Jack's addition (make it the way it was before).
ie, undo this:
--- gcc/config/darwin.h (revision 151908)
+++ gcc/config/darwin.h (working copy)
@@ -372,7 +372,9 @@
/* Machine dependent libraries. */
-#define LIB_SPEC "%{!static:-lSystem}"
+#define LIB_SPEC "%{!static:\
+ %:version-compare(>= 10.6 mmacosx-version-min= -no_compact_unwind) \
+ -lSystem}"
/* Support -mmacosx-version-min by supplying different (stub) libgcc_s.dylib
libraries to link against, and by not linking against libgcc_s on
gcc/config/darwin.h
and remove Jack's addition (make it the way it was before).
ie, undo this:
--- gcc/config/darwin.h (revision 151908)
+++ gcc/config/darwin.h (working copy)
@@ -372,7 +372,9 @@
/* Machine dependent libraries. */
-#define LIB_SPEC "%{!static:-lSystem}"
+#define LIB_SPEC "%{!static:\
+ %:version-compare(>= 10.6 mmacosx-version-min= -no_compact_unwind) \
+ -lSystem}"
/* Support -mmacosx-version-min by supplying different (stub) libgcc_s.dylib
libraries to link against, and by not linking against libgcc_s on
For your "bad CPU type in executable" error, use "lipo" to examine your executable and see what the heck CPU type it is. You want ppc7400 -- but what it is actually making is a question still.
Correction: it is this file that the system can't run:
/usr/libexec/gcc/powerpc-apple-darwin10/4.2.1/ld
what is that -- if it is a symlink, what is it pointing too? And what arch is the final file?
Last edited:
Yes. It was a new symlink to a more recent version of ld I mentioned a few posts back. I was optimistic this newer version of ld would be the thing which overcame the issue of my default ld being unable to deal with that flag from earlier.
So the newer ld I just built this week when I compiled binutils is i386 and not universal, like the ld set aside from the system default (shown here as /usr/bin/ld.10A96):
sh-4.3# lipo -detailed_info /usr/bin/ld
input file /usr/bin/ld is not a fat file
Non-fat file: /usr/bin/ld is architecture: i386
sh-4.3# lipo -detailed_info /usr/bin/ld.10A96
Fat header in: /usr/bin/ld.10A96
fat_magic 0xcafebabe
nfat_arch 2
architecture i386
cputype CPU_TYPE_I386
cpusubtype CPU_SUBTYPE_I386_ALL
offset 4096
size 1270080
align 2^12 (4096)
architecture ppc7400
cputype CPU_TYPE_POWERPC
cpusubtype CPU_SUBTYPE_POWERPC_7400
offset 1277952
size 1299164
align 2^12 (4096)
sh-4.3#I’m reverting the ld symlink and restoring the system default version of ld.
building a new ld64 and cctools will certainly be needed. Have to figure out how to get them into the proper arch, though. If building with MacPorts, some editing of Portfiles will be needed, as on darwin10 MacPorts will be forcing Intel archs only in places.
In the Portfiles, such a force looks like this
supported_archs i386 x86_64
and you'd have to either delete that line or add "ppc" to it. Then, there could be other issues that arise.
In the Portfiles, such a force looks like this
supported_archs i386 x86_64
and you'd have to either delete that line or add "ppc" to it. Then, there could be other issues that arise.
It still looks pretty tempting for bootstrapping to go to Leopard PPC, install MacPorts into a custom prefix like /opt/toolchains, install gcc7 into that, and then package it all up with one command (sudo port pkg gcc7), copy that package onto the 10.6 PPC machine, and run and install that package into /opt/toolchains.
The MacPorts configure command on Leopard would look something like this:
That gets you gcc7, cctools. and ld64, all built right and hopefully functional.
Once you have that working, you can use that to bootstrap things further perhaps.
The MacPorts configure command on Leopard would look something like this:
Code:
./configure --prefix=/opt/toolchains --without-startupitems --with-applications-dir=/Applications/MacPorts-ToolchainThat gets you gcc7, cctools. and ld64, all built right and hopefully functional.
Once you have that working, you can use that to bootstrap things further perhaps.
After a few days of trying different approaches to getting irssi installed on Darwin10/PPC, there appears to be two things I’ve learnt from this exercise.
The first is there probably is not a way to build irssi from macports in this Darwin10.0.0d1/d2-on-PowerPC environment, because most of the “darwin-10” ports are i386/x86_64 only. Some are “noarch” and will install on the PowerPC in Darwin10.0.0d1 or d2. And a handful, I’ve come to learn, will install despite being i386/x86_64 tarballs, but when invoked at a prompt, they will throw a mach-o bad CPU type error. Here’s a look at some of the few “i386” ports which installed successfully, but will not actually run:
In the above, all of the installed dependencies up through db48, llvm_select and cctools excepted, are for i386 — not “noarch” or “ppc”.
I concluded this after trying several different ways to fresh-build Macports2.7.1 in Darwin10/PPC — including methods like going through and editing key locations in all the configure files (where an “OS major” variable is specified) to “trick” the compiler to think this system was actually running Darwin9 on a PPC. (This didn’t work.) I also tried another approach to get the configure files to trick the compiler to think that “i386 ppc” as target architectures was valid for not only 10.4 and 10.5, but also for 10.6. (This didn’t work, either.) In every case, the fetching of ports from the MP servers grabbed “darwin_10” and not “darwin_9”. Which I guess makes sense.
[Note: there are a few “darwin_10.noarch” ports (links to google), but there are no “darwin_10.ppc” ports (also links to google). They don’t exist.]
Eventually, I gave up, capitulating instead to running a port mpkg irssi on a PowerPC running 10.5.8 to create an installer to install irssi that way on the Darwin10/PPC Mac.
This brought me to the second thing I learnt (and is beyond the scope of what I was trying to figure out with this thread):
irssi 1.2.3 (the current build, the one also provided by macports) seems to have issues on every PowerPC Mac I have (four, at present, three of which are running 1.2.3). When I installed from the mpkg onto the Darwin10/PPC test Mac, it installed fine and even opened fine, but it cannot connect to any server including the ngircd servers I have running on two of my PowerPC Macs (which were installed at different times). (I found that irssi 1.2.3, when opened from an Intel Mac — three, at present, two of which are running 1.2.3 — runs as it should, logging onto my test ngircd boxes without trouble.)
But when trying to run irssi 1.2.3 from the Darwin10/PPC, a Darwin9/PPC (on which I created the mpkg used for the Darwin 10/PPC Mac), and a Darwin8/PPC (a clamshell iBook, on which I installed irssi from a port install command), server connection fails to occur and shortly after, all keystrokes (or their echoes) stop displaying on screen, forcing a closing of that window. This behaviour is repeatable across all three Macs experiencing this, which seems to point at irssi or one of its dependencies being either incompatible or saddled with a bug that prevents functionality of 1.2.3 on PowerPC Macs).
Meanwhile, I have one PowerPC (Darwin 9/10.5.8) and one Intel (Darwin10/10.6.8) Mac, each running irssi 1.2.2 (both installed, separately, with macports probably last year), and both connected to my test ngircd servers without any issues.
The challenge I’m running into now — and something I can’t pinpoint in the Macports guide — is how to create an mpkg from the one PowerPC Mac still running irssi 1.2.2 or build irssi 1.2.2 with its now-dated dependencies without macports fetching from the server the latest versions and latest-versioned dependencies (as I suspect letting it do so will also break irssi on that one remaining PowerPC Mac by bumping it up to 1.2.3 with updated dependencies). I‘d really like to make an mpkg of irssi 1.2.2 with its dependencies on that one Darwin9 Mac, to install on the other PPC Macs, until issues with 1.2.3 are resolved.
I think the dependency in question could be ncurses, given one solitary crash logged by the Darwin10/PPC Macs which reported:
Unfortunately, I could not invoke more crashes with logs to repeat this error.
So if anything, this exercise has demonstrated itself to be more of a challenge than even I had anticipated. I suppose I should feel frustrated, but if anything, I feel sort of resigned.
[EDIT to add: I strongly encourage everyone who’s been participating in this thread to get Build 10A96 or Build 10A190 up and running on a spare PowerPC Mac in order to working from the same core set of circumstances described throughout this thread. Thanks!]
The first is there probably is not a way to build irssi from macports in this Darwin10.0.0d1/d2-on-PowerPC environment, because most of the “darwin-10” ports are i386/x86_64 only. Some are “noarch” and will install on the PowerPC in Darwin10.0.0d1 or d2. And a handful, I’ve come to learn, will install despite being i386/x86_64 tarballs, but when invoked at a prompt, they will throw a mach-o bad CPU type error. Here’s a look at some of the few “i386” ports which installed successfully, but will not actually run:
sh-4.3# port install neofetch
---> Fetching archive for neofetch
---> Attempting to fetch neofetch-7.1.0_0.darwin_10.noarch.tbz2 from http://packages.macports.org/neofetch
---> Attempting to fetch neofetch-7.1.0_0.darwin_10.noarch.tbz2.rmd160 from http://packages.macports.org/neofetch
---> Installing neofetch @7.1.0_0
---> Activating neofetch @7.1.0_0
---> Cleaning neofetch
sh-4.3# port install irssi
---> Computing dependencies for irssi
The following dependencies will be installed:
bzip2
cctools
clang-9.0
clang_select
db48
expat
gdbm
gettext
glib2
icu
ld64
ld64-127
libcxx
libedit
libffi
libiconv
libomp
libxml2
llvm-3.4
llvm-9.0
llvm_select
ncurses
ncurses-bootstrap
openssl
pcre
perl5
perl5.28
pkgconfig
python27
python2_select
python39
python3_select
python_select
readline
sqlite3
xar
xz
zlib
Continue? [Y/n]: y
---> Fetching archive for libffi
---> Attempting to fetch libffi-3.3_1.darwin_10.i386.tbz2 from http://packages.macports.org/libffi
---> Attempting to fetch libffi-3.3_1.darwin_10.i386.tbz2.rmd160 from http://packages.macports.org/libffi
---> Installing libffi @3.3_1
---> Activating libffi @3.3_1
---> Cleaning libffi
---> Fetching archive for llvm_select
---> Attempting to fetch llvm_select-2_0.darwin_10.noarch.tbz2 from http://packages.macports.org/llvm_select
---> Attempting to fetch llvm_select-2_0.darwin_10.noarch.tbz2.rmd160 from http://packages.macports.org/llvm_select
---> Installing llvm_select @2_0
---> Activating llvm_select @2_0
---> Cleaning llvm_select
---> Fetching archive for ncurses-bootstrap
---> Attempting to fetch ncurses-bootstrap-6.2_1.darwin_10.i386.tbz2 from http://packages.macports.org/ncurses-bootstrap
---> Attempting to fetch ncurses-bootstrap-6.2_1.darwin_10.i386.tbz2.rmd160 from http://packages.macports.org/ncurses-bootstrap
---> Installing ncurses-bootstrap @6.2_1
---> Activating ncurses-bootstrap @6.2_1
---> Cleaning ncurses-bootstrap
---> Fetching archive for zlib
---> Attempting to fetch zlib-1.2.11_0.darwin_10.i386.tbz2 from http://packages.macports.org/zlib
---> Attempting to fetch zlib-1.2.11_0.darwin_10.i386.tbz2.rmd160 from http://packages.macports.org/zlib
---> Installing zlib @1.2.11_0
---> Activating zlib @1.2.11_0
---> Cleaning zlib
---> Fetching archive for llvm-3.4
---> Attempting to fetch llvm-3.4-3.4.2_14.darwin_10.i386.tbz2 from http://packages.macports.org/llvm-3.4
---> Attempting to fetch llvm-3.4-3.4.2_14.darwin_10.i386.tbz2.rmd160 from http://packages.macports.org/llvm-3.4
---> Installing llvm-3.4 @3.4.2_14
---> Activating llvm-3.4 @3.4.2_14
---> Cleaning llvm-3.4
---> Fetching archive for cctools
---> Attempting to fetch cctools-949.0.1_1+llvm34.darwin_10.i386.tbz2 from http://packages.macports.org/cctools
---> Attempting to fetch cctools-949.0.1_1+llvm34.darwin_10.i386.tbz2.rmd160 from http://packages.macports.org/cctools
---> Installing cctools @949.0.1_1+llvm34
---> Activating cctools @949.0.1_1+llvm34
---> Cleaning cctools
---> Fetching archive for clang_select
---> Attempting to fetch clang_select-2.2_0.darwin_10.noarch.tbz2 from http://packages.macports.org/clang_select
---> Attempting to fetch clang_select-2.2_0.darwin_10.noarch.tbz2.rmd160 from http://packages.macports.org/clang_select
---> Installing clang_select @2.2_0
---> Activating clang_select @2.2_0
---> Cleaning clang_select
---> Fetching archive for ld64-127
---> Attempting to fetch ld64-127-127.2_14+llvm34.darwin_10.i386.tbz2 from http://packages.macports.org/ld64-127
---> Attempting to fetch ld64-127-127.2_14+llvm34.darwin_10.i386.tbz2.rmd160 from http://packages.macports.org/ld64-127
---> Installing ld64-127 @127.2_14+llvm34
---> Activating ld64-127 @127.2_14+llvm34
---> Cleaning ld64-127
---> Fetching archive for ld64
---> Attempting to fetch ld64-3_3+ld64_127.darwin_10.i386.tbz2 from http://packages.macports.org/ld64
---> Attempting to fetch ld64-3_3+ld64_127.darwin_10.i386.tbz2.rmd160 from http://packages.macports.org/ld64
---> Installing ld64 @3_3+ld64_127
---> Activating ld64 @3_3+ld64_127
---> Cleaning ld64
---> Fetching archive for libcxx
---> Attempting to fetch libcxx-5.0.1_4+universal.darwin_10.i386-x86_64.tbz2 from http://packages.macports.org/libcxx
---> Attempting to fetch libcxx-5.0.1_4+universal.darwin_10.i386-x86_64.tbz2.rmd160 from http://packages.macports.org/libcxx
---> Installing libcxx @5.0.1_4+universal
---> Activating libcxx @5.0.1_4+universal
---> Cleaning libcxx
---> Fetching archive for libomp
---> Attempting to fetch libomp-12.0.1_0+universal.darwin_10.i386-x86_64.tbz2 from http://packages.macports.org/libomp
---> Attempting to fetch libomp-12.0.1_0+universal.darwin_10.i386-x86_64.tbz2.rmd160 from http://packages.macports.org/libomp
---> Installing libomp @12.0.1_0+universal
---> Activating libomp @12.0.1_0+universal
---> Cleaning libomp
---> Fetching archive for icu
---> Attempting to fetch icu-67.1_4.darwin_10.i386.tbz2 from http://packages.macports.org/icu
---> Attempting to fetch icu-67.1_4.darwin_10.i386.tbz2.rmd160 from http://packages.macports.org/icu
---> Installing icu @67.1_4
---> Activating icu @67.1_4
---> Cleaning icu
---> Fetching archive for libiconv
---> Attempting to fetch libiconv-1.16_1.darwin_10.i386.tbz2 from http://packages.macports.org/libiconv
---> Attempting to fetch libiconv-1.16_1.darwin_10.i386.tbz2.rmd160 from http://packages.macports.org/libiconv
---> Installing libiconv @1.16_1
---> Activating libiconv @1.16_1
---> Cleaning libiconv
---> Fetching archive for ncurses
---> Attempting to fetch ncurses-6.2_1.darwin_10.i386.tbz2 from http://packages.macports.org/ncurses
---> Attempting to fetch ncurses-6.2_1.darwin_10.i386.tbz2.rmd160 from http://packages.macports.org/ncurses
---> Installing ncurses @6.2_1
---> Activating ncurses @6.2_1
---> Cleaning ncurses
---> Fetching archive for gettext
---> Attempting to fetch gettext-0.19.8.1_2.darwin_10.i386.tbz2 from http://packages.macports.org/gettext
---> Attempting to fetch gettext-0.19.8.1_2.darwin_10.i386.tbz2.rmd160 from http://packages.macports.org/gettext
---> Installing gettext @0.19.8.1_2
---> Activating gettext @0.19.8.1_2
---> Cleaning gettext
---> Fetching archive for xz
---> Attempting to fetch xz-5.2.5_0.darwin_10.i386.tbz2 from http://packages.macports.org/xz
---> Attempting to fetch xz-5.2.5_0.darwin_10.i386.tbz2.rmd160 from http://packages.macports.org/xz
---> Installing xz @5.2.5_0
---> Activating xz @5.2.5_0
---> Cleaning xz
---> Fetching archive for libxml2
---> Attempting to fetch libxml2-2.9.12_1.darwin_10.i386.tbz2 from http://packages.macports.org/libxml2
---> Attempting to fetch libxml2-2.9.12_1.darwin_10.i386.tbz2.rmd160 from http://packages.macports.org/libxml2
---> Installing libxml2 @2.9.12_1
---> Activating libxml2 @2.9.12_1
---> Cleaning libxml2
---> Fetching archive for libedit
---> Attempting to fetch libedit-20210216-3.1_0.darwin_10.i386.tbz2 from http://packages.macports.org/libedit
---> Attempting to fetch libedit-20210216-3.1_0.darwin_10.i386.tbz2.rmd160 from http://packages.macports.org/libedit
---> Installing libedit @20210216-3.1_0
---> Activating libedit @20210216-3.1_0
---> Cleaning libedit
---> Fetching archive for bzip2
---> Attempting to fetch bzip2-1.0.8_0.darwin_10.i386.tbz2 from http://packages.macports.org/bzip2
---> Attempting to fetch bzip2-1.0.8_0.darwin_10.i386.tbz2.rmd160 from http://packages.macports.org/bzip2
---> Installing bzip2 @1.0.8_0
---> Activating bzip2 @1.0.8_0
---> Cleaning bzip2
---> Fetching archive for db48
---> Attempting to fetch db48-4.8.30_4+java.darwin_10.i386.tbz2 from http://packages.macports.org/db48
---> Attempting to fetch db48-4.8.30_4+java.darwin_10.i386.tbz2.rmd160 from http://packages.macports.org/db48
---> Installing db48 @4.8.30_4+java
tar (child): bzip2: Cannot exec: Bad CPU type in executable
tar (child): Error is not recoverable: exiting now
/usr/bin/tar: Child returned status 2
/usr/bin/tar: ./+CONTENTS: Not found in archive
/usr/bin/tar: Error exit delayed from previous errors
Error: Failed to install db48: child process exited abnormally
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_databases_db48/db48/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port irssi failed
---> Some of the ports you installed have notes:
libomp has the following notes:
To use this OpenMP library:
* For clang-3.8+, or clang-3.7 with +openmp variant:
add "-fopenmp" during compilation / linking.
* For clang-3.7 without +openmp variant, use:
"-I/opt/local/include/libomp -L/opt/local/lib/libomp -fopenmp"
sh-4.3#In the above, all of the installed dependencies up through db48, llvm_select and cctools excepted, are for i386 — not “noarch” or “ppc”.
I concluded this after trying several different ways to fresh-build Macports2.7.1 in Darwin10/PPC — including methods like going through and editing key locations in all the configure files (where an “OS major” variable is specified) to “trick” the compiler to think this system was actually running Darwin9 on a PPC. (This didn’t work.) I also tried another approach to get the configure files to trick the compiler to think that “i386 ppc” as target architectures was valid for not only 10.4 and 10.5, but also for 10.6. (This didn’t work, either.) In every case, the fetching of ports from the MP servers grabbed “darwin_10” and not “darwin_9”. Which I guess makes sense.
[Note: there are a few “darwin_10.noarch” ports (links to google), but there are no “darwin_10.ppc” ports (also links to google). They don’t exist.]
Eventually, I gave up, capitulating instead to running a port mpkg irssi on a PowerPC running 10.5.8 to create an installer to install irssi that way on the Darwin10/PPC Mac.
This brought me to the second thing I learnt (and is beyond the scope of what I was trying to figure out with this thread):
irssi 1.2.3 (the current build, the one also provided by macports) seems to have issues on every PowerPC Mac I have (four, at present, three of which are running 1.2.3). When I installed from the mpkg onto the Darwin10/PPC test Mac, it installed fine and even opened fine, but it cannot connect to any server including the ngircd servers I have running on two of my PowerPC Macs (which were installed at different times). (I found that irssi 1.2.3, when opened from an Intel Mac — three, at present, two of which are running 1.2.3 — runs as it should, logging onto my test ngircd boxes without trouble.)
But when trying to run irssi 1.2.3 from the Darwin10/PPC, a Darwin9/PPC (on which I created the mpkg used for the Darwin 10/PPC Mac), and a Darwin8/PPC (a clamshell iBook, on which I installed irssi from a port install command), server connection fails to occur and shortly after, all keystrokes (or their echoes) stop displaying on screen, forcing a closing of that window. This behaviour is repeatable across all three Macs experiencing this, which seems to point at irssi or one of its dependencies being either incompatible or saddled with a bug that prevents functionality of 1.2.3 on PowerPC Macs).
Meanwhile, I have one PowerPC (Darwin 9/10.5.8) and one Intel (Darwin10/10.6.8) Mac, each running irssi 1.2.2 (both installed, separately, with macports probably last year), and both connected to my test ngircd servers without any issues.
The challenge I’m running into now — and something I can’t pinpoint in the Macports guide — is how to create an mpkg from the one PowerPC Mac still running irssi 1.2.2 or build irssi 1.2.2 with its now-dated dependencies without macports fetching from the server the latest versions and latest-versioned dependencies (as I suspect letting it do so will also break irssi on that one remaining PowerPC Mac by bumping it up to 1.2.3 with updated dependencies). I‘d really like to make an mpkg of irssi 1.2.2 with its dependencies on that one Darwin9 Mac, to install on the other PPC Macs, until issues with 1.2.3 are resolved.
I think the dependency in question could be ncurses, given one solitary crash logged by the Darwin10/PPC Macs which reported:
Process: irssi [88227]
Path: /opt/local/bin/irssi
Identifier: irssi
Version: ??? (???)
Code Type: PPC (Native)
Parent Process: bash [88216]
Date/Time: 2021-08-18 08:09:22.101 -0400
OS Version: Mac OS X Server 10.6 (10A96)
Report Version: 6
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000001, 0x000000008fe01078
Crashed Thread: 0
Dyld Error Message:
Library not loaded: /opt/local/lib/libncurses.6.dylib
Referenced from: /opt/local/bin/irssi
Reason: no suitable image found. Did find:
/opt/local/lib/libncurses.6.dylib: mach-o, but wrong architectureUnfortunately, I could not invoke more crashes with logs to repeat this error.
So if anything, this exercise has demonstrated itself to be more of a challenge than even I had anticipated. I suppose I should feel frustrated, but if anything, I feel sort of resigned.
[EDIT to add: I strongly encourage everyone who’s been participating in this thread to get Build 10A96 or Build 10A190 up and running on a spare PowerPC Mac in order to working from the same core set of circumstances described throughout this thread. Thanks!]
Last edited:
I continue to suggest you disable archive_sites as I described above, because anything you download will be wrong except noarch files.
MacPorts is surprisingly easy to hack on. It is quite well-written, so a change like you need is going to be in only one or two places.
You want MacPorts to ignore any supported_archs set in the Portfiles, and to always return ppc as the arch to build in all cases. That logic is handled in a small block of quite-readable tcl code staring on line 409 in this file:
github.com
You have that file installed on your system now, in /opt/local/libexec/macports, if memory serves.
You would want to edit that function, possibly in only one spot, to returb ppc no matter what.
MacPorts is surprisingly easy to hack on. It is quite well-written, so a change like you need is going to be in only one or two places.
You want MacPorts to ignore any supported_archs set in the Portfiles, and to always return ppc as the arch to build in all cases. That logic is handled in a small block of quite-readable tcl code staring on line 409 in this file:
macports-base/src/port1.0/portconfigure.tcl at master · macports/macports-base
The MacPorts command-line client. Contribute to macports/macports-base development by creating an account on GitHub.
github.com
You have that file installed on your system now, in /opt/local/libexec/macports, if memory serves.
You would want to edit that function, possibly in only one spot, to returb ppc no matter what.
If you need an older package, you have to checkout an older ports tree from GitHub and then sync it. It’s insanely slow and IMO the worst thing about macports (I otherwise like it a lot). I wish I could just specify a pre compiled binary (which macports generates!) to install like every other package manager…
I did disable “archive_sites” in an earlier build/install of Macports — specifically, the version I built over the weekend.
What I am saying is this: not every port has a “darwin_10.ppc” or “darwin_10.noarch”. A very select few (like mpstats and neofetch) do have a variant of the latter, while the rest do not. Have a look yourself. For irssi (in this link), there are archives for i386 or arm64 — and for darwin_10 in particular, they’re i386- and x86_64-only. In fact, I am stating that no port designated as “Darwin_10.ppc” has likely ever existed. Keep reading.
Also, have you walked though any of this yourself specifically on a PowerPC Mac running 10.0.0d1 or 10.0.0d2? I get the impression that this feedback (which I do welcome) isn’t coming from the applied testing of that specific situation. Until it is, then this discussion isn’t going to be very helpful.
Excellent. But this isn’t terribly helpful. Keep reading.
Yes, I understand. And that same code appears within the config files which are generated after one has configured Macports, prior to running the make/make-install commands to build it. When that particular area of code is changed so that 10.6 looks for “ppc” archives only, every fetch for a port looking for the “darwin-10.ppc” version of the port archive is going to fail.
For example, and for sake of this discussion, I port-uninstalled both ncurses and libcxx (libc++). Next, I port-install’d libcxx with the “ppc” edit made previously to the “portconfigure.tcl” file. MP installs a “universal” libcxx aimed at the “universal” of i386 & x86_64:
sh-4.3# uname -a
Darwin glaciologia.private 10.0.0d1 Darwin Kernel Version 10.0.0d1: Tue Jun 3 23:38:02 PDT 2008; root:xnu-1292.3~1/RELEASE_PPC Power Macintosh
sh-4.3# port -v install libcxx
---> Fetching archive for libcxx
---> libcxx-5.0.1_4+universal.darwin_10.i386-x86_64.tbz2 doesn't seem to exist in /opt/local/var/macports/incoming/verified
---> Attempting to fetch libcxx-5.0.1_4+universal.darwin_10.i386-x86_64.tbz2 from http://packages.macports.org/libcxx
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
4 762k 4 32340 0 0 7873 0 0:01:39 0:00:04 0:01:35 207k
100 762k 100 762k 0 0 144k 0 0:00:05 0:00:05 --:--:-- 607k---> Attempting to fetch libcxx-5.0.1_4+universal.darwin_10.i386-x86_64.tbz2.rmd160 from http://packages.macports.org/libcxx
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 512 100 512 0 0 127 0 0:00:04 0:00:04 --:--:-- 127
100 512 100 512 0 0 100 0 0:00:05 0:00:05 --:--:-- 0---> Installing libcxx @5.0.1_4+universal
---> Activating libcxx @5.0.1_4+universal
./
./+COMMENT
./+CONTENTS
./+DESC
./+PORTFILE
./+STATE
./opt/
./opt/local/
./opt/local/var/
./opt/local/var/system_roots/
./opt/local/var/system_roots/libcxx-5.0.1-4.tgz
---> Cleaning libcxx
---> Removing work directory for libcxx
---> Scanning binaries for linking errors
---> Found 69 broken files, matching files to ports
---> Found 2 broken ports, determining rebuild order
You can always run 'port rev-upgrade' again to fix errors.
The following ports will be rebuilt:
libxml2 @2.9.12
llvm-3.4 @3.4.2
Continue? [Y/n]: nThis, however, is not a “universal” in a way that both PowerPC and Snow Leopard Intel Macs will understand. It is not a universal of i386 and ppc code bundled together. I can verify this by browsing to a libcxx library and checking its contents:
sh-4.3# cd /opt/local/libexec/libcxx-bootstrap/lib
sh-4.3# file libform.6.dylib
libform.6.dylib: Mach-O dynamically linked shared library i386So once that libcxx is installed, despite it being an i386 installation on ppc, I try a port-install for ncurses with that portconfigure.tcl (still looking for “ppc”). This is what happens:
sh-4.3# port install ncurses
---> Computing dependencies for ncurses
Error: Cannot install ncurses for the arch 'ppc' because
Error: its dependency libcxx only supports the archs 'i386 x86_64'.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port ncurses failedThis makes sense since the libcxx which installed is entirely written for Intel architecture. So what about libcxx-5.0.1_4+universal.darwin_10.ppc.tbz2 or even libcxx-5.0.1_4+universal.darwin_10.noarch.tbz2?
404. They don’t exist, and they probably never have.
Try this yourself. Throw either of these builds of OS X onto a spare a PowerPC Mac you can use for testing and apply all of this in your own test environment. Please let me know how it goes. I insist!
macports-base/src/port1.0/portconfigure.tcl at master · macports/macports-base
The MacPorts command-line client. Contribute to macports/macports-base development by creating an account on GitHub.
You have that file installed on your system now, in /opt/local/libexec/macports, if memory serves.
You would want to edit that function, possibly in only one spot, to returb ppc no matter what.
As I’ve said, I’ve done this. In fact, I’ve done this twice. The outcome remains identical.
[EDIT: There is a discussion from the first week of September 2009, one week after Snow Leopard went on sale, that is somewhat adjacent to this issue. In it, there is clarification that macports archives would likely never factor into the mix port files for a Darwin 10 — not the final Darwin 10, obviously — deployed on a PowerPC Mac.]
Last edited:
So, for sake of discussion, I could build Macports_2.6.4 from the github archive, avoid using “selfupdate” (to prevent it from updating to 2.7.1), and just run a port-install on the desired ports? On SL-PPC, as Macports must be built from source code anyway, it has to do that slow sync regardless, and it’s something I’ve factored into the mix every time I’ve compiled MP on said SL-PPC Mac — namely, by setting aside several hours for it to run the sync. This is also why I’ve only had time since the weekend to build MP from source four times as I try different approaches per stuff brought up earlier in this thread.
Last edited:
I hope you finally built gcc; that was your original goal in this thread, in itself something of a long shot, but perhaps within reach.
I realize what you are trying to do with MacPorts has many pitfalls. If I install ppc for SL and fix them, I will let you know what I find.
I realize what you are trying to do with MacPorts has many pitfalls. If I install ppc for SL and fix them, I will let you know what I find.
If you want to PM me, I can tell you the "easy" no sync way to do this. It's not relevant to this thread, so I won't post it here.
Not exactly. The goal, described in the opening post, was to ultimately get irssi running on the PowerPC Mac running Snow Leopard 10A96.
What I have done since the other day is the following:
- I made a list of all the source code tarballs I compiled from scratch last week (back when I was still working with the first compile-build of Macports2.7.1, and I also added to that list all the source code tarballs I couldn’t compile.
- Next, I used Macports on another PowerPC Mac running Leopard (and thus, Darwin9) to run “port pkg [portname_of_tarball_from_#1]” on each item in that list. I chose overkill to err on the side of the precautionary principle.
- Then, I installed each of those, individually, on the PowerPC Mac running Darwin10/10A96. I installed each of the three items you listed in addition to everything I had built — or tried to build — in #1.
- Because I learnt earlier how the current irssi_1.2.3 is having basic functionality issues across all my PowerPC Macs — at least, as installed via Macports (on Darwin8, Darwin9, and Darwin10 PowerPC Macs, with Darwin10 install failing following a “port mpkg irssi” made on the Darwin9 Mac) — I manually compiled its predecessor, irssi_1.2.2, on the Darwin10 PPC earlier today.
The only method I can see which affords a reasonable ability to build anything more substantial than standalone “noarch” ports on Snow Leopard for PowerPC (Darwin10) is to first use Macports on a PowerPC Mac running Leopard to generate .pkg installs for each individual component required to build a target-something/application. This isn’t what I wanted ideally, but the Macports team never foresaw the possibility of PowerPC Macs successfully running a version of Snow Leopard and, thus, never made ports available for use on Darwin10/PPC.
Sure, that something could also be installed from a .pkg generated by a Leopard Macports instance, but given the problems of using the port pkg of irssi_1.2.3 — the ultimate thing I wanted to build here — I chose to configure and make that application manually on the SL-PPC Mac so that I could rule out that aforementioned flaw in a pre-made port or a buggy version being the culprit.
And so, as connected to an ngircd instance on another Mac in my LAN, minutes ago:
Where I’m from, that’s good enough for now.
I originally was pulled in here by the question of whether a newer gcc would build on this system, and I have indeed been successful in so doing, using the script I posted and a couple of small, single-digit changes in gcc/config/darwin.h:
$ ./gcc -v
Using built-in specs.
COLLECT_GCC=./gcc
COLLECT_LTO_WRAPPER=/opt/gcc7/libexec/gcc/powerpc-apple-darwin10.0.0d2/7.5.0/lto-wrapper
Target: powerpc-apple-darwin10.0.0d2
Configured with: ../configure --prefix=/opt/gcc7 --enable-languages=c,c++,fortran,lto,objc,obj-c++ --with-system-zlib --disable-nls --disable-multilib --with-dwarf2
Thread model: posix
gcc version 7.5.0 (GCC)
So that is gcc7.5.0 at least, and probably most or all of the gccs will all build, if I were to try. The changes are mostly to account for the hybrid nature of this system, being between 10.5.8 and 10.6.8, which are the two systems gcc actually supports. I'll put the changes into actual patches for MacPorts' build of these compilers, I think.
And on that note, MacPorts runs on 10.6 PPC quite well, normally even, with a few adjustments for the ppc arch and a couple of idiosyncrasies. Several ports need minor tweaking, based on assumptions that 10.6 = i386 and similar, but it largely looks quite do-able. Here's what I built so far on 10.6 PPC with MacPorts, and I'll see what should be done next.
$ port -v installed
The following ports are currently installed:
bzip2 @1.0.8_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-22T21:44:04-0700'
cctools @949.0.1_1 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-22T21:42:09-0700'
db48 @4.8.30_4 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T11:31:10-0700'
expat @2.4.1_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T11:33:02-0700'
gdbm @1.20_1 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T12:24:21-0700'
gettext @0.19.8.1_2 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-22T21:29:04-0700'
gperf @3.1_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-22T20:47:53-0700'
ld64 @3_3+ld64_127 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T15:04:32-0700'
ld64-127 @127.2_14+llvm34 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T15:04:28-0700'
libedit @20210216-3.1_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T11:34:13-0700'
libffi @3.3_1 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T11:34:58-0700'
libiconv @1.16_1 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-22T20:53:42-0700'
libmacho-headers @949.0.1_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-23T15:01:52-0700'
libunwind-headers @5.0.1_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-22T21:33:18-0700'
llvm-3.4 @3.4.2_14 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T14:54:52-0700'
llvm_select @2_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-23T14:00:06-0700'
ncurses @6.2_1 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-22T20:45:57-0700'
openssl @1.1.1k_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T13:16:30-0700'
perl5 @5.28.3_0+perl5_28 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-23T13:00:38-0700'
perl5.28 @5.28.3_4 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T12:43:22-0700'
pkgconfig @0.29.2_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T13:20:14-0700'
python2_select @0.0_3 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-23T13:20:18-0700'
python27 @2.7.18_2 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T13:37:05-0700'
python_select @0.3_9 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-23T13:20:20-0700'
readline @8.1.000_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T12:23:12-0700'
sqlite3 @3.36.0_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T13:25:17-0700'
xz @5.2.5_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-22T21:33:06-0700'
zlib @1.2.11_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T11:35:18-0700'
All of them are proper PPC binaries, of course, no i386 binaries in this mix, and so far, at least, they all seem to work just fine.
I'll think about how to make these MacPorts changes available. I don't want to cause too much confusion in so doing. Probably I'll make a repo with the macports-base changes integrated, and a custom ports tree overlay like I do with TigerPorts, LeopardPorts, SnowLeopardPorts, and LionPorts, and people can use it if they so choose to do so.
$ ./gcc -v
Using built-in specs.
COLLECT_GCC=./gcc
COLLECT_LTO_WRAPPER=/opt/gcc7/libexec/gcc/powerpc-apple-darwin10.0.0d2/7.5.0/lto-wrapper
Target: powerpc-apple-darwin10.0.0d2
Configured with: ../configure --prefix=/opt/gcc7 --enable-languages=c,c++,fortran,lto,objc,obj-c++ --with-system-zlib --disable-nls --disable-multilib --with-dwarf2
Thread model: posix
gcc version 7.5.0 (GCC)
So that is gcc7.5.0 at least, and probably most or all of the gccs will all build, if I were to try. The changes are mostly to account for the hybrid nature of this system, being between 10.5.8 and 10.6.8, which are the two systems gcc actually supports. I'll put the changes into actual patches for MacPorts' build of these compilers, I think.
And on that note, MacPorts runs on 10.6 PPC quite well, normally even, with a few adjustments for the ppc arch and a couple of idiosyncrasies. Several ports need minor tweaking, based on assumptions that 10.6 = i386 and similar, but it largely looks quite do-able. Here's what I built so far on 10.6 PPC with MacPorts, and I'll see what should be done next.
$ port -v installed
The following ports are currently installed:
bzip2 @1.0.8_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-22T21:44:04-0700'
cctools @949.0.1_1 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-22T21:42:09-0700'
db48 @4.8.30_4 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T11:31:10-0700'
expat @2.4.1_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T11:33:02-0700'
gdbm @1.20_1 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T12:24:21-0700'
gettext @0.19.8.1_2 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-22T21:29:04-0700'
gperf @3.1_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-22T20:47:53-0700'
ld64 @3_3+ld64_127 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T15:04:32-0700'
ld64-127 @127.2_14+llvm34 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T15:04:28-0700'
libedit @20210216-3.1_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T11:34:13-0700'
libffi @3.3_1 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T11:34:58-0700'
libiconv @1.16_1 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-22T20:53:42-0700'
libmacho-headers @949.0.1_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-23T15:01:52-0700'
libunwind-headers @5.0.1_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-22T21:33:18-0700'
llvm-3.4 @3.4.2_14 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T14:54:52-0700'
llvm_select @2_0 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-23T14:00:06-0700'
ncurses @6.2_1 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-22T20:45:57-0700'
openssl @1.1.1k_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T13:16:30-0700'
perl5 @5.28.3_0+perl5_28 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-23T13:00:38-0700'
perl5.28 @5.28.3_4 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T12:43:22-0700'
pkgconfig @0.29.2_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T13:20:14-0700'
python2_select @0.0_3 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-23T13:20:18-0700'
python27 @2.7.18_2 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T13:37:05-0700'
python_select @0.3_9 (active) requested_variants='' platform='darwin 10' archs='noarch' date='2021-08-23T13:20:20-0700'
readline @8.1.000_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T12:23:12-0700'
sqlite3 @3.36.0_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T13:25:17-0700'
xz @5.2.5_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-22T21:33:06-0700'
zlib @1.2.11_0 (active) requested_variants='' platform='darwin 10' archs='ppc' date='2021-08-23T11:35:18-0700'
All of them are proper PPC binaries, of course, no i386 binaries in this mix, and so far, at least, they all seem to work just fine.
I'll think about how to make these MacPorts changes available. I don't want to cause too much confusion in so doing. Probably I'll make a repo with the macports-base changes integrated, and a custom ports tree overlay like I do with TigerPorts, LeopardPorts, SnowLeopardPorts, and LionPorts, and people can use it if they so choose to do so.
What command line syntax did you invoke to make macports obtain ppc tarballs for darwin_10 install?
The command syntax is unchanged: "sudo port -v install xz", or your desired port. A version of the previously-described changes in macports.conf and archive_sites.conf allow it to work.
Working on a version of the edits for general users, but beware, there are potholes in Portfile where assumptions have been made that require rethinking.
libgcc11 is not yet bootstrapping (on 10.6 Intel I used clang-9.0 to bootstrap it, but that is not an option on 10.6 PPC because clang is non-functional on PPC as yet).
Setting up 10.6 for PPC was a breeze, by the way. Only hiccup was finding an empty 200GB FireWire HD to use...
The advantage, really, is being able to build newer code bases that require C11 / c++11 or greater. And it comes with it's own set of issues.
Could you walk us through the adjustments and highlight those idiosyncrasices in a step-by-step here?
I’m asking for this step-by-step because not only has it so far eluded my ability to make it work as you’ve reported, but I also know the community here comes from many levels of competence and comfort with the more advanced workings of macports. Few, however, are as thoroughly acquainted and comfortable with it as you and maybe also alex. Cheers.
Last edited:
I am just putting together some final touches, so that when people try this they have a good experience, with as much as possible, no pitfalls.
I know gcc7 builds on this system, and for many years, libgcc7 was the basic gcc library for the newer gcc ports on MacPorts. I changed that, ironically, a couple of months ago to libgcc11, and so now I have to make libgcc11 work on a PPC SnowLeopard system that bootstraps without clang. Or I can consider rolling it back to libgcc7 for this system, but if I do that, the divergence between this and MacPorts grows, which is always a cause for trouble. So currently getting to bootstrap to libgcc11 if I can is the plan.
It will never be perfect, of course. So far my "tweak rate" to install ports on PPC SnowLeopard is about 25% of ports need something. The tweaks are all reasonably minor to me, but may not be so obvious to someone who has not spent the many years fixing non-building ports on MacPorts that I have. ld64-127 had an interesting issue with missing symbols in the older libSystem.B.dylib, that was in the end a simple one-digit change, easy enough once you know just what digit needs changing.
I'll focus on the toolchain at the beginning, so people don't build broken infrastructure off the bat.
There will always be a portfile overlay needed to make this work, as few of the PPC SnowLeopard fixes would ever be appropriate to upstream to MacPorts. If a portfile overlay is too overwhelming for someone to consider, then I would say this project is likely over the head of such a user.
I know gcc7 builds on this system, and for many years, libgcc7 was the basic gcc library for the newer gcc ports on MacPorts. I changed that, ironically, a couple of months ago to libgcc11, and so now I have to make libgcc11 work on a PPC SnowLeopard system that bootstraps without clang. Or I can consider rolling it back to libgcc7 for this system, but if I do that, the divergence between this and MacPorts grows, which is always a cause for trouble. So currently getting to bootstrap to libgcc11 if I can is the plan.
It will never be perfect, of course. So far my "tweak rate" to install ports on PPC SnowLeopard is about 25% of ports need something. The tweaks are all reasonably minor to me, but may not be so obvious to someone who has not spent the many years fixing non-building ports on MacPorts that I have. ld64-127 had an interesting issue with missing symbols in the older libSystem.B.dylib, that was in the end a simple one-digit change, easy enough once you know just what digit needs changing.
I'll focus on the toolchain at the beginning, so people don't build broken infrastructure off the bat.
There will always be a portfile overlay needed to make this work, as few of the PPC SnowLeopard fixes would ever be appropriate to upstream to MacPorts. If a portfile overlay is too overwhelming for someone to consider, then I would say this project is likely over the head of such a user.