I am having trouble building lang/gcc8 (and gcc7) when lang/libunwind is installed. This is on MacOS, but the basic cause seems system-independent. The problem stems from the fact that libunwind installs unwind.h and gcc uses an internal version of unwind.h. These two files are different. For me, gcc is picking up the libunwind version when it is expecting the internal one. Here is one example of a command that fails because of this: /Volumes/NetBSD-boost/NetBSD/pkgsrc-HEAD/pkgsrc/lang/gcc8/work/build/./gcc/xgcc -B/Volumes/NetBSD-boost/NetBSD/pkgsrc-HEAD/pkgsrc/lang/gcc8/work/build/./gcc/ -B/Volumes/NetBSD-boost/NetBSD/pkg-HEAD/Darwin-19.0.0-x86_64/gcc8/x86_64-apple-darwin19/bin/ -B/Volumes/NetBSD-boost/NetBSD/pkg-HEAD/Darwin-19.0.0-x86_64/gcc8/x86_64-apple-darwin19/lib/ -isystem /Volumes/NetBSD-boost/NetBSD/pkg-HEAD/Darwin-19.0.0-x86_64/gcc8/x86_64-apple-darwin19/include -isystem /Volumes/NetBSD-boost/NetBSD/pkg-HEAD/Darwin-19.0.0-x86_64/gcc8/x86_64-apple-darwin19/sys-include -g -O2 -I/Volumes/NetBSD-boost/NetBSD/pkg-HEAD/Darwin-19.0.0-x86_64/include/python3.7 -I/Volumes/NetBSD-boost/NetBSD/pkg-HEAD/Darwin-19.0.0-x86_64/include -O2 -g -O2 -I/Volumes/NetBSD-boost/NetBSD/pkg-HEAD/Darwin-19.0.0-x86_64/include/python3.7 -I/Volumes/NetBSD-boost/NetBSD/pkg-HEAD/Darwin-19.0.0-x86_64/include -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -mmacosx-version-min=10.5 -pipe -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -mmacosx-version-min=10.5 -pipe -fno-common -I. -I. -I../.././gcc -I../../../gcc-8.3.0/libgcc -I../../../gcc-8.3.0/libgcc/. -I../../../gcc-8.3.0/libgcc/../gcc -I../../../gcc-8.3.0/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o unwind-dw2_s.o -MT unwind-dw2_s.o -MD -MP -MF unwind-dw2_s.dep -DSHARED -fexceptions -c ../../../gcc-8.3.0/libgcc/unwind-dw2.c Notice that -I/Volumes/NetBSD-boost/NetBSD/pkg-HEAD/Darwin-19.0.0-x86_64/include (which contains the libunwind version) precedes -I../../../gcc-8.3.0/libgcc (which contains the internal version). The attached two patches seem sufficient to fix this, because they ensure that the correct internal directory is early enough in the list. It seems that this would be a general problem that needs addressing upstream as well. However, I am not a gcc wizard, so please suggest improvements. Thanks a lot. Cheers, Brook
Attachment:
patch-libgcc_Makefile.in
Description: Binary data
Attachment:
patch-libstdc++-v3_configure
Description: Binary data