https://gcc.gnu.org/bugzilla/show_bug.cgi?id=123976
--- Comment #123 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Peter Dyballa from comment #122) > (In reply to Iain Sandoe from comment #121) > > OK.. so if you have a theory on what specific change or configuration option > > breaks the build - that is exactly what you need to test .. and then we have > > something concrete to debug and fix. > > Iain, I have no input data to build a theory upon it. (And I am pretty sure > that the next ten years *I* won't learn GCC's build rules – I am only an > average, and old, guy.) :) we old guys have to stick together .. > All I have is the obvious: the database of rules 'make -p' prints out shows > that make has knowledge of the three missing files (or rather symlinks). > Make's debug output has forgotten it. Why? Is make buggy? How many makes > (versions) are so buggy? To avoid confusion and to set a baseline (because otherwise we have no way to find out where the observed issue comes from) My builds use "stock" i.e Apple-provided tools (make, ar, as, ld, ... ) these can, of course, also be buggy - but they are a known factor .. > Maybe I did not express it that way: GCC-15.2 and GCC-16.1 do build. Due to > manual intervention the build finds its final stage. Are more proofs needed? I am not debating that you are seeing a problem - but we are not converging on finding where that problem comes from - because there are way too many variables in the equation. When I build the released and published branch(es) using the stock system tools, the builds complete successfully without any manual intervention. In order to converge on finding where the problem you see lies (I contend that my successful build demonstrates that it is not with the released sources) .. we have to reduce the number of changes to "one at a time" until the culprit is found. So .. I suggest that you first build GCC outside of the macports infrastructure .. it can be done: - 1. checkout the darwin branch from Github + add the makeinfo patch - 2. to avoid having to link external dependencies for GMP, MPFR etc you can run contrib/download_prerequisites in the top level of the sources, to save time you can delete gettext and isl .. - 3. make sure your PATH only contains the default system cases + the PATH for your bootstrap compiler (I am assuming that's an earlier GCC version). - 4. keep the configuration simple: e.g. /...../configure --prefix=/..... --build=powerpc-apple-darwin9 --enable-languages=c,c++,objc,obj-c++ CC=powerpc-apple-darwin9-gcc CXX=powerpc-apple-darwin9-g++ - 5 to save build time maybe add --disable-multilib --disable-libgomp that should work unless there's some issue with the bootstrap compiler. THEN ... you can start experimenting with adding other things - e.g. using the macports make (MAKE=...) We are never going to solve your problem by saying "this complex setup does not do the same as this other one" .. I believe that entirely .. but we have to find *which* piece of the broken case is responsible.
