Sidebar Sidebar
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]

yeah, I went back and read your first post more clearly. I kinda got pulled into the middle of this chain by Alex's other gcc question and didn't see that you were on this system at first.

I have 10 PPC machines and have that 10.6 for PPC, but life is short and I haven't got around to trying it.

--disable-multilib should fix you, I'm guessing. You don't really need a cross-compiler so I'll skip explaining that for now.

Best of luck!
 
  • Like
Reactions: alex_free and B S Magnet
or-- just pull the "pragma gcc diagnodtics" out of the source you're working with. They are completely optional.

I have done dozens of fixes like that on MacPorts to make things build with gcc-4.2.
 
  • Like
Reactions: alex_free
kencu said:
or-- just pull the "pragma gcc diagnodtics" out of the source you're working with. They are completely optional.
Click to expand...

I wouldn’t even know where to begin to look for that, to be honest.

kencu said:
I have done dozens of fixes like that on MacPorts to make things build with gcc-4.2.
Click to expand...

If only Macports had darwin10.ppc sources…
 
MacPorts no doubt works on that Darwin10 PPC system, or can be made to if not. It runs great on Ubuntu 2104 for example.

But in the tcl logic throughout MacPorts base code, Portfiles, and PortGroups, there will likely be many places where assumptions are made...like darwin10 can use clang and not build for powerpc...that would need to be tweaked. Certainly possible. Perhaps a MP fork might be needed, though, as upstreaming such fixes for 10.6 on PPC would be highly unlikely.
 
  • Like
Reactions: barracuda156
Off the topic of building a newer gcc for you, but I thought I might make you a patch for irssi to get past the pragma gcc diagnostics. However, in MacPorts, without any patches of note, irssi just builds through from start to finish on Tiger with gcc-4.2 without any errors. It is irssi version 1.2.3.

grepping the source for irssi, the only place I see it is here:

$ ag pragma
build-aux/ltmain.sh
4603:#pragma GCC diagnostic ignored \"-Wstrict-prototypes\"

and that is already guarded so you should not stumble across it:

Code: 
#if defined __GNUC__ && (((__GNUC__ == 4) && (__GNUC_MINOR__ >= 4)) || (__GNUC__ > 4))
#pragma GCC diagnostic ignored \"-Wstrict-prototypes\"
#endif

but if that guard is not working, you can just delete that completely from ltmain.sh. There is no other place I can detect a pragma in the irssi source.

If it is some other prerequisite that irssi needs that is causing your stumble, that would be a separate issue of course.
 
kencu said:
MacPorts no doubt works on that Darwin10 PPC system, or can be made to if not. It runs great on Ubuntu 2104 for example.
Click to expand...

I mean, I’ve compiled Macports 2.7.1 from source on this environment just fine, but when I attempt a port install, it almost always errors out with a “bad CPU type” error after grabbing the “i386” tarball of a port. The only ports I’ve installed successfully after compiling 2.7.1 are mpstats and neofetch, as both were available as “noarch” tarballs.

In any case, the --disable-multilib flag addition just brought me back to a similar error I ran into earlier in the week which I may or may not have documented earlier in this discussion thread (the similarities being: an “error 77” and “C compiler cannot create executables”):

MLIBS=`/opt/gcc_kencu/gcc-7.5.0/objdir/./gcc/xgcc -B/opt/gcc_kencu/gcc-7.5.0/objdir/./gcc/ -B/opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/bin/ -B/opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/lib/ -isystem /opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/include -isystem /opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/sys-include --print-multi-lib | sed -e 's/;.*$//'` ; \ for mlib in $MLIBS ; do \ strip -o libgcc_ext.10.5.dylib_T${mlib} \ -R ../../../libgcc/config/rs6000/libgcc-darwin.10.5.ver -c -urx \ ../${mlib}/libgcc/${mlib}/libgcc_s.dylib || exit 1 ; \ done lipo -output libgcc_s.1.dylib \ -create libgcc_s.1.dylib_T* lipo -output libgcc_ext.10.4.dylib -create libgcc_ext.10.4.dylib_T* lipo -output libgcc_ext.10.5.dylib -create libgcc_ext.10.5.dylib_T* rm libgcc_ext.10.5.dylib_T* rm libgcc_s.1.dylib_T* rm libgcc_ext.10.4.dylib_T* # Now that we have built all the objects, we need to copy # them back to the GCC directory. Too many things (other # in-tree libraries, and DejaGNU) know about the layout # of the build tree, for now. make install-leaf DESTDIR=../.././gcc \ slibdir= libsubdir= MULTIOSDIR=. make[4]: Entering directory `/opt/gcc_kencu/gcc-7.5.0/objdir/powerpc-apple-darwin10.0.0d1/libgcc' /bin/sh ../../../libgcc/../mkinstalldirs ../.././gcc /bin/sh ../../../libgcc/../mkinstalldirs ../.././gcc /usr/bin/install -c -m 644 libgcc_eh.a ../.././gcc/ for d in libgcc_s.1.dylib libgcc_ext.10.4.dylib libgcc_ext.10.5.dylib ; do \ /usr/bin/install -c -m 644 $d ../.././gcc/$d || exit 1 ; \ done chmod 644 ../.././gcc/libgcc_eh.a ranlib ../.././gcc/libgcc_eh.a if [ -f ../.././gcc/libgcc_s_ppc64.1.dylib ]; then \ ranlib: file: ../.././gcc/libgcc_eh.a(unwind-sjlj.o) has no symbols rm -f ../.././gcc/libgcc_s_ppc64.1.dylib; \ else true; fi ln -s libgcc_s.1.dylib \ ../.././gcc/libgcc_s_ppc64.1.dylib if [ -f ../.././gcc/libgcc_s_x86_64.1.dylib ]; then \ rm -f ../.././gcc/libgcc_s_x86_64.1.dylib; \ else true; fi ln -s libgcc_s.1.dylib \ ../.././gcc/libgcc_s_x86_64.1.dylib /bin/sh ../../../libgcc/../mkinstalldirs ../.././gcc /usr/bin/install -c -m 644 libgcc.a ../.././gcc/ chmod 644 ../.././gcc/libgcc.a ranlib ../.././gcc/libgcc.a ranlib: file: ../.././gcc/libgcc.a(_trampoline.o) has no symbols ranlib: file: ../.././gcc/libgcc.a(_ctors.o) has no symbols ranlib: file: ../.././gcc/libgcc.a(_powixf2.o) has no symbols ranlib: file: ../.././gcc/libgcc.a(_mulhc3.o) has no symbols ranlib: file: ../.././gcc/libgcc.a(_mulxc3.o) has no symbols ranlib: file: ../.././gcc/libgcc.a(_divhc3.o) has no symbols ranlib: file: ../.././gcc/libgcc.a(_divxc3.o) has no symbols ranlib: file: ../.././gcc/libgcc.a(_fixunsxfsi.o) has no symbols ranlib: file: ../.././gcc/libgcc.a(_fixxfdi.o) has no symbols ranlib: file: ../.././gcc/libgcc.a(_fixunsxfdi.o) has no symbols ranlib: file: ../.././gcc/libgcc.a(_floatdixf.o) has no symbols ranlib: file: ../.././gcc/libgcc.a(_floatundixf.o) has no symbols ranlib: file: ../.././gcc/libgcc.a(darwin-64.o) has no symbols ranlib: file: ../.././gcc/libgcc.a(ppc64-fp.o) has no symbols /usr/bin/install -c -m 644 libgcov.a ../.././gcc/ chmod 644 ../.././gcc/libgcov.a ranlib ../.././gcc/libgcov.a ranlib: file: ../.././gcc/libgcov.a(_gcov_interval_profiler_atomic.o) has no symbols ranlib: file: ../.././gcc/libgcov.a(_gcov_pow2_profiler_atomic.o) has no symbols ranlib: file: ../.././gcc/libgcov.a(_gcov_one_value_profiler_atomic.o) has no symbols ranlib: file: ../.././gcc/libgcov.a(_gcov_average_profiler_atomic.o) has no symbols ranlib: file: ../.././gcc/libgcov.a(_gcov_ior_profiler_atomic.o) has no symbols parts="crt3.o crttms.o crttme.o crt2.o crt3_2.o libef_ppc.a dw_ppc.o"; \ for file in $parts; do \ rm -f ../.././gcc/$file; \ /usr/bin/install -c -m 644 $file ../.././gcc/; \ case $file in \ *.a) \ ranlib ../.././gcc/$file ;; \ esac; \ done make[4]: Leaving directory `/opt/gcc_kencu/gcc-7.5.0/objdir/powerpc-apple-darwin10.0.0d1/libgcc' make[3]: Leaving directory `/opt/gcc_kencu/gcc-7.5.0/objdir/powerpc-apple-darwin10.0.0d1/libgcc' mkdir powerpc-apple-darwin10.0.0d1/libgomp Checking multilib configuration for libgomp... Configuring stage 1 in powerpc-apple-darwin10.0.0d1/libgomp configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for --enable-generated-files-in-srcdir... no 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 build environment is sane... yes checking for a thread-safe mkdir -p... ../../../libgomp/../install-sh -c -d checking for gawk... awk checking whether make sets $(MAKE)... yes checking for powerpc-apple-darwin10.0.0d1-gcc... /opt/gcc_kencu/gcc-7.5.0/objdir/./gcc/xgcc -B/opt/gcc_kencu/gcc-7.5.0/objdir/./gcc/ -B/opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/bin/ -B/opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/lib/ -isystem /opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/include -isystem /opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/sys-include checking for C compiler default output file name... configure: error: in `/opt/gcc_kencu/gcc-7.5.0/objdir/powerpc-apple-darwin10.0.0d1/libgomp': configure: error: C compiler cannot create executables See `config.log' for more details. make[2]: *** [configure-stage1-target-libgomp] Error 77 make[2]: Leaving directory `/opt/gcc_kencu/gcc-7.5.0/objdir' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/opt/gcc_kencu/gcc-7.5.0/objdir' make: *** [all] Error 2 sh-4.3#

I’m not sure what to try next.
 
Well OK, progress anyway. No more trying to build gcc for an arch that the system roots don't support.

For this error, you need to see exactly what is happening with the compiler.

The new bootstrap compiler "/opt/gcc_kencu/gcc-7.5.0/objdir/./gcc/xgcc" you built is trying now to build libgomp but it is failing at some basic step. We can't really know what the exact issue is, because all we see is:

cannot create executables
Error 77

which tells us pretty much nothing.

You might see what actually happened by finding the failing lines in the "config.log" -- probably the one in the libgomp folder -- and see exactly what happened. The failing build line will be in there.

You might also try just running /opt/gcc_kencu/gcc-7.5.0/objdir/./gcc/xgcc yourself, and use that bootstrap compiler to build anything at all -- a "hello.c" program as simple as you can make it -- and see if it works at all or if it is just broken completely. It should not be totally broken -- gcc is exceptionally adaptive -- it might be trying to use the wrong linker, or assembler, or put out the wrong CPU subtype, or some such thing that can be fixed.


I can give you some hints about how you might force MacPorts to do your bidding later -- but that kind of issue you found, where 10.6.8 assumes Intel processors -- is exactly what you can expect to find about 1,000 times over in the various portfiles and base. But it can be managed, with sufficient patience and incentive.
 
To get MacPorts to try to do something it doesn't by default want to do, you can try forcing things to your bidding by editing "macports.conf". It is by default at /opt/local/etc/macports/macports.conf.

In that file, you can put overrides that subvert MacPorts base logic for architecture, build SDK, deployment target, recommended compilers, etc.

I might try something like this in there:

Code: 
buildmakejobs          2                # or a more appropriate number for your processor count
default_compilers      gcc-4.2            # override compiler selection. we can add more if any others work
cxx_stdlib             libstdc++        # make sure we use this in this case
build_arch             ppc

a full listing of all the available compilers that can be put in default_compilers is here:

UsingTheRightCompiler – MacPorts

trac.macports.org trac.macports.org

MacPorts will choose the first one in the default_compilers list that has not been specifically blacklisted in the Portfile.

You might also disable archive_sites, as there is absolutely nothing in MacPorts buildbot archives of use to you, and it will only cause a mess.

You disable archive_sites in MacPorts by editing /opt/local/etc/macports/archive_sites.conf and what you need to do is on the very last line or two of that file.
 
kencu said:
To get MacPorts to try to do something it doesn't by default want to do, you can try forcing things to your bidding by editing "macports.conf". It is by default at /opt/local/etc/macports/macports.conf.

In that file, you can put overrides that subvert MacPorts base logic for architecture, build SDK, deployment target, recommended compilers, etc.

I might try something like this in there:

Code: 
buildmakejobs          2                # or a more appropriate number for your processor count
default_compilers      gcc-4.2            # override compiler selection. we can add more if any others work
cxx_stdlib             libstdc++        # make sure we use this in this case
build_arch             ppc
Click to expand...

Yes. I’ve already tried the “build_arch” variable in macports.conf. What happens is the fetch never begins:

1628979725985.png

kencu said:
MacPorts will choose the first one in the default_compilers list that has not been specifically blacklisted in the Portfile.

You might also disable archive_sites, as there is absolutely nothing in MacPorts buildbot archives of use to you, and it will only cause a mess.

You disable archive_sites in MacPorts by editing /opt/local/etc/macports/archive_sites.conf and what you need to do is on the very last line or two of that file.
Click to expand...

Same basic outcome of an unfulfilled fetch:

1628979897388.png
 
I'm kind of curious about something. SM64EXLC contains an ENTIRE MacPorts installation including GCC 7.5.0 which was all compiled on Leopard, since it needs the GCC 7.5 compiler to build the SM64 decomp port. Technically you can use it as a normal MacPorts installation if you copy SM64EXLC.app to /Applications and then EXPORT PATH=/Applications/SM64EXLC.app/bin:$PATH. This might allow you to use GCC 7.5.0 on 10.6, but it would be built for Leopard, and just happen to work on Snow Leopard. I know this isn't really what you want to do, but it probably would give you GCC 7 on Snow Leopard.
 
  • Like
Reactions: barracuda156 and G4fanboy
kencu said:
You might see what actually happened by finding the failing lines in the "config.log" -- probably the one in the libgomp folder -- and see exactly what happened. The failing build line will be in there.
Click to expand...

In /opt/gcc_kencu/gcc-7.5.0/objdir/powerpc-apple-darwin10.0.0d1/libgomp/ the config.log does expand on the error, but beyond that, I don’t know much more on why it failed. The error portion is pasted; the config.log will be attached momentarily:

configure:3703: $? = 0 configure:3692: /opt/gcc_kencu/gcc-7.5.0/objdir/./gcc/xgcc -B/opt/gcc_kencu/gcc-7.5.0/objdir/./gcc/ -B/opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/bin/ -B/opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/lib/ -isystem /opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/include -isystem /opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/sys-include -v >&5 Reading specs from /opt/gcc_kencu/gcc-7.5.0/objdir/./gcc/specs COLLECT_GCC=/opt/gcc_kencu/gcc-7.5.0/objdir/./gcc/xgcc COLLECT_LTO_WRAPPER=/opt/gcc_kencu/gcc-7.5.0/objdir/./gcc/lto-wrapper Target: powerpc-apple-darwin10.0.0d1 Configured with: ../configure --prefix=/opt/gcc_kencu --enable-languages=c,c++,fortran,lto,objc,obj-c++ --with-system-zlib --disable-nls --with-dwarf2 --disable-multilib Thread model: posix gcc version 7.5.0 (GCC) configure:3703: $? = 0 configure:3692: /opt/gcc_kencu/gcc-7.5.0/objdir/./gcc/xgcc -B/opt/gcc_kencu/gcc-7.5.0/objdir/./gcc/ -B/opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/bin/ -B/opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/lib/ -isystem /opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/include -isystem /opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/sys-include -V >&5 xgcc: error: unrecognized command line option '-V' xgcc: fatal error: no input files compilation terminated. configure:3703: $? = 1 configure:3692: /opt/gcc_kencu/gcc-7.5.0/objdir/./gcc/xgcc -B/opt/gcc_kencu/gcc-7.5.0/objdir/./gcc/ -B/opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/bin/ -B/opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/lib/ -isystem /opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/include -isystem /opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/sys-include -qversion >&5 xgcc: error: unrecognized command line option '-qversion'; did you mean '--version'? xgcc: fatal error: no input files compilation terminated. configure:3703: $? = 1 configure:3723: checking for C compiler default output file name configure:3745: /opt/gcc_kencu/gcc-7.5.0/objdir/./gcc/xgcc -B/opt/gcc_kencu/gcc-7.5.0/objdir/./gcc/ -B/opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/bin/ -B/opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/lib/ -isystem /opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/include -isystem /opt/gcc_kencu/powerpc-apple-darwin10.0.0d1/sys-include -g -O2 conftest.c >&5 ld: unknown option: -no_compact_unwind collect2: error: ld returned 1 exit status configure:3749: $? = 1 configure:3786: result: configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "GNU Offloading and Multi Processing Runtime Library" | #define PACKAGE_TARNAME "libgomp" | #define PACKAGE_VERSION "1.0" | #define PACKAGE_STRING "GNU Offloading and Multi Processing Runtime Library 1.0" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "http://www.gnu.org/software/libgomp/" | #define PACKAGE "libgomp" | #define VERSION "1.0" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:3792: error: in `/opt/gcc_kencu/gcc-7.5.0/objdir/powerpc-apple-darwin10.0.0d1/libgomp': configure:3796: error: C compiler cannot create executables See `config.log' for more details.
 

Attachments

  • config.log.zip
    3.6 KB · Views: 118
alex_free said:
What does sudo port -d install python37 do?
Click to expand...

sh-4.3# port -d install python37 DEBUG: Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/lang/python37 DEBUG: OS darwin/10.0.0d1 (macOS 10.6) arch powerpc DEBUG: Sourcing PortGroup select 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/select-1.0.tcl DEBUG: Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf DEBUG: universal variant already exists, so not adding the default one DEBUG: Requested variant +ppc is not provided by port python37. DEBUG: Requested variant +noarch is not provided by port python37. DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Finished running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Finished running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Running callback portstartupitem::add_notes DEBUG: Finished running callback portstartupitem::add_notes DEBUG: dropping privileges: euid changed to 502, egid changed to 502. DEBUG: Starting logging for python37 @3.7.11_0 DEBUG: Mac OS X 10.6 (darwin/10.0.0d1) arch powerpc DEBUG: MacPorts 2.7.1 DEBUG: Xcode 3.2 DEBUG: SDK 10.6 DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.6 Warning: archive_sites.conf: no urls set for macports_archives DEBUG: epoch: in tree: 0 installed: 0 DEBUG: xz 5.2.5_0 exists in the ports tree DEBUG: xz 5.2.5_0 is the latest installed DEBUG: xz 5.2.5_0 is active DEBUG: Merging existing requested variants '' into variants DEBUG: new fully merged portvariants: ppc + noarch + DEBUG: Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/archivers/xz DEBUG: OS darwin/10.0.0d1 (macOS 10.6) arch powerpc DEBUG: Sourcing PortGroup clang_dependency 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/clang_dependency-1.0.tcl DEBUG: adding the default universal variant DEBUG: Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf DEBUG: Requested variant +noarch is not provided by port xz. DEBUG: Requested variant +ppc is not provided by port xz. DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Finished running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Finished running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Running callback portstartupitem::add_notes DEBUG: Finished running callback portstartupitem::add_notes DEBUG: No need to upgrade! xz 5.2.5_0 >= xz 5.2.5_0 DEBUG: epoch: in tree: 0 installed: 0 DEBUG: libiconv 1.16_1 exists in the ports tree DEBUG: libiconv 1.16_1 is the latest installed DEBUG: libiconv 1.16_1 is active DEBUG: Merging existing requested variants '' into variants DEBUG: new fully merged portvariants: ppc + noarch + DEBUG: Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/textproc/libiconv DEBUG: OS darwin/10.0.0d1 (macOS 10.6) arch powerpc DEBUG: Sourcing PortGroup muniversal 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/muniversal-1.0.tcl DEBUG: Sourcing PortGroup clang_dependency 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/clang_dependency-1.0.tcl DEBUG: Sourcing PortGroup xcodeversion 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/xcodeversion-1.0.tcl DEBUG: muniversal: adding universal variant DEBUG: Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf DEBUG: Requested variant +noarch is not provided by port libiconv. DEBUG: Requested variant +ppc is not provided by port libiconv. DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Finished running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Finished running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Running callback portstartupitem::add_notes DEBUG: Finished running callback portstartupitem::add_notes DEBUG: Running callback xcodeversions_run_check DEBUG: Finished running callback xcodeversions_run_check DEBUG: No need to upgrade! libiconv 1.16_1 >= libiconv 1.16_1 DEBUG: epoch: in tree: 2 installed: 2 DEBUG: gettext 0.19.8.1_2 exists in the ports tree DEBUG: gettext 0.19.8.1_2 is the latest installed DEBUG: gettext 0.19.8.1_2 is active DEBUG: Merging existing requested variants '' into variants DEBUG: new fully merged portvariants: ppc + noarch + DEBUG: Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/devel/gettext DEBUG: OS darwin/10.0.0d1 (macOS 10.6) arch powerpc DEBUG: Sourcing PortGroup compiler_blacklist_versions 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/compiler_blacklist_versions-1.0.tcl DEBUG: Sourcing PortGroup muniversal 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/muniversal-1.0.tcl DEBUG: Sourcing PortGroup clang_dependency 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/clang_dependency-1.0.tcl DEBUG: compiler clang blacklisted because it's not installed or it doesn't work DEBUG: muniversal: adding universal variant DEBUG: Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf DEBUG: Requested variant +noarch is not provided by port gettext. DEBUG: Requested variant +ppc is not provided by port gettext. DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Finished running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Finished running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Running callback portstartupitem::add_notes DEBUG: Finished running callback portstartupitem::add_notes DEBUG: cxx_stdlib mismatch ... upgrading! DEBUG: epoch: in tree: 0 installed: 0 DEBUG: ncurses 6.2_1 exists in the ports tree DEBUG: ncurses 6.2_1 is the latest installed DEBUG: ncurses 6.2_1 is active DEBUG: Merging existing requested variants '' into variants DEBUG: new fully merged portvariants: ppc + noarch + DEBUG: Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/devel/ncurses DEBUG: OS darwin/10.0.0d1 (macOS 10.6) arch powerpc DEBUG: Sourcing PortGroup clang_dependency 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/clang_dependency-1.0.tcl DEBUG: adding the default universal variant DEBUG: Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf DEBUG: Requested variant +noarch is not provided by port ncurses. DEBUG: Requested variant +ppc is not provided by port ncurses. DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Finished running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Finished running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Running callback portstartupitem::add_notes DEBUG: Finished running callback portstartupitem::add_notes DEBUG: cxx_stdlib mismatch ... upgrading! DEBUG: dropping privileges: euid changed to 502, egid changed to 502. DEBUG: Starting logging for ncurses @6.2_1 DEBUG: Mac OS X 10.6 (darwin/10.0.0d1) arch powerpc DEBUG: MacPorts 2.7.1 DEBUG: Xcode 3.2 DEBUG: SDK 10.6 DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.6 DEBUG: Executing org.macports.main (ncurses) DEBUG: dropping privileges: euid changed to 502, egid changed to 502. DEBUG: archivefetch phase started at Sat Aug 14 18:45:42 EDT 2021 DEBUG: Executing org.macports.archivefetch (ncurses) DEBUG: dropping privileges: euid changed to 502, egid changed to 502. DEBUG: Starting logging for ncurses @6.2_1 DEBUG: Mac OS X 10.6 (darwin/10.0.0d1) arch powerpc DEBUG: MacPorts 2.7.1 DEBUG: Xcode 3.2 DEBUG: SDK 10.6 DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.6 DEBUG: Executing org.macports.main (ncurses) DEBUG: dropping privileges: euid changed to 502, egid changed to 502. DEBUG: fetch phase started at Sat Aug 14 18:45:43 EDT 2021 ---> Fetching distfiles for ncurses DEBUG: Executing org.macports.fetch (ncurses) ---> ncurses-6.2.tar.gz does not exist in /opt/local/var/macports/distfiles/ncurses ---> Attempting to fetch ncurses-6.2.tar.gz from http://distfiles.macports.org/ncurses

And after that, nothing further. It just waits.

alex_free said:
I'm kind of curious about something. SM64EXLC contains an ENTIRE MacPorts installation including GCC 7.5.0 which was all compiled on Leopard, since it needs the GCC 7.5 compiler to build the SM64 decomp port. Technically you can use it as a normal MacPorts installation if you copy SM64EXLC.app to /Applications and then EXPORT PATH=/Applications/SM64EXLC.app/bin:$PATH. This might allow you to use GCC 7.5.0 on 10.6, but it would be built for Leopard, and just happen to work on Snow Leopard. I know this isn't really what you want to do, but it probably would give you GCC 7 on Snow Leopard.
Click to expand...

In the earlier attempt at trying to get Macports (in 2.6.4) to recognize (or think) this was a Darwin9 system, it complained (correctly) that this was a Darwin10 system.
 
B S Magnet said:
sh-4.3# port -d install python37 DEBUG: Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/lang/python37 DEBUG: OS darwin/10.0.0d1 (macOS 10.6) arch powerpc DEBUG: Sourcing PortGroup select 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/select-1.0.tcl DEBUG: Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf DEBUG: universal variant already exists, so not adding the default one DEBUG: Requested variant +ppc is not provided by port python37. DEBUG: Requested variant +noarch is not provided by port python37. DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Finished running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Finished running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Running callback portstartupitem::add_notes DEBUG: Finished running callback portstartupitem::add_notes DEBUG: dropping privileges: euid changed to 502, egid changed to 502. DEBUG: Starting logging for python37 @3.7.11_0 DEBUG: Mac OS X 10.6 (darwin/10.0.0d1) arch powerpc DEBUG: MacPorts 2.7.1 DEBUG: Xcode 3.2 DEBUG: SDK 10.6 DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.6 Warning: archive_sites.conf: no urls set for macports_archives DEBUG: epoch: in tree: 0 installed: 0 DEBUG: xz 5.2.5_0 exists in the ports tree DEBUG: xz 5.2.5_0 is the latest installed DEBUG: xz 5.2.5_0 is active DEBUG: Merging existing requested variants '' into variants DEBUG: new fully merged portvariants: ppc + noarch + DEBUG: Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/archivers/xz DEBUG: OS darwin/10.0.0d1 (macOS 10.6) arch powerpc DEBUG: Sourcing PortGroup clang_dependency 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/clang_dependency-1.0.tcl DEBUG: adding the default universal variant DEBUG: Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf DEBUG: Requested variant +noarch is not provided by port xz. DEBUG: Requested variant +ppc is not provided by port xz. DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Finished running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Finished running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Running callback portstartupitem::add_notes DEBUG: Finished running callback portstartupitem::add_notes DEBUG: No need to upgrade! xz 5.2.5_0 >= xz 5.2.5_0 DEBUG: epoch: in tree: 0 installed: 0 DEBUG: libiconv 1.16_1 exists in the ports tree DEBUG: libiconv 1.16_1 is the latest installed DEBUG: libiconv 1.16_1 is active DEBUG: Merging existing requested variants '' into variants DEBUG: new fully merged portvariants: ppc + noarch + DEBUG: Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/textproc/libiconv DEBUG: OS darwin/10.0.0d1 (macOS 10.6) arch powerpc DEBUG: Sourcing PortGroup muniversal 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/muniversal-1.0.tcl DEBUG: Sourcing PortGroup clang_dependency 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/clang_dependency-1.0.tcl DEBUG: Sourcing PortGroup xcodeversion 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/xcodeversion-1.0.tcl DEBUG: muniversal: adding universal variant DEBUG: Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf DEBUG: Requested variant +noarch is not provided by port libiconv. DEBUG: Requested variant +ppc is not provided by port libiconv. DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Finished running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Finished running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Running callback portstartupitem::add_notes DEBUG: Finished running callback portstartupitem::add_notes DEBUG: Running callback xcodeversions_run_check DEBUG: Finished running callback xcodeversions_run_check DEBUG: No need to upgrade! libiconv 1.16_1 >= libiconv 1.16_1 DEBUG: epoch: in tree: 2 installed: 2 DEBUG: gettext 0.19.8.1_2 exists in the ports tree DEBUG: gettext 0.19.8.1_2 is the latest installed DEBUG: gettext 0.19.8.1_2 is active DEBUG: Merging existing requested variants '' into variants DEBUG: new fully merged portvariants: ppc + noarch + DEBUG: Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/devel/gettext DEBUG: OS darwin/10.0.0d1 (macOS 10.6) arch powerpc DEBUG: Sourcing PortGroup compiler_blacklist_versions 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/compiler_blacklist_versions-1.0.tcl DEBUG: Sourcing PortGroup muniversal 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/muniversal-1.0.tcl DEBUG: Sourcing PortGroup clang_dependency 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/clang_dependency-1.0.tcl DEBUG: compiler clang blacklisted because it's not installed or it doesn't work DEBUG: muniversal: adding universal variant DEBUG: Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf DEBUG: Requested variant +noarch is not provided by port gettext. DEBUG: Requested variant +ppc is not provided by port gettext. DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Finished running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Finished running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Running callback portstartupitem::add_notes DEBUG: Finished running callback portstartupitem::add_notes DEBUG: cxx_stdlib mismatch ... upgrading! DEBUG: epoch: in tree: 0 installed: 0 DEBUG: ncurses 6.2_1 exists in the ports tree DEBUG: ncurses 6.2_1 is the latest installed DEBUG: ncurses 6.2_1 is active DEBUG: Merging existing requested variants '' into variants DEBUG: new fully merged portvariants: ppc + noarch + DEBUG: Changing to port directory: /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/devel/ncurses DEBUG: OS darwin/10.0.0d1 (macOS 10.6) arch powerpc DEBUG: Sourcing PortGroup clang_dependency 1.0 from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/group/clang_dependency-1.0.tcl DEBUG: adding the default universal variant DEBUG: Reading variant descriptions from /opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/_resources/port1.0/variant_descriptions.conf DEBUG: Requested variant +noarch is not provided by port ncurses. DEBUG: Requested variant +ppc is not provided by port ncurses. DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Finished running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Finished running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Running callback portstartupitem::add_notes DEBUG: Finished running callback portstartupitem::add_notes DEBUG: cxx_stdlib mismatch ... upgrading! DEBUG: dropping privileges: euid changed to 502, egid changed to 502. DEBUG: Starting logging for ncurses @6.2_1 DEBUG: Mac OS X 10.6 (darwin/10.0.0d1) arch powerpc DEBUG: MacPorts 2.7.1 DEBUG: Xcode 3.2 DEBUG: SDK 10.6 DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.6 DEBUG: Executing org.macports.main (ncurses) DEBUG: dropping privileges: euid changed to 502, egid changed to 502. DEBUG: archivefetch phase started at Sat Aug 14 18:45:42 EDT 2021 DEBUG: Executing org.macports.archivefetch (ncurses) DEBUG: dropping privileges: euid changed to 502, egid changed to 502. DEBUG: Starting logging for ncurses @6.2_1 DEBUG: Mac OS X 10.6 (darwin/10.0.0d1) arch powerpc DEBUG: MacPorts 2.7.1 DEBUG: Xcode 3.2 DEBUG: SDK 10.6 DEBUG: MACOSX_DEPLOYMENT_TARGET: 10.6 DEBUG: Executing org.macports.main (ncurses) DEBUG: dropping privileges: euid changed to 502, egid changed to 502. DEBUG: fetch phase started at Sat Aug 14 18:45:43 EDT 2021 ---> Fetching distfiles for ncurses DEBUG: Executing org.macports.fetch (ncurses) ---> ncurses-6.2.tar.gz does not exist in /opt/local/var/macports/distfiles/ncurses ---> Attempting to fetch ncurses-6.2.tar.gz from http://distfiles.macports.org/ncurses

And after that, nothing further. It just waits.



In the earlier attempt at trying to get Macports (in 2.6.4) to recognize (or think) this was a Darwin9 system, it complained (correctly) that this was a Darwin10 system.
Click to expand...
Yea I'm not saying it would work as a MacPorts installation, but GCC 7 would probably work which is already built in it.
Hmm, I feel like if you changed the MacPorts .conf file discussed by kencu to Leopard PPC values and the 10.5 SDK/10.5 deployment target maybe it would do something. I'd also use Xcode 3.1.4 instead to see if that changes anything.
 
you have the error here:

ld: unknown option: -no_compact_unwind
collect2: error: ld returned 1 exit status

The compiler tried to link this simple nothing program:

int
main ()
{

;
return 0;
}

and got this:

configure:3792: error: in `/opt/gcc_kencu/gcc-7.5.0/objdir/powerpc-apple-darwin10.0.0d1/libgomp':

So -- what happened here? The xgcc compiler sent an option to the linker (-no_compact_unwind) that it thought the linker should understand. But the linker did not understand it, and rather than ignoring it (being a cautious linker) it sent back an error. And the whole house of cards came crashing down.

The linker is probably /usr/bin/ld, as that is the default linker, and I'm pretty sure it's the only linker on that system. The linker probably works -- otherwise you would not have been able to build anything. It's probably a very old linker, but it's probably newer than the linkers that came with Tiger and Leopard, and gcc can make those work.

So the likely scenario then becomes that on darwin 10 (10.6) gcc has been set up to THINK that the linker /usr/bin/ld will understand that option -no_compact_unwind, because most darwin10 (10.6) systems DO have a linker that understands that option.

But you (with the bootleg system you have) have something that gcc has never seen before: a darwin10 system that comes with a /usr/bin/ld that does not understand -no_compact_unwind.

How would we fix such a thing? We could try to fix gcc somehow, to make it learn that this darwin10 system does not have a linker that understands -no_compact_unwind. We could install a newer linker somehow (one that understands -no_compact_unwind) and then tell xgcc to use that during it's bootstrapping (that is what the "bins" directory is really for -- you put symlinks in there for tools you want to force to be used :>). OR -- we could write some kind of a simple wrapper script in shell that we put in /usr/bin/ld and calls the real /usr/bin/ld (perhaps renamed to /usr/bin/ld-original) and before it calls it, it strips out that -no_compact_unwind argument somehow.

All possible. Any one of those might be done, in varying lengths of time. I would first try to get MacPorts working, and see if you can install a newer linker that way maybe. Or download the source to ld64-127 and do it manually if you're up to it. The shell script thing is also possibly not too hard; you will find lots of similar examples on the web from people who have done exactly this for other troublesome situations to use as a template.

And then there is modifying gcc itself. That is the best solution. Not likely the easiest solution for a novice -- gcc is one of the most complicated pieces of software out there, and it is written in such a way as to prevent people from messing with it. But perhaps some digging (I might start with the collect2 script) might lead to an easy way to turn off that -no_compact_unwind option.
 
  • Like
Reactions: barracuda156 and B S Magnet
B S Magnet said:
Yes. I’ve already tried the “build_arch” variable in macports.conf. What happens is the fetch never begins:

View attachment 1818776


Same basic outcome of an unfulfilled fetch:

View attachment 1818777
Click to expand...
No, you're conflating a few things.

When you set the build_arch, MacPorts CORRECTLY realizes that you don't want to download a prebuilt i386 binary. That is good. That is working properly.

Then MacPorts tries to start a download of the source code for ncurses so it can start building it. That is good. That is working properly.

But your download doesn't work. That is not good. That is most likely not MacPorts fault -- it just asks the system CURL library to download the file. But the file is not downloading...

Does curl work? Can it download anything on that system? Does this do anything (using a real URL):

curl -O http://myserver.com/download/my/file.zip

MacPorts can properly drive the ancient libcurl.dylib that comes with Tiger PPC, so whatever libcurl.dylib is on the 10.6 PPC system probably is new enough, but I don't know if it actually is a consistent piece of software that works.

MacPorts can be built against another, newer libcurl of your own construction (I do it all the time). You configure it to use a different curl like this:

./configure --with-curlprefix=/path/to/my/curl

So we have some options if the curl on your system is not working, or not working with MacPorts.

You could build curl on 10.5 Leopard PPC, and copy it over to 10.6 PPC, in a pinch.

You can also skip MacPorts' downloading of files and do it manually yourself, by the way. MacPorts puts it's downloaded source files in a certain folder in a certain directory, and before it goes to the internet to download source, it first checks to see if it already has it. SO if you put it in the right place, having obtained it by any method you wish, then MacPorts will just use that, and skip trying to download it. Might come in handy to get bootstrapped.
 
Last edited:
  • Like
Reactions: B S Magnet
alex_free said:
I'm kind of curious about something. SM64EXLC contains an ENTIRE MacPorts installation including GCC 7.5.0 which was all compiled on Leopard, since it needs the GCC 7.5 compiler to build the SM64 decomp port. Technically you can use it as a normal MacPorts installation if you copy SM64EXLC.app to /Applications and then EXPORT PATH=/Applications/SM64EXLC.app/bin:$PATH. This might allow you to use GCC 7.5.0 on 10.6, but it would be built for Leopard, and just happen to work on Snow Leopard. I know this isn't really what you want to do, but it probably would give you GCC 7 on Snow Leopard.
Click to expand...
There is a very high probability that a software toolchain built on 10.5 Leopard PPC and then moved over to 10.6 would run. It will run on a 10.6 Intel system after all (Rosetta) and with any luck at all, would also run on a 10.6 PPC system.

You would build ld64, cctools, and gcc7.5.0 and move them ''en mass' as a consistent block to the new system. The simplest method I can think of to do this would be to install the three into a custom prefix using MacPorts (eg /opt/toolchain), and then compress and copy the entire folder, or at least all the binaries and libs, to the new system into /opt/toolchain, and with any luck at all you'd be in business. MacPorts can very easily generate a self-contained installer for such things as an available option. Something like this:

sudo port pkg cctools

gives you a cctools installer, with all needed deps included. I think with gcc7 you get everything you need at one time:

sudo port pkg gcc7

as gcc7 depends on cctools, ld64, and all the other parts.
 
  • Like
Reactions: barracuda156 and alex_free
kencu said:
There is a very high probability that a software toolchain built on 10.5 Leopard PPC and then moved over to 10.6 would run. It will run on a 10.6 Intel system after all (Rosetta) and with any luck at all, would also run on a 10.6 PPC system.

You would build ld64, cctools, and gcc7.5.0 and move them ''en mass' as a consistent block to the new system. The simplest method I can think of to do this would be to install the three into a custom prefix using MacPorts (eg /opt/toolchain), and then compress and copy the entire folder, or at least all the binaries and libs, to the new system into /opt/toolchain, and with any luck at all you'd be in business. MacPorts can very easily generate a self-contained installer for such things as an available option. Something like this:

sudo port pkg cctools

gives you a cctools installer, with all needed deps included. I think with gcc7 you get everything you need at one time:

sudo port pkg gcc7

as gcc7 depends on cctools, ld64, and all the other parts.
Click to expand...
Yea I agree, this is what SM64EXLC.app has in it:
bzip2 version 1.0.8_0
cctools version 949.0.1_0
db48 version 4.8.30_4+java
expat version 2.2.10_0
gcc7 version 7.5.0_2
gcc_select version 0.1_9
gdbm version 1.19_0
gettext version 0.19.8.1_2
glew version 2.2.0_0
gmake version 4.3_0
gmp version 6.2.1_0
gperf version 3.1_0
i686-w64-mingw32-binutils version 2.36.1_0
i686-w64-mingw32-crt version 8.0.0_0
i686-w64-mingw32-gcc-bootstrap version 10.2.0_0
i686-w64-mingw32-gcc-nothreads version 10.2.0_0
i686-w64-mingw32-headers version 8.0.0_0
isl version 0.22.1_0
ld64 version 3_3+ld64_127
ld64-127 version 127.2_14+llvm33
libedit version 20210216-3.1_0
libffi version 3.3_1
libgcc version 3.0_0
libgcc7 version 7.5.0_0
libiconv version 1.16_1
libmacho-headers version 949.0.1_0
libmpc version 1.2.1_0
libunwind-headers version 5.0.1_0
llvm-3.3 version 3.3_11
llvm_select version 2_0
lzip version 1.22_0
mpfr version 4.1.0_0
ncurses version 6.2_1
openssl version 1.1.1j_0
perl5 version 5.28.3_0+perl5_28
perl5.28 version 5.28.3_1
pkgconfig version 0.29.2_0
python3_select version 0.0_2
python39 version 3.9.2_0
python_select version 0.3_9
readline version 8.1.000_0
sqlite3 version 3.34.1_0
xz version 5.2.5_0
zlib version 1.2.11_0
 
kencu said:
you have the error here:

ld: unknown option: -no_compact_unwind
collect2: error: ld returned 1 exit status

The compiler tried to link this simple nothing program:

int
main ()
{

;
return 0;
}

and got this:

configure:3792: error: in `/opt/gcc_kencu/gcc-7.5.0/objdir/powerpc-apple-darwin10.0.0d1/libgomp':

So -- what happened here? The xgcc compiler sent an option to the linker (-no_compact_unwind) that it thought the linker should understand. But the linker did not understand it, and rather than ignoring it (being a cautious linker) it sent back an error. And the whole house of cards came crashing down.

The linker is probably /usr/bin/ld, as that is the default linker, and I'm pretty sure it's the only linker on that system. The linker probably works -- otherwise you would not have been able to build anything. It's probably a very old linker, but it's probably newer than the linkers that came with Tiger and Leopard, and gcc can make those work.

So the likely scenario then becomes that on darwin 10 (10.6) gcc has been set up to THINK that the linker /usr/bin/ld will understand that option -no_compact_unwind, because most darwin10 (10.6) systems DO have a linker that understands that option.

But you (with the bootleg system you have) have something that gcc has never seen before: a darwin10 system that comes with a /usr/bin/ld that does not understand -no_compact_unwind.

How would we fix such a thing? We could try to fix gcc somehow, to make it learn that this darwin10 system does not have a linker that understands -no_compact_unwind. We could install a newer linker somehow (one that understands -no_compact_unwind) and then tell xgcc to use that during it's bootstrapping (that is what the "bins" directory is really for -- you put symlinks in there for tools you want to force to be used :>). OR -- we could write some kind of a simple wrapper script in shell that we put in /usr/bin/ld and calls the real /usr/bin/ld (perhaps renamed to /usr/bin/ld-original) and before it calls it, it strips out that -no_compact_unwind argument somehow.

All possible. Any one of those might be done, in varying lengths of time. I would first try to get MacPorts working, and see if you can install a newer linker that way maybe. Or download the source to ld64-127 and do it manually if you're up to it. The shell script thing is also possibly not too hard; you will find lots of similar examples on the web from people who have done exactly this for other troublesome situations to use as a template.

And then there is modifying gcc itself. That is the best solution. Not likely the easiest solution for a novice -- gcc is one of the most complicated pieces of software out there, and it is written in such a way as to prevent people from messing with it. But perhaps some digging (I might start with the collect2 script) might lead to an easy way to turn off that -no_compact_unwind option.
Click to expand...

Thank you for your patience and thoroughness with this. I very much appreciate it and hope it’ll help other folks along the way.

What I’m doing presently is re-running the script, but with a twist aided by your reply here: I had compiled and installed binutils 2.23.2 earlier in the week and hadn’t thought to consider that the ld linker was a part of that. So what I’ve done, at least for this run, is moved the /user/bin/ld to the usual [name].10A96 (to help me keep track of things I’ve moved from the default 10A96 installation) and created a symlink to the newer ld-127 on /opt/local/bin to /usr/bin as “ld”. Hopefully, if your hypothesis turns out correct, this linker will be able to parse the --no_compact_unwind flag which caused the fatal error in the previous build attempt.

I’ll update with what happens this go-round when it stops, fingers crossed.
 
alex_free said:
Yea I agree, this is what SM64EXLC.app has in it:
bzip2 version 1.0.8_0
cctools version 949.0.1_0
db48 version 4.8.30_4+java
expat version 2.2.10_0
gcc7 version 7.5.0_2
gcc_select version 0.1_9
gdbm version 1.19_0
gettext version 0.19.8.1_2
glew version 2.2.0_0
gmake version 4.3_0
gmp version 6.2.1_0
gperf version 3.1_0
i686-w64-mingw32-binutils version 2.36.1_0
i686-w64-mingw32-crt version 8.0.0_0
i686-w64-mingw32-gcc-bootstrap version 10.2.0_0
i686-w64-mingw32-gcc-nothreads version 10.2.0_0
i686-w64-mingw32-headers version 8.0.0_0
isl version 0.22.1_0
ld64 version 3_3+ld64_127
ld64-127 version 127.2_14+llvm33
libedit version 20210216-3.1_0
libffi version 3.3_1
libgcc version 3.0_0
libgcc7 version 7.5.0_0
libiconv version 1.16_1
libmacho-headers version 949.0.1_0
libmpc version 1.2.1_0
libunwind-headers version 5.0.1_0
llvm-3.3 version 3.3_11
llvm_select version 2_0
lzip version 1.22_0
mpfr version 4.1.0_0
ncurses version 6.2_1
openssl version 1.1.1j_0
perl5 version 5.28.3_0+perl5_28
perl5.28 version 5.28.3_1
pkgconfig version 0.29.2_0
python3_select version 0.0_2
python39 version 3.9.2_0
python_select version 0.3_9
readline version 8.1.000_0
sqlite3 version 3.34.1_0
xz version 5.2.5_0
zlib version 1.2.11_0
Click to expand...
So that's a collection of MacPorts ports... I really do wish people would just install MacPorts, and if they want those, install them, and then they can all help with keeping MacPorts robust.

The admins at MacPorts pay attention to the user base.

If your concern is "building" things, then there is already a PPC buildbot. Ryan (macports admin) responds to demand. If 40 people all ask for the Tiger and Leopard PPC buildbots to be brought online and kept up to date, they will be. And then everyone can help us keep these ports up to date.

Having a rogue installation of a bunch of MacPorts ports might seem cool, but it is really going to be counterproductive to where we need to be in the end. Users of this should be in main fold, and helping us all contribute to the shared effort.
 
  • Like
Reactions: barracuda156
kencu said:
So that's a collection of MacPorts ports... I really do wish people would just install MacPorts, and if they want those, install them, and then they can all help with keeping MacPorts robust.

The admins at MacPorts pay attention to the user base.

If your concern is "building" things, then there is already a PPC buildbot. Ryan (macports admin) responds to demand. If 40 people all ask for the Tiger and Leopard PPC buildbots to be brought online and kept up to date, they will be. And then everyone can help us keep these ports up to date.

Having a rogue installation of a bunch of MacPorts ports might seem cool, but it is really going to be counterproductive to where we need to be in the end. Users of this should be in main fold, and helping us all contribute to the shared effort.
Click to expand...
The point of SM64EXLC is a point and click GUI for building the SM64EX decomp port on PPC. Similar things exist for Windows, but are not self contained and in fact worse. The target user base is people that don't even know what GCC is and just want to run Mario 64 natively without an emulator on Leopard PPC. I can't just distribute binaries of mario 64 because the binaries themselves contain the game assets copyrighted by Nintendo. SM64EXLC works around this by asking for a ROM file to extract just those assets and makes building SM64EX as easy as possible. Also it's not just MacPorts, it also has my Leopard SDL 2.0.6 and Panther SDL 2.0.3 forks in it and applescript to run everything as a GUI.

Otherwise I do agree with you, but SM64EXLC is not exactly the same use case. I always enable the macports stats packages on old OSes by the way.
 
  • Like
Reactions: kencu
alex_free said:
The point of SM64EXLC is a point and click GUI for build the SM64EX decomp port on PPC. Similar things exist for Windows, but are not self contained and in fact worse. The target user base is people that don't even know what GCC is and just want to run Mario 64 natively without an emulator on Leopard PPC. I can't just distribute binaries of mario 64 because the binaries themselves contain the game assets copyrighted by Nintendo. SM64EXLC works around this by asking for a ROM file to extract just those assets and makes building SM64EX as easy as possible. Also it's not just MacPorts, it also has my Leopard SDL 2.0.6 and Panther SDL 2.0.3 forks in it and applescript to run everything as a GUI.

Otherwise I do agree with you, but SM64EXLC is not exactly the same use case.
Click to expand...
Hey, did you get a working libsdl2 2.0.6 on Leopard? Best I got to was this 2.0.3 one, four years ago <https://github.com/kencu/LeopardPorts/tree/master/devel/libsdl2>. If there are some newer patches for 2.06, love to see them so I can update it.

I looked at moving this into MacPorts, but it was turned down as too confusing for users at that point in time. Of course, I was pretty much the only person keeping PPC alive at that time, so there was possibly not a good understanding of the actual demand.
 
  • Love
Reactions: alex_free
kencu said:
So that's a collection of MacPorts ports... I really do wish people would just install MacPorts, and if they want those, install them, and then they can all help with keeping MacPorts robust.

The admins at MacPorts pay attention to the user base.
Click to expand...

For what it’s worth, mpstats is the first port I install when I install/compile Macports on all of my Macs, and all of my Macs have Macports installed on then. Macports is an invaluable resource, and I hope I can get more use with it on this unicorn of a Mac environment!
 
  • Like
Reactions: alex_free and kencu
kencu said:
Hey, did you get a working libsdl2 2.0.6 on Leopard? Best I got to was this 2.0.3 one, four years ago <https://github.com/kencu/LeopardPorts/tree/master/devel/libsdl2>. If there are some newer patches for 2.06, love to see them so I can update it.

I looked at moving this into MacPorts, but it was turned down as too confusing for users at that point in time. Of course, I was pretty much the only person keeping PPC alive at that time, so there was possibly not a good understanding of the actual demand.
Click to expand...
Sure did: https://github.com/alex-free/leopard_sdl2.0.6 (works with the latest FFplay and SM64EX). Also I ported SDL 2.0.3 to Mac OS X 10.3.9, I use that with PowerPC Media Center 7 which uses the latest FFplay media player: https://github.com/alex-free/panther_sdl2 https://alex-free.github.io/ppcmc7/

SDL 2.0.6 is actually required for SM64EX's SDL2 support. Both Panther_SDL2.0.3 and Leopard_SDL2.0.6 should work on Intel (Panther_SDL2 obviously on Intel Tiger and above only). Feel free to ask any questions or direct me into how I can add this to something like tiger/leopard ports.
 
  • Like
Reactions: barracuda156 and kencu
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back