gcc10 not building on Tiger due to "unwind.h" not being found during build.

[kencu]

Discussion moved from:

https://github.com/macports/macports-ports/pull/13995

[iains]

my rebuild of the standard build of gcc 10.3.0 using --with-dwarf2 failed again on Tiger with the dreaded "bootstrap comparison failure", so I'm out of this for the time being.

Please would you tell me the output of cat .bad_compare in the build directory? (if it's 100s of files not important .. but if just one or two it might be relevant)

that is with: ld64-97 (unpatched?) cctool949 (also unpatched?)

Glad to see you are helping Iain get his patchset "Tiger-ready".

heh

[iains]

my rebuild of the standard build of gcc 10.3.0 using --with-dwarf2 failed again on Tiger with the dreaded "bootstrap comparison failure", so I'm out of this for the time being.

Please would you tell me the output of cat .bad_compare in the build directory? (if it's 100s of files not important .. but if just one or two it might be relevant)

that is with: ld64-97 (unpatched?) cctool949 (also unpatched?)

In particular, using a new cctools like that kinda implies that it calls clang -cc1as to be the assembler by default - has that been worked around?

[barracuda156]

@iains Thank you! So to build on Tiger PPC I just change the arch in the line to:

--prefix=... --build=powerpc-apple-darwin8 --with-dwarf2 --disable-multilib --with-ld=/opt/iains/powerpc-apple-darwin8/cct-698-ld64-85-2/bin/ld --with-as=/opt/iains/powerpc-apple-darwin8/cct-698-ld64-85-2/bin/as --enable-languages=all --with-cpu=generic

Does it benefit to specify cpu instead of genetic to G4 or 970?

And re cctools, are those just stock ones from Xcode 3.1.4? I didn't think they install on Tiger tbh, but didn't think to try. Will do.

[iains]

@iains Thank you! So to build on Tiger PPC I just change the arch in the line to:

--prefix=... --build=powerpc-apple-darwin8 --with-dwarf2 --disable-multilib --with-ld=/opt/iains/powerpc-apple-darwin8/cct-698-ld64-85-2/bin/ld --with-as=/opt/iains/powerpc-apple-darwin8/cct-698-ld64-85-2/bin/as --enable-languages=all --with-cpu=generic

Does it benefit to specify cpu instead of genetic to G4 or 970?

generic only applies to i686 - there should be no need to use --with-cpu on powerpc.

And re cctools, are those just stock ones from Xcode 3.1.4? I didn't think they install on Tiger tbh, but didn't think to try. Will do.

I built them from source on Tiger ..

[kencu]

for the purposes of macports, we’re either going to use the system’s cctools/ld64, or MacPorts cctools/ld64.

MacPorts assembler will punt to the newest installed clang it finds, but exactly how and when that happens is not quite as deterministic as Iain would like it to be. The rules are logical, but not trivially simple.

On PPC, where I am today here, it never finds a new enough clang installed, so it always uses the internal assembler, which is 949 with Jeremy’s and my additional patches. Running the test suite an cctools is not trivial, so our cctools could have unexplored issues. I do recall running the tests when I updated it last.

I doubt anyone else on Macports except perhaps Jeremy would have ever tried it, though.

[kencu]

Iain, I invite you once again to take over the entire MacPorts toolchain if you want to. I know you’re too busy, but you could run it all and everyone who uses an older system would benefit.

On newer systems, macports cctools and ld64 ports are simple symlinks to the system tools, BTW.

[iains]

Were there a large number of objects with compare fails, or just one or two?

for the purposes of macports, we’re either going to use the system’s cctools/ld64, or MacPorts cctools/ld64.

Although there are multiple choices for "Mac ports cctools/ld64", or have I misunderstood?

MacPorts assembler will punt to the newest installed clang it finds, but exactly how and when that happens is not quite as deterministic as Iain would like it to be. The rules are logical, but not trivially simple.

On PPC, where I am today here, it never finds a new enough clang installed, so it always uses the internal assembler, which is 949 with Jeremy’s and my additional patches. Running the test suite an cctools is not trivial, so our cctools could have unexplored issues. I do recall running the tests when I updated it last.

Hard to know where the problem is creeping in ..

[iains]

Iain, I invite you once again to take over the entire MacPorts toolchain if you want to. I know you’re too busy, but you could run it all and everyone who uses an older system would benefit.

yeah $dayjob + actually trying to make the toolchain go forward uses up more than 24h / day - I cannot offer to do more than try to answer questions - and / or offer sets of useful back ports ...

On newer systems, macports cctools and ld64 ports are simple symlinks to the system tools, BTW.

OK (these are links to /Library/Developer/CommandLineTools/usr/bin/.... I guess?)

[kencu]

Although there are multiple choices for "Mac ports cctools/ld64", or have I misunderstood?

Each system is set to use the same cctools 949 until the systems tools are newer than 949.

For ld64, each system uses the newest one it is capable of building from system roots.

10.4 => ld64-97 10.5 - 10.6 => ld64-127 10.7 - 10.11 => ld64-274 10.12 - 10.13 => ld64-450 10.14 and newer => xcode (via xcrun

The ld64 127 and up are linked against the newest llvm that the system roots can build.

I mentioned symlinks in the ld64-xcode variant, but in fact it uses xcrun if available via a shell script, and just calls into /usr/bin/ld if there is no xcrun, apologies:

https://github.com/macports/macports-ports/blob/master/devel/ld64/files/ld-xcode

cctools does something similar but a bit different, of course:

https://github.com/macports/macports-ports/blob/a49fb8d20c3de75ccdc9d3caeeb9c87abfeaa8b3/devel/cctools/Portfile#L147

[kencu]

that current ld64 plan is not really to my liking, BTW -- 10.6 can build and use at least ld64-450, and that is what I use.

But bootstrapping to ld64-450 on 10.6 is a manual step...so not in MacPorts as yet.

[kencu]

my rebuild of the standard build of gcc 10.3.0 using --with-dwarf2 failed again on Tiger with the dreaded "bootstrap comparison failure", so I'm out of this for the time being.

Please would you tell me the output of cat .bad_compare in the build directory? (if it's 100s of files not important .. but if just one or two it might be relevant)

$ cat .bad_compare
gcc/host-darwin.o differs
powerpc-apple-darwin8/libstdc++-v3/src/.libs/libstdc++.6.dylib-master.o differs

../gcc-10.3.0/configure --prefix=/opt/gcc/gcc10 --build=powerpc-apple-darwin8 --with-dwarf2 --without-zstd --enable-languages=all CC=/opt/local/bin/gcc-apple-4.2 CXX=/opt/local/bin/g++-apple-4.2 > config.txt && time nice make -j4 >b.txt 2>e.txt

b.txt config.txt e.txt

[kencu]

That is the unpatched, raw, original gcc 10.3.0 there

[iains]

that current ld64 plan is not really to my liking, BTW -- 10.6 can build and use at least ld64-450, and that is what I use.

presumably, via some intermediate step - since (unless patched) ld64 > 128 or so needs C++11.

My intent is to try to consolidate the patches for known ld64 issues onto ld64-236-3 which can be made to build using gcc-4.2.1 + libstdc++ at least up to macOS 10.8 without requiring too many c++11 related changes - but I will post on the xtools repo about that, when the time comes (when I have a few seconds to collate the known issues and fixes).

Likewise for 10.9 - 10.13 (where we now need libtapi and much more extensive C++11 support) .. and so on.

The idea is to try and reduce the number of permutations - at the cost of more patches per permutation - but I think that is the way to minimise work.

[iains]

That is the unpatched, raw, original gcc 10.3.0 there

the output of cat .bad_compare in the build dir is what's interesting in terms of the number of failed comparisons.

[kencu]

Indeed. I build ld64-127, then clang-9.0, then ld64-450 and overwrite manually the ld64-127 with ld64-450.

These are built-in macports steps, just not automatic to do, and need a manual step.

[kencu]

That is the unpatched, raw, original gcc 10.3.0 there

the output of cat .bad_compare in the build dir is what's interesting in terms of the number of failed comparisons.

I presume you saw that just above. Thanks for looking!

Yeah - it that was on a local machine I might be tempted to see where the mismatches came from for such a small number.

My guess is that gcc/host-darwin.o differs is a result of the inability to strip the binaries properly with the PCH memory

this one: powerpc-apple-darwin8/libstdc++-v3/src/.libs/libstdc++.6.dylib-master.o differs is not one i've seen as a solitary output.

[iains]

(https://github.com/iains/gcc-10-branch/files/8171041/config.txt) e.txt

Sadly, this shows the issue with the assembler not exiting with "1" on bad command line parms. so one cannot be confident that the configuration is reliable.

[kencu]

So we will have to use the newer macports cctools to build gcc10 on Tiger.

I was hoping to avoid that, but it's unavoidable anyway as apple-gcc42 uses them.

[iains]

So we will have to use the newer macports cctools to build gcc10 on Tiger.

or someone needs to fix up gcc/configure.ac to cater for that case (but IMO it's borderline to add cruft for 10.4 at this stage)

I was hoping to avoid that, but it's unavoidable anyway as apple-gcc42 uses them.

Well .. once i established that ld64-62 was no-go - I moved to the next set as a set, because of the load commands concerns.

[iains]

That is the unpatched, raw, original gcc 10.3.0 there

the output of cat .bad_compare in the build dir is what's interesting in terms of the number of failed comparisons.

I presume you saw that just above. Thanks for looking!

oops I accidentally edited your post instead of replying....

Yeah - it that was on a local machine I might be tempted to see where the mismatches came from for such a small number. My guess is that gcc/host-darwin.o differs is a result of the inability to strip the binaries properly with the PCH memory

this one:

powerpc-apple-darwin8/libstdc++-v3/src/.libs/libstdc++.6.dylib-master.o differs is not one i've seen as a solitary output.

[barracuda156]

The ld64 127 and up are linked against the newest llvm that the system roots can build.

@kencu Is this done in some non-trivial way? For me ld64 links against llvm-3.3 and llvm-3.4 but does not want to link against anything newer. At the same time all llvm versions through llvm-5.0 build in Macports for PowerPC. (I have built 3.5, 3.6, 3.9, 4.0 and 5.0.)

[evanmiller]

Sadly, this shows the issue with the assembler not exiting with "1" on bad command line parms. so one cannot be confident that the configuration is reliable.

As a small consolation: at least -mmacosx-version-min is harmless, at least when -o appears before it. It is interpreted as -m -m -a -c -o=sx-version-min. m, a, and c are ignored, then everything after the o is interpreted as the output destination (and ignored when preceded by another -o). Haven't inspected the other optional flags, though.

[kencu]

The ld64 127 and up are linked against the newest llvm that the system roots can build.

@kencu Is this done in some non-trivial way? For me ld64 links against llvm-3.3 and llvm-3.4 but does not want to link against anything newer.

To get bootstrapped, ld64 defaults to the newest llvm your system toolchain can build. The code is all in the ld64 Portfile, so it's neither magical nor secretive.

To force a newer llvm is generally trivial enough:

$ port info ld64-latest
ld64-latest @450.3 (devel)
Variants:             llvm50, llvm60, llvm70, llvm80, [+]llvm90, llvmdev

sudo port -v install ld64-latest +llvm90 if you need to force it.

I haven't looked in a while, but probably we could use some newer llvm now -- if anyone gets excited enough about it.

[barracuda156]

To get bootstrapped, ld64 defaults to the newest llvm your system toolchain can build. The code is all in the ld64 Portfile, so it's neither magical nor secretive.

To force a newer llvm is generally trivial enough:

@kencu I tried to rebuild ld64-127 with +llvm… but it did not want to pick anything but 3.3 or 3.4. It is quite likely however that I did not tweak port file appropriately (though llvm-5.0 is active in Macports and should link). I am less sure about removed versions, which I asked once in a ticket about: https://trac.macports.org/ticket/64600 (you were not enthusiastic about it, so I leave a link just in case for others). I have dug out removed port files and have built 3.6, 3.8, 3.9 and 4.0 (linking with libstdc++).

By the way, in other post you said that you had llvm-5.0 on PPC, but it produced broken code. LTO should work fine still?

I haven't looked in a while, but probably we could use some newer llvm now -- if anyone gets excited enough about it.

If there is some benefit to be had, it probably makes sense: more often than not newer versions of compilers work better. It is still unclear for me why Macports retained two archaic versions of llvm while removing relatively newer ones that still build easily.

[kencu]

To get bootstrapped, ld64 defaults to the newest llvm your system toolchain can build. The code is all in the ld64 Portfile, so it's neither magical nor secretive. To force a newer llvm is generally trivial enough:

@kencu I tried to rebuild ld64-127 with +llvm… but it did not want to pick anything but 3.3 or 3.4.

You would have to force it to the available llvm options by forcing off the default variant, whatever it is, with a " - " and forcing on the variant you want, whatever it is , with a " + ".

It is quite likely however that I did not tweak port file appropriately (though llvm-5.0 is active in Macports and should link).

Not sure what you tried to do, but you should just tweak variants for now, not touch the portfile.

I am less sure about removed versions, which I asked once in a ticket about: https://trac.macports.org/ticket/64600 (you were not enthusiastic about it, so I leave a link just in case for others). I have dug out removed port files and have built 3.6, 3.8, 3.9 and 4.0 (linking with libstdc++).

All of that is unsupported in macports, references to them removed from base and from all the portfiles and portgroups and ports where such things matter.

You can resuscitate stuff like that, but it can be hard to do it right. You might see clang-3.8 in my TigerPorts repo, fully resuscitated and was very useful on Tiger Intel when I cared about Tiger Intel.

By the way, in other post you said that you had llvm-5.0 on PPC, but it produced broken code. LTO should work fine still?

I actually don't know the answer to that, because although I have built llvm 1,000,000 times and also fixed ld64 and other ports like libtapi to build against llvm, I have never read deeply what exactly llvm does for ld64 to allow LTO to work.

I haven't looked in a while, but probably we could use some newer llvm now -- if anyone gets excited enough about it.

If there is some benefit to be had, it probably makes sense: more often than not newer versions of compilers work better.

Yup.

It is still unclear for me why Macports retained two archaic versions of llvm while removing relatively newer ones that still build easily.

only for bootstrapping.

Once gcc10-bootstrap can build clang11-bootstrap and then that is used to bootstrap the rest, every llvm and clang before about clang-13 and llvm-13 are ripe to be removed from macports completely.

And good riddance! Bootstrapping is a pain in the A**S.

[kencu]

My usual Ubuntu system (that runs great on a 2006 MacBook 2,1 by the way) bootstraps right into clang-13 / llvm-13 using gcc11 to do it.

That is the plan for macports, at some point.

(PS: my PowerPC systems, that run on ancient 2004-era PowerPC systems from Apple, do the same).

[iains]

this thread is drifting onto multiple problems - please move them to new threads if they are pertinent to this repo.

As for the original issue, I think I have suitable fixes for the missing dependency and the missing darwin-fallback.o. I need to test that on master, apply it there and then back port.

[iains]

however, JFTR:

There is no point (0) in ld64 having LTO support unless you have a working clang/llvm capable of correct code-gen driving it.

My xtoolsbuilds explicitly allow for building a starting toolchain without LTO support in ld64 (and otool) to break the dependency loops.

GCC's LTO does not require libLTO.dylib from LLVM clang's LTO does.

As mentioned several times, clang is not yet working on powerpc-darwin, so there's no point in bothering with these difficulties there (yet), unless you want to use it as a cross-compiler for x86.

LLVM LTO (and GCC's although a bit less, maybe) is very heavy on (especially memory) resources, so you'd better have lots of RAM on an old box if you really intend to use it.

[barracuda156]

There is no point (0) in ld64 having LTO support unless you have a working clang/llvm capable of correct code-gen driving it. GCC's LTO does not require libLTO.dylib from LLVM clang's LTO does. As mentioned several times, clang is not yet working on powerpc-darwin, so there's no point in bothering with these difficulties there (yet), unless you want to use it as a cross-compiler for x86.

Thank you for clarification!

The problem of llvm remains apparently unavoidable on Leopard though, since Macports wants some version of llvm to build a linker, and alternative choice of +ld64_xcode is broken. On 10.6 which is restricted to ppc32 problem does not arise. However ancient llvm fail to build for ppc64 (not only ppc+ppc64, but just ppc64 too): https://github.com/iains/darwin-toolchains-start-here/discussions/29 (and yeah, let’s move llvm topic to there, you are right).

LLVM LTO (and GCC's although a bit less, maybe) is very heavy on (especially memory) resources, so you'd better have lots of RAM on an old box if you really intend to use it.

Quad G5 16 GB RAM

[evanmiller]

Yeah - it that was on a local machine I might be tempted to see where the mismatches came from for such a small number. My guess is that gcc/host-darwin.o differs is a result of the inability to strip the binaries properly with the PCH memory

this one:

powerpc-apple-darwin8/libstdc++-v3/src/.libs/libstdc++.6.dylib-master.o differs is not one i've seen as a solitary output.

I (finally) get a bootstrap comparison failure building on Tiger via MacPorts, which is using the system assembler:

:info:build warning: gcc/cc1obj-checksum.o differs
:info:build warning: gcc/cc1objplus-checksum.o differs
:info:build Bootstrap comparison failure!
:info:build gcc/host-darwin.o differs
:info:build powerpc-apple-darwin8.11.0/libstdc++-v3/src/.libs/libstdc++.6.dylib-master.o differs
:info:build make[2]: *** [compare] Error 1

Let me know if there's any other information I can provide on this machine – though a full recompile takes ~3 days.

[iains]

Yeah - it that was on a local machine I might be tempted to see where the mismatches came from for such a small number. My guess is that gcc/host-darwin.o differs is a result of the inability to strip the binaries properly with the PCH memory this one: powerpc-apple-darwin8/libstdc++-v3/src/.libs/libstdc++.6.dylib-master.o differs is not one i've seen as a solitary output.

I (finally) get a bootstrap comparison failure building on Tiger via MacPorts, which is using the system assembler:

Right so you've replicated @kencu 's results (which is great, consistent bugs can be fixed).

So what exactly are the versions of cctools and ld(64?) you are using ... ISTR that 10.4 will default to using the "classic" linker, unless you specify ld64?

I understand the time to build problem :/ one reason I have stopped regular darwin8 testing.

[evanmiller]

So what exactly are the versions of cctools and ld(64?) you are using ... ISTR that 10.4 will default to using the "classic" linker, unless you specify ld64?

The ports used in the build are:

apple-gcc42 5666.3_16 ld64-97 97.17_9 cctools 949.0.1_1

[kencu]

I tried to use the --with-as and --with-ld arguments to force the macports' ones, but this failed too.

I think this is why, last year, I symlinked in the exact tools I wanted to use into a "bins" directory and forced that onto the front of the path.

There are other tricks gcc uses to force certain toolchains, but those are mostly not for mortals to use.

[kencu]

and you can again see why MacPorts has been on gcc7 for older systems all these years ;>

[iains]

I tried to use the --with-as and --with-ld arguments to force the macports' ones, but this failed too.

That --with-as=/path/to/as and the ld equivalent should trump everything (and now I have also added --with-dsymutil= which was somehow omitted when the tool was added).

edit: usually, the problem is the opposite one - someone configures with these options and then finds that other mechanisms to use a different as, ld etc. no longer work ;)

The only reason I can think of that those configure args would fail to DTRT would be if the tools were not actually present at the paths specified .. .. IFF you can find a repeatable failure then I'd like to see it (since it would affect any version of GCC / macOS - not limited to vintage oddities).

[kencu]

I know. I was planning on reporting how well it worked myself. Sigh.

pmg5:/Users/Shared/gcc/buildgcc user$ rm -rf ./*
pmg5:/Users/Shared/gcc/buildgcc user$ ls

$ ../gcc-10.3.0/configure --prefix=/opt/gcc/gcc10 --build=powerpc-apple-darwin8 --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-dwarf2 --without-zstd --enable-languages=all CC=/opt/local/bin/gcc-apple-4.2 CXX=/opt/local/bin/g++-apple-4.2 > config.txt && time nice make -j4 >b.txt 2>e.txt
configure: WARNING: using in-tree isl, disabling version check
configure: WARNING: GNAT is required to build ada
configure: WARNING: brig not supported for this target
configure: WARNING: d not supported for this target
configure: WARNING: go not supported for this target
configure: WARNING: --enable-host-shared required to build jit
*** This configuration is not supported in the following subdirectories:
     target-libsanitizer target-libvtv target-libphobos target-libgo gnattools gotools target-libada target-libhsail-rt target-zlib target-libffi target-liboffloadmic
    (Any other directories should still work fine.)
rm: conftest.dSYM: is a directory

real    709m23.984s
user    1218m31.537s
sys     99m5.183s

$ ls -la /opt/local/bin/as
-r-xr-xr-x   1 root  admin  27080 Jan 12 12:45 /opt/local/bin/as
$ ls -la /opt/local/bin/ld
lrwxrwxrwx   1 root  admin  5 Jan 12 12:42 /opt/local/bin/ld -> ld-97
$ ls -la /opt/local/bin/ld-97
-rwxr-xr-x   1 root  admin  3093136 Jan 12 12:42 /opt/local/bin/ld-97

b.txt config.txt e.txt

[kencu]

maybe that ld symlink messes things up? We've had that for a decade or more, since Jeremy set this all up...

[iains]

maybe that ld symlink messes things up? We've had that for a decade or more, since Jeremy set this all up...

perhaps. first what is the output of gcc hello.c -save-temps -v -Wl,-v (this should establish which tools are actually invoked by the compiler)

We should really try to keep dsymutil in step ... but that's more tricky until one can build a working LLVM dsymutil.

[kencu]

$ printenv
TERM_PROGRAM=Apple_Terminal
TERM=xterm-color
SHELL=/bin/bash
TERM_PROGRAM_VERSION=133-1
OLDPWD=/Users/Shared/gcc
USER=username
__CF_USER_TEXT_ENCODING=0x1F5:0:0
PATH=/Users/Shared/gcc/bins:/bin:/sbin:/usr/bin:/usr/sbin
PWD=/Users/Shared/gcc/buildgcc
SHLVL=1
HOME=/Users/username
LOGNAME=usersname
DISPLAY=:0
SECURITYSESSIONID=617840
_=/usr/bin/printenv
pmg5:/Users/Shared/gcc/buildgcc username$ ls /Users/Shared/gcc/bins
make
pmg5:/Users/Shared/gcc/buildgcc username$ /Users/Shared/gcc/bins/make -v
GNU Make 3.81
Copyright (C) 2006  Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.

This program built for powerpc-apple-darwin8.11.0

[kencu]

$ /opt/local/bin/gcc-apple-4.2 hello.c -save-temps -v -Wl,-v
Using built-in specs.
Target: powerpc-apple-darwin8
Configured with: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_apple-gcc42/apple-gcc42/work/objroot/src/configure --disable-checking --enable-werror --prefix=/opt/local --mandir=/opt/local/share/man --enable-languages=c,c++,objc,obj-c++ --libexecdir=/opt/local/libexec/apple-gcc42 --libdir=/opt/local/lib/apple-gcc42 --includedir=/opt/local/include/apple-gcc42 --program-suffix=-apple-4.2 --with-system-zlib --disable-nls --with-slibdir=/usr/lib --build=powerpc-apple-darwin8 --with-gxx-include-dir=/usr/include/c++/4.0.0 --host=powerpc-apple-darwin8 --target=powerpc-apple-darwin8
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5666) (dot 3) (MacPorts apple-gcc42 5666.3_16)
 /opt/local/libexec/apple-gcc42/gcc/powerpc-apple-darwin8/4.2.1/cc1 -E -quiet -v -D__DYNAMIC__ hello.c -fPIC -mmacosx-version-min=10.4 -fpch-preprocess -o hello.i
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/opt/local/lib/apple-gcc42/gcc/powerpc-apple-darwin8/4.2.1/../../../../powerpc-apple-darwin8/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/local/include
 /opt/local/lib/apple-gcc42/gcc/powerpc-apple-darwin8/4.2.1/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 /opt/local/libexec/apple-gcc42/gcc/powerpc-apple-darwin8/4.2.1/cc1 -fpreprocessed hello.i -fPIC -quiet -dumpbase hello.c -mmacosx-version-min=10.4 -auxbase hello -version -o hello.s
GNU C version 4.2.1 (Apple Inc. build 5666) (dot 3) (MacPorts apple-gcc42 5666.3_16) (powerpc-apple-darwin8)
    compiled by GNU C version 4.2.1 (Apple Inc. build 5666) (dot 3) (MacPorts apple-gcc42 5666.3_16).
GGC heuristics: --param ggc-min-expand=150 --param ggc-min-heapsize=131072
Compiler executable checksum: 9babc7b9a63e00bc356afd7c801b3efe
 /opt/local/libexec/apple-gcc42/gcc/powerpc-apple-darwin8/4.2.1/as -arch ppc -o hello.o hello.s
 /opt/local/libexec/apple-gcc42/gcc/powerpc-apple-darwin8/4.2.1/collect2 -dynamic -arch ppc -macosx_version_min 10.4 -weak_reference_mismatches non-weak -o a.out -lcrt1.o -L/opt/local/lib/apple-gcc42/gcc/powerpc-apple-darwin8/4.2.1 -L/opt/local/lib/apple-gcc42/gcc/powerpc-apple-darwin8/4.2.1/../../.. hello.o -v -lgcc_s.10.4 -lgcc -lSystemStubs -lSystem
collect2 version 4.2.1 (Apple Inc. build 5666) (dot 3) (MacPorts apple-gcc42 5666.3_16) (Darwin/PowerPC)
/opt/local/libexec/apple-gcc42/gcc/powerpc-apple-darwin8/4.2.1/ld -dynamic -arch ppc -macosx_version_min 10.4 -weak_reference_mismatches non-weak -o a.out -lcrt1.o -L/opt/local/lib/apple-gcc42/gcc/powerpc-apple-darwin8/4.2.1 -L/opt/local/lib/apple-gcc42/gcc/powerpc-apple-darwin8/4.2.1/../../.. hello.o -v -lgcc_s.10.4 -lgcc -lSystemStubs -lSystem
@(#)PROGRAM:ld  PROJECT:ld64-97.17
configured to support archs: i386 x86_64 ppc ppc64 armv6 armv7
Library search paths:
    /opt/local/lib/apple-gcc42/gcc/powerpc-apple-darwin8/4.2.1
    /opt/local/lib/apple-gcc42
    /usr/lib
    /usr/local/lib
Framework search paths:
    /Library/Frameworks/
    /System/Library/Frameworks/

[kencu]

$ ls -la /opt/local/libexec/apple-gcc42/gcc/powerpc-apple-darwin8/4.2.1/as
lrwxrwxrwx   1 root  admin  21 Jan 12 13:39 /opt/local/libexec/apple-gcc42/gcc/powerpc-apple-darwin8/4.2.1/as -> ../../../../../bin/as

$ ls -la /opt/local/libexec/apple-gcc42/gcc/powerpc-apple-darwin8/4.2.1/ld 
lrwxrwxrwx   1 root  admin  21 Jan 12 13:39 /opt/local/libexec/apple-gcc42/gcc/powerpc-apple-darwin8/4.2.1/ld -> ../../../../../bin/ld

[iains]

so that's the bootstrap compiler you used. what is the output for the 10.3 one you built? if you cannot install it - because of the compare fail:

./bin/xgcc -Bgcc hello.c -v -Wl,-v

incidentally, you can continue from a compare error by doing: touch compare and then reissuing the make command to build the compiler. Of course, doing that implies you decided that the compare errors were not significant .. which is not something would do outside a testing scenario.

[iains]

but I notice the bootstrap compiler does not use --with-as/ld= so it is possible for that compiler to have its supporting tools changed, by the other mechanisms you referred to.

[kencu]

My gcc-foo is failing. I assume I must do an additional something:

$ find . | grep xgcc
./stage1-gcc/xgcc
./stage2-gcc/xgcc
./stage3-gcc/xgcc

pmg5:/Users/Shared/gcc/buildgcc user$ ./stage3-gcc/xgcc  -Bgcc ../hello.c -v -Wl,-v
Using built-in specs.
COLLECT_GCC=./stage3-gcc/xgcc
Target: powerpc-apple-darwin8
Configured with: ../gcc-10.3.0/configure --prefix=/opt/gcc/gcc10 --build=powerpc-apple-darwin8 --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-dwarf2 --without-zstd --enable-languages=all CC=/opt/local/bin/gcc-apple-4.2 CXX=/opt/local/bin/g++-apple-4.2
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-B' 'gcc' '-v' '-mmacosx-version-min=10.4' '-asm_macosx_version_min=10.4'
 cc1 -quiet -v -iprefix /Users/Shared/gcc/buildgcc/stage3-gcc/../lib/gcc/powerpc-apple-darwin8/10.3.0/ -D__DYNAMIC__ ../hello.c -fPIC -quiet -dumpbase hello.c -mmacosx-version-min=10.4 -auxbase hello -version -o /var/tmp//ccLCnhcM.s
xgcc: error trying to exec 'cc1': execvp: No such file or directory

[iains]

My gcc-foo is failing. I assume I must do an additional something:

$ find . | grep xgcc
./stage1-gcc/xgcc
./stage2-gcc/xgcc
./stage3-gcc/xgcc

yeah because you are stopped after the compare fail.

./stage3-gcc/xgcc -Bstage3-gcc hello.c -v -Wl,-v

will do for now (it is possible to unstage the comparisons phase - as would be done with the touch compare and restart).

[kencu]

$ ./stage3-gcc/xgcc  -Bstage3-gcc ../hello.c -v -Wl,-v
Reading specs from stage3-gcc/specs
COLLECT_GCC=./stage3-gcc/xgcc
COLLECT_LTO_WRAPPER=stage3-gcc/lto-wrapper
Target: powerpc-apple-darwin8
Configured with: ../gcc-10.3.0/configure --prefix=/opt/gcc/gcc10 --build=powerpc-apple-darwin8 --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-dwarf2 --without-zstd --enable-languages=all CC=/opt/local/bin/gcc-apple-4.2 CXX=/opt/local/bin/g++-apple-4.2
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-B' 'stage3-gcc' '-v' '-mmacosx-version-min=10.4' '-asm_macosx_version_min=10.4'
 stage3-gcc/cc1 -quiet -v -iprefix /Users/Shared/gcc/buildgcc/stage3-gcc/../lib/gcc/powerpc-apple-darwin8/10.3.0/ -isystem stage3-gcc/include -isystem stage3-gcc/include-fixed -D__DYNAMIC__ ../hello.c -fPIC -quiet -dumpbase hello.c -mmacosx-version-min=10.4 -auxbase hello -version -o /var/tmp//ccZaBuPa.s
GNU C17 (GCC) version 10.3.0 (powerpc-apple-darwin8)
    compiled by GNU C version 10.3.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/Users/Shared/gcc/buildgcc/stage3-gcc/../lib/gcc/powerpc-apple-darwin8/10.3.0/include"
ignoring nonexistent directory "/Users/Shared/gcc/buildgcc/stage3-gcc/../lib/gcc/powerpc-apple-darwin8/10.3.0/include-fixed"
ignoring nonexistent directory "/Users/Shared/gcc/buildgcc/stage3-gcc/../lib/gcc/powerpc-apple-darwin8/10.3.0/../../../../powerpc-apple-darwin8/include"
ignoring nonexistent directory "/Users/Shared/gcc/buildgcc/stage3-gcc/../lib/gcc/../../lib/gcc/powerpc-apple-darwin8/10.3.0/include"
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/Users/Shared/gcc/buildgcc/stage3-gcc/../lib/gcc/../../include"
ignoring nonexistent directory "/Users/Shared/gcc/buildgcc/stage3-gcc/../lib/gcc/../../lib/gcc/powerpc-apple-darwin8/10.3.0/include-fixed"
ignoring nonexistent directory "/Users/Shared/gcc/buildgcc/stage3-gcc/../lib/gcc/../../lib/gcc/powerpc-apple-darwin8/10.3.0/../../../../powerpc-apple-darwin8/include"
#include "..." search starts here:
#include <...> search starts here:
 stage3-gcc/include
 stage3-gcc/include-fixed
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
GNU C17 (GCC) version 10.3.0 (powerpc-apple-darwin8)
    compiled by GNU C version 10.3.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

[iains]

oops, mea culpa - I forgot the -save-temps so we don't see the lines we care about.

[kencu]

$ ./stage3-gcc/xgcc  -Bstage3-gcc ../hello.c -save-temps  -v -Wl,-v
Reading specs from stage3-gcc/specs
COLLECT_GCC=./stage3-gcc/xgcc
COLLECT_LTO_WRAPPER=stage3-gcc/lto-wrapper
Target: powerpc-apple-darwin8
Configured with: ../gcc-10.3.0/configure --prefix=/opt/gcc/gcc10 --build=powerpc-apple-darwin8 --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-dwarf2 --without-zstd --enable-languages=all CC=/opt/local/bin/gcc-apple-4.2 CXX=/opt/local/bin/g++-apple-4.2
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.3.0 (GCC) 
COLLECT_GCC_OPTIONS='-B' 'stage3-gcc' '-save-temps' '-v' '-mmacosx-version-min=10.4' '-asm_macosx_version_min=10.4'
 stage3-gcc/cc1 -E -quiet -v -iprefix /Users/Shared/gcc/buildgcc/stage3-gcc/../lib/gcc/powerpc-apple-darwin8/10.3.0/ -isystem stage3-gcc/include -isystem stage3-gcc/include-fixed -D__DYNAMIC__ ../hello.c -fPIC -mmacosx-version-min=10.4 -fpch-preprocess -o hello.i
ignoring nonexistent directory "/Users/Shared/gcc/buildgcc/stage3-gcc/../lib/gcc/powerpc-apple-darwin8/10.3.0/include"
ignoring nonexistent directory "/Users/Shared/gcc/buildgcc/stage3-gcc/../lib/gcc/powerpc-apple-darwin8/10.3.0/include-fixed"
ignoring nonexistent directory "/Users/Shared/gcc/buildgcc/stage3-gcc/../lib/gcc/powerpc-apple-darwin8/10.3.0/../../../../powerpc-apple-darwin8/include"
ignoring nonexistent directory "/Users/Shared/gcc/buildgcc/stage3-gcc/../lib/gcc/../../lib/gcc/powerpc-apple-darwin8/10.3.0/include"
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/Users/Shared/gcc/buildgcc/stage3-gcc/../lib/gcc/../../include"
ignoring nonexistent directory "/Users/Shared/gcc/buildgcc/stage3-gcc/../lib/gcc/../../lib/gcc/powerpc-apple-darwin8/10.3.0/include-fixed"
ignoring nonexistent directory "/Users/Shared/gcc/buildgcc/stage3-gcc/../lib/gcc/../../lib/gcc/powerpc-apple-darwin8/10.3.0/../../../../powerpc-apple-darwin8/include"
#include "..." search starts here:
#include <...> search starts here:
 stage3-gcc/include
 stage3-gcc/include-fixed
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
COLLECT_GCC_OPTIONS='-B' 'stage3-gcc' '-save-temps' '-v' '-mmacosx-version-min=10.4' '-asm_macosx_version_min=10.4'
 stage3-gcc/cc1 -fpreprocessed hello.i -fPIC -quiet -dumpbase hello.c -mmacosx-version-min=10.4 -auxbase hello -version -o hello.s
GNU C17 (GCC) version 10.3.0 (powerpc-apple-darwin8)
    compiled by GNU C version 10.3.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 10.3.0 (powerpc-apple-darwin8)
    compiled by GNU C version 10.3.0, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: df6e0f0ecb63fed7812ab44ffd4ef2fb
COLLECT_GCC_OPTIONS='-B' 'stage3-gcc' '-save-temps' '-v' '-mmacosx-version-min=10.4' 
 /opt/local/bin/as -v -arch ppc -o hello.o hello.s
Apple Inc version cctools-localbuild, GNU assembler version 1.38
COMPILER_PATH=stage3-gcc/
LIBRARY_PATH=stage3-gcc/
COLLECT_GCC_OPTIONS='-B' 'stage3-gcc' '-save-temps' '-v' '-mmacosx-version-min=10.4' 
 stage3-gcc/collect2 -dynamic -arch ppc -macosx_version_min 10.4 -weak_reference_mismatches non-weak -o a.out -lcrt1.o -Lstage3-gcc hello.o -v -lgcc_s.10.4 -lgcc_ext.10.4 -lgcc -lSystemStubs -lSystem -lef_ppc -v
collect2 version 10.3.0
/opt/local/bin/ld -dynamic -arch ppc -macosx_version_min 10.4 -weak_reference_mismatches non-weak -o a.out -lcrt1.o -Lstage3-gcc hello.o -v -lgcc_s.10.4 -lgcc_ext.10.4 -lgcc -lSystemStubs -lSystem -lef_ppc -v
@(#)PROGRAM:ld  PROJECT:ld64-97.17
configured to support archs: i386 x86_64 ppc ppc64 armv6 armv7
@(#)PROGRAM:ld  PROJECT:ld64-97.17
configured to support archs: i386 x86_64 ppc ppc64 armv6 armv7
Library search paths:
    stage3-gcc
    /usr/lib
    /usr/local/lib
Framework search paths:
    /Library/Frameworks/
    /System/Library/Frameworks/

[iains]

looks to be using the tools you expect.

/opt/local/bin/as

@(#)PROGRAM:ld  PROJECT:ld64-97.17

moreover, IFF you put another set of tools earlier in the PATH, they should not override the ones set by --with-as/ld=

[iains]

looks to be using the tools you expect.

/opt/local/bin/as

@(#)PROGRAM:ld  PROJECT:ld64-97.17

moreover, IFF you put another set of tools earlier in the PATH, they should not override the ones set by --with-as/ld=

whereas, by comparison, the installed bootstrap gcc-4.2 above could have its linker or assembler changed by altering the PATH before invoking it [at least, that is the case for newer GCC - perhaps the apple 4.2.1 does not do that, but I would not like to stake anything on that]