[This likely applies to some other lang/gcc* examples.] On powerpc (head -r308247, so 12-CURRENT) I tried to build lang/gcc6 and it failed at the comparison step (stage 3 vs. 2). Looking at the mismatched .o's via objdump -x -d : stage 3 had built with debug information present but stage 2 had not. The /etc/make.conf had: WITH_DEBUG= WITH_DEBUG_FILES= So to have a build with WITH_DEBUG= in use I had to turn off the full bootstrap option. Another way would be to not have WITH_DEBUG= but still have the full bootstrap. But having both at the same time is broken. Supporting notes: I do not build the JAVA stuff so for powerpc64 I enable building lang/gcc6: # svnlite diff /usr/ports/lang/gcc6 Index: /usr/ports/lang/gcc6/Makefile =================================================================== --- /usr/ports/lang/gcc6/Makefile (revision 424540) +++ /usr/ports/lang/gcc6/Makefile (working copy) @@ -13,7 +13,7 @@ LICENSE= GPLv3 GPLv3RLE LICENSE_COMB= multi -BROKEN_powerpc64= Does not build +#BROKEN_powerpc64= Does not build LIB_DEPENDS= libgmp.so:math/gmp \ libmpfr.so:math/mpfr \ I experiment with the broken/problematical clang 3.8.0 for targeting powerpc64 and powerpc and report specific problems to llvm for what blocks FreeBSD from being able to use clang as a system compiler for those TARGET_ARCH's. For example I use a modified kernel signal handling that includes a so-called "red zone" on the stack to deal with clang's powerpc ABI stack-handling violations in the code that it generates. (It allows me to find other issues without waiting for the ABI fix.) So my powerpc and powerpc64 contexts are not currently normal but are more like what clang-based powerpc and powerpc64 environments would be like if/when clang is sufficient for direct use by FreeBSD. (Workarounds and avoiding specific issues being involved.) An implication is that direct replication of what I've done would be odd: a system-clang based build of lang/gcc6. But I doubt that clang vs. gcc as the host compiler matters for the WITH_DEBUG= build properties.
(In reply to Mark Millard from comment #0) I tried this on a BananaPi-M3 (armv6) and it did not have the problem: the comparison of stage 3 vs. stage 2 passed. So this issue may be specific to only some architectures, possibly only powerpc. (powerpc64 is odd by forcing gcc49 to be used for the bootstrap even if the system compiler is clang instead of gcc 4.2.1. So while powerpc64 did not have the problem I did not try to conclude much from that. armv6 does not have such an odd context and yet does not have the problem.)
(In reply to Mark Millard from comment #0) FYI: The following context notes associated with mey powerpc and powerpc64 experiments may prove useful. For lang/gcc* and devel/gcc* builds I have JAVA (when an option) and GRAPHITE (when an option) unset in general. For powerpc64 targeting I normally unset MULTILIB as well when it is listed as a possibility (so 64-bit only). As I remember for powerpc/powerpc64 lang/gcc49 (for example) JAVA fails with something like: /usr/local/bin/ld: classpath/tools/.libs/libgcj_tools_la-tools.o: unknown relocation type 3345220 for `*UND*' and I was not using JAVA anyway. For powerpc64 and MULTILIB: The lib32 context does not work when used (lib32 built by, for example, devel/powerpc64-gcc for buildworld). This is due to crtbeginS code problems related to R30 use (bad address in R30 dereferenced). (Native builds and cross builds from amd64 both produce the bad code.) I have not figured out why the crtbeginS code produced by devel/powerpc64-gcc is as it is --or how to control that code to be what FreeBSD needs for lib32 use.
Andreas, does this trigger anything? Mark, I am very surprised that any global setting would affect stage 3 build of GCC versus stage 2 build since these two should be built identically - which is the point of the bootstrap and comparing these two stages. For me to debug this, I do lack to this environment (hardware as well FreeBSD version), and it seems both are needed to trigger this. What I recommend you check out is comparing two compiler invocations for one and the same file, one in the stage 2 build, the other in the stage 3 build. Which, if any, differences do you see?
(In reply to Gerald Pfeifer from comment #3) Below gives the evidence from the script log file. But the summary is that, while both stage 2 and stage 3 list -g in the powerpc xg++ command, stage 2's xg++ command has -gtoggle and stage 3's xg++ command does not. -gtoggle is described in https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html as: -gtoggle Turn off generation of debug info, if leaving out this option generates it, or turn it on at level 2 otherwise. The position of this argument in the command line does not matter; it takes effect after all other options are processed, and it does so only once, no matter how many times it is given. This is mainly intended to be used with -fcompare-debug. I'll note that so far I've only seen the mismatched comparison on powerpc, not even powerpc64. amd64 and armv6 have not had a mismatch. The detailed evidence using read-rtl.c and its read-rtl.o as an example . . . The first compile (stage 1) of read-rtl.o from the log (just shown for reference): c++ -std=gnu++98 -c -g -DIN_GCC -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attrib ute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I/usr/obj/portswork/usr/ports/lang/gc c6/work/gcc-6.2.0/gcc -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/gcc/build -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/gcc/../include -I/usr/obj/portswork/usr/ports/lang/gcc6 /work/gcc-6.2.0/gcc/../libcpp/include -DLIBICONV_PLUG \ -o build/read-rtl.o /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/gcc/read-rtl.c c++: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated The 2nd stage (the first compile by xg++): (formatted to isolate the later difference with the 3rd as single option on its own line) /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./prev-gcc/xg++ -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./prev-gcc/ -B/usr/local/powerpc-portbld-freebsd12.0/bin/ -nostdinc++ -B/usr/obj /portswork/usr/ports/lang/gcc6/work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/src/.libs -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/li bsupc++/.libs -isystem /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/include/powerpc-portbld-freebsd12.0 -isystem /usr/obj/portswork/usr/ports/lang /gcc6/work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/include -isystem /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libstdc++-v3/libsupc++ -L/usr/obj/portswork/usr/ports/lang/gcc6/ work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/src/.libs -L/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/gcc -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/gcc/build -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/gcc/../include -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/gcc/../libcpp/include -DLIBICONV_PLUG \ -o build/read-rtl.o /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/gcc/read-rtl.c The 3rd stage (the 2nd compile by xg++) does not have -gtoggle: (blank line for the lack of the -gtoggle) /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./prev-gcc/xg++ -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./prev-gcc/ -B/usr/local/powerpc-portbld-freebsd12.0/bin/ -nostdinc++ -B/usr/obj /portswork/usr/ports/lang/gcc6/work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/src/.libs -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/li bsupc++/.libs -isystem /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/include/powerpc-portbld-freebsd12.0 -isystem /usr/obj/portswork/usr/ports/lang /gcc6/work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/include -isystem /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libstdc++-v3/libsupc++ -L/usr/obj/portswork/usr/ports/lang/gcc6/ work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/src/.libs -L/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/libsupc++/.libs -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/gcc -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/gcc/build -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/gcc/../include -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/gcc/../libcpp/include -DLIBICONV_PLUG \ -o build/read-rtl.o /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/gcc/read-rtl.c -gtoggle is the only difference that I find between the commands.
(In reply to Mark Millard from comment #4) I normally have WITH_DEBUG "always on" and have not tied omitting it to see if there still would be a -gtoggle difference for lang/gcc6. So I've not really done enough to blame WITH_DEBUG for sure for lang/gcc6. (Let me know if you need the behavior confirmed for lack of WITH_DEBUG.) (I normally also have WTIH_DEBUG_FILES "always on".) Side note on why I suspect WITH_DEBUG: I've run into multiple ports that independently use WITH_DEBUG for their own purposes (even outside of FreeBSD contexts). One of those requires disabling WITH_DEBUG for it to complete building: (bugzilla 206679) www/webkit-qt5: ar: libWebCore.a: File truncated for debug/libWebCore.a when FreeBSD ports' WITH_DEBUG= is used I wish FreeBSD's ports infrastructure had picked a less generic name, say something like WITH_FBSD_DBG , that effectively could be treated as reserved because preexisting matches were rather unlikely compared to WITH_DEBUG . Making a port that uses WITH_DEBUG on its own use something else for its internal purposes and then maintaining that status over time would likely be a major pain. (Luckily: at least for now I do not build anything that indirectly gets to www/webkit-qt5 .)
Reply to comment #3: No Gerald it doesn't ring. I doubt that the WITH_DEBUG* has an influence on the bootstrap. I see no direct invocation with WITH_DEBUG* setting something special. The -gtoggle is intended. We want to check if stage2 builds the exact same binary w/o debug as stage3 does with debug. I'll try to reproduce but it'll take some time. Upgrade 32-bit machine, portudate and then bootstrap. I think it is a simple bootstrap-comparison issue which might be hard to debug. I have currently a similar one on aarch64-*-freebsd*. On trunk and 5.4.x it bootstraps, but on 6.x it fails.
(In reply to Andreas Tobler from comment #6) I did a build attempt with full bootstrap selected but without WITH_DEBUG (from /etc/make.conf ). Summary: Stage 2 still has: -g -gtoggle Stage 3 still has: -g and the build fails the comparison of stages 2 and 3 in the same way as before. So WITH_DEBUG has nothing to do with it. Supporting evidence: Stage 2's read-rtl.c compile has both -g and -gtoggle present: (on isolated lines in the below) /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./prev-gcc/xg++ -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./prev-gcc/ -B/usr/local/powerpc-portbld-freebsd12.0/bin/ -nostdinc++ -B/usr/obj /portswork/usr/ports/lang/gcc6/work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/src/.libs -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/li bsupc++/.libs -isystem /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/include/powerpc-portbld-freebsd12.0 -isystem /usr/obj/portswork/usr/ports/lang /gcc6/work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/include -isystem /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libstdc++-v3/libsupc++ -L/usr/obj/portswork/usr/ports/lang/gcc6/ work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/src/.libs -L/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wn o-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/gcc -I/usr/obj/portswork/usr/ports/lang/gcc6/w ork/gcc-6.2.0/gcc/build -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/gcc/../include -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/gcc/../libcpp/include -DLIBICONV_PLUG \ -o build/read-rtl.o /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/gcc/read-rtl.c The debug sections are missing for Stage 2: # objdump -x -d /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/stage2-gcc/build/read-rtl.o | more . . . Sections: Idx Name Size VMA LMA File off Algn 0 .text 000030cc 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .data 00000000 00000000 00000000 00003100 2**0 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0000004d 00000000 00000000 00003100 2**2 ALLOC 3 .rodata 000002ac 00000000 00000000 00003100 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 4 .rodata.cst4 00000014 00000000 00000000 000033ac 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 5 .rodata.str1.4 00000233 00000000 00000000 000033c0 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .sbss 00000008 00000000 00000000 000035f4 2**2 ALLOC 7 .comment 00000027 00000000 00000000 000035f4 2**0 CONTENTS, READONLY 8 .note.GNU-stack 00000000 00000000 00000000 0000361b 2**0 CONTENTS, READONLY 9 .eh_frame 00000488 00000000 00000000 0000361c 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA . . . Stage 3's read-rtl.c compile has -g but not -gtoggle present(?): (on isolated lines in the below) /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./prev-gcc/xg++ -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/./prev-gcc/ -B/usr/local/powerpc-portbld-freebsd12.0/bin/ -nostdinc++ -B/usr/obj /portswork/usr/ports/lang/gcc6/work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/src/.libs -B/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/li bsupc++/.libs -isystem /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/include/powerpc-portbld-freebsd12.0 -isystem /usr/obj/portswork/usr/ports/lang /gcc6/work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/include -isystem /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/libstdc++-v3/libsupc++ -L/usr/obj/portswork/usr/ports/lang/gcc6/ work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/src/.libs -L/usr/obj/portswork/usr/ports/lang/gcc6/work/.build/prev-powerpc-portbld-freebsd12.0/libstdc++-v3/libsupc++/.libs -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadi c-macros -Wno-overlength-strings -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/gcc -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6 .2.0/gcc/build -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/gcc/../include -I/usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/gcc/../libcpp/include -DLIBICONV_PLUG \ -o build/read-rtl.o /usr/obj/portswork/usr/ports/lang/gcc6/work/gcc-6.2.0/gcc/read-rtl.c The debug sections are present for Stage 3: # objdump -x -d /usr/obj/portswork/usr/ports/lang/gcc6/work/.build/stage3-gcc/build/read-rtl.o | more . . . Sections: Idx Name Size VMA LMA File off Algn 0 .text 000030cc 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE 1 .data 00000000 00000000 00000000 00003100 2**0 CONTENTS, ALLOC, LOAD, DATA 2 .bss 0000004d 00000000 00000000 00003100 2**2 ALLOC 3 .rodata 000002a9 00000000 00000000 00003100 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 4 .rodata.cst4 00000014 00000000 00000000 000033ac 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA 5 .rodata.str1.4 00000233 00000000 00000000 000033c0 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .sbss 00000008 00000000 00000000 000035f4 2**2 ALLOC 7 .debug_info 0000f57c 00000000 00000000 000035f4 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 8 .debug_abbrev 00000a87 00000000 00000000 00012b70 2**0 CONTENTS, READONLY, DEBUGGING 9 .debug_loc 0000586a 00000000 00000000 000135f7 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 10 .debug_aranges 00000020 00000000 00000000 00018e61 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 11 .debug_ranges 00001340 00000000 00000000 00018e81 2**0 CONTENTS, READONLY, DEBUGGING 12 .debug_line 00001534 00000000 00000000 0001a1c1 2**0 CONTENTS, RELOC, READONLY, DEBUGGING 13 .debug_str 0000dfde 00000000 00000000 0001b6f5 2**0 CONTENTS, READONLY, DEBUGGING 14 .comment 00000027 00000000 00000000 000296d3 2**0 CONTENTS, READONLY 15 .note.GNU-stack 00000000 00000000 00000000 000296fa 2**0 CONTENTS, READONLY 16 .eh_frame 00000488 00000000 00000000 000296fc 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA . . .
(In reply to Mark Millard from comment #7) I looked at a armv6 example (which did not fail the comparison). It also has (read-rtl.c example): Stage 2: -g -gtoggle Stage 3: -g Being successful for the comparison it does not leave . . ./work/. . . having copies of the likes of the compared stage2 and stage3 read-rtl.o files : just the one final one at . . ./work/.build/gcc/build/read-rtl.o . Still it suggests that Stage 2 had debug information turned off by -gtoggle while Stage 3 had it turned on --yet the comparison passed. Unfortunately this might mean having to look at the details of the comparison technique for powerpc and the data it was processing to find what makes it classify its read-rtl.o's as mismatched. Merely noting the variations in having debug information vs. not is apparently not enough to have a mismatch as the classification. Bad assumption on my part, just like the tie to WITH_DEBUG was a bad assumption on my part. Still 32-bit powerpc does fail its comparison so the bugzilla report still applies overall. It just would read better and quicker if I could eliminate my false assumptions from the description and comments.
I have to confirm that lang/gcc6 is broken on powerpc. It is a bootstrap comparison failure. Also lang/gcc6-devel is broken. lang/gcc5 should work. It takes some time to fix this.
The bootstrap comparison is fixed with the same fix needed for aarch64. It is included in the files/patch-aarch64-support, the last two files. (gcc/dwarf2out.c and gcc/cgraphunit.c)
The multilib build succeeded too. But there is a fundamental issue on how we install the ports gcc. For 'single' lib architectures it doesn't matter. But for multilib architectures we might have to reconsider the path where install gcc.
(In reply to Andreas Tobler from comment #10) I note that on the ppc list: Jesper Schmitz Mouridsen jsm at FreeBSD.org Mon Nov 12 21:48:26 UTC 2018 reports: QUOTE After 2.5 days compiling gcc7 on mac g4 i get the following (stage2 and stage3 comparison errors) Any working configs out there? I've found similar issues (gcc6) in the past https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214456 END QUOTE Were gcc7, gcc8, etc. ever updated for the issue? gcc6 is no longer updated upstream and devel/gcc6-devel is defunct now. I'm not yet ready to test such things in a modern environment.
(In reply to Mark Millard from comment #12) Explained on lists as the elf toolchain problem fixed in head -r339726 instead of this old issue.
Is this PR still relevant?
No, we no longer support gcc6. And gcc789 look fine on powerpc(64)