While debugging the MacPorts build approach for FSF gcc and comparing it to our own in the fink project, I ran across a surprising result. The MacPorts project builds fail when their libunwinder-headers package is installed in their ${prefix} which is /opt/local. I expected to be able to solve this by building, like fink, with CPPFLAGS and LDFLAGS unset (i.e. no -I/opt/local/include on CPPFLAGS and -L/opt/local/lib on LDFLAGS) but instead to rely on the individual --with-*= configure options to sort the paths out. Weirdly the build starts out fine and the initially generated Makefiles always retain... CPPFLAGS= but once the build hits any configure which used config/gettext.m4 or config/iconv.m4, CPPFLAGS gets contaminated with INCICONV or LIBICONV_INCLUDE. Why can't config/gettext.m4 and config/iconv.m4 be restructured to perform its tests without contaminating the previous contents of CPPFLAGS in the process?
FYI, the only reason we never see the same breakage on fink as MacPorts is that we don't happen to have a libunwinder package in our package set to expose us to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14925 We do however end up with the same contamination of CPPFLAGS late in the build (in our case with contamination by -I/sw/include). Also, in the case of --with-libiconv-prefix[=DIR] search for libiconv in DIR/include and DIR/lib this process results in DIR being placed on CPPFLAGS instead of being keep on the INCLUDES lines of individual Makefile.in instead. My initial attempts to detangle this have been along the lines of... --- gcc/Makefile.in.orig 2016-11-08 03:29:02.000000000 -0500 +++ gcc/Makefile.in 2016-11-08 03:29:56.000000000 -0500 @@ -1063,7 +1063,7 @@ # currently being compiled, in both source trees, to be examined as well. # libintl.h will be found in ../intl if we are using the included libintl. INCLUDES = -I. -I$(@D) -I$(srcdir) -I$(srcdir)/$(@D) \ - -I$(srcdir)/../include @INCINTL@ \ + -I$(srcdir)/../include @INCINTL@ ${INCICONV} \ $(CPPINC) $(GMPINC) $(DECNUMINC) $(BACKTRACEINC) \ $(ISLINC) --- libstdc++-v3/src/Makefile.in.orig 2016-11-08 02:14:37.000000000 -0500 +++ libstdc++-v3/src/Makefile.in 2016-11-08 02:15:15.000000000 -0500 @@ -126,7 +126,7 @@ @VTV_CYGMIN_TRUE@am_libvtv_la_OBJECTS = vtv_stubs.lo libvtv_la_OBJECTS = $(am_libvtv_la_OBJECTS) @VTV_CYGMIN_TRUE@am_libvtv_la_rpath = -rpath $(toolexeclibdir) -DEFAULT_INCLUDES = -I.@am__isrc@ -I$(top_builddir) +DEFAULT_INCLUDES = -I.@am__isrc@ -I$(top_builddir) -I${INCICONV} depcomp = am__depfiles_maybe = CXXCOMPILE = $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) \ --- libstdc++-v3/configure.orig 2016-11-08 02:00:42.000000000 -0500 +++ libstdc++-v3/configure 2016-11-08 02:10:25.000000000 -0500 @@ -28529,7 +28529,6 @@ am_cv_func_iconv="no, consider installing GNU libiconv" am_cv_lib_iconv=no am_save_CPPFLAGS="$CPPFLAGS" - CPPFLAGS="$CPPFLAGS $INCICONV" if test x$gcc_no_link = xyes; then as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO" 5 fi @@ -40804,7 +40803,6 @@ am_cv_func_iconv="no, consider installing GNU libiconv" am_cv_lib_iconv=no am_save_CPPFLAGS="$CPPFLAGS" - CPPFLAGS="$CPPFLAGS $INCICONV" if test x$gcc_no_link = xyes; then as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO" 5 fi @@ -46928,7 +46926,6 @@ am_cv_func_iconv="no, consider installing GNU libiconv" am_cv_lib_iconv=no am_save_CPPFLAGS="$CPPFLAGS" - CPPFLAGS="$CPPFLAGS $INCICONV" if test x$gcc_no_link = xyes; then as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO" 5 fi @@ -59755,7 +59752,6 @@ am_cv_func_iconv="no, consider installing GNU libiconv" am_cv_lib_iconv=no am_save_CPPFLAGS="$CPPFLAGS" - CPPFLAGS="$CPPFLAGS $INCICONV" if test x$gcc_no_link = xyes; then as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO" 5 fi --- libstdc++-v3/configure.orig 2016-11-08 02:33:18.000000000 -0500 +++ libstdc++-v3/configure 2016-11-08 02:34:41.000000000 -0500 @@ -28596,7 +28596,7 @@ if test "$am_cv_func_iconv" != yes; then am_save_CPPFLAGS="$CPPFLAGS" am_save_LIBS="$LIBS" - CPPFLAGS="$LIBS $INCICONV" + CPPFLAGS="$LIBS" LIBS="$LIBS $LIBICONV" if test x$gcc_no_link = xyes; then as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO" 5 @@ -40870,7 +40870,7 @@ if test "$am_cv_func_iconv" != yes; then am_save_CPPFLAGS="$CPPFLAGS" am_save_LIBS="$LIBS" - CPPFLAGS="$LIBS $INCICONV" + CPPFLAGS="$LIBS" LIBS="$LIBS $LIBICONV" if test x$gcc_no_link = xyes; then as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO" 5 @@ -46993,7 +46993,7 @@ if test "$am_cv_func_iconv" != yes; then am_save_CPPFLAGS="$CPPFLAGS" am_save_LIBS="$LIBS" - CPPFLAGS="$LIBS $INCICONV" + CPPFLAGS="$LIBS" LIBS="$LIBS $LIBICONV" if test x$gcc_no_link = xyes; then as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO" 5 @@ -59819,7 +59819,7 @@ if test "$am_cv_func_iconv" != yes; then am_save_CPPFLAGS="$CPPFLAGS" am_save_LIBS="$LIBS" - CPPFLAGS="$LIBS $INCICONV" + CPPFLAGS="$LIBS" LIBS="$LIBS $LIBICONV" if test x$gcc_no_link = xyes; then as_fn_error "Link tests are not allowed after GCC_NO_EXECUTABLES." "$LINENO" 5 --- gcc/configure.orig 2016-11-08 02:53:20.000000000 -0500 +++ gcc/configure 2016-11-08 02:56:53.000000000 -0500 @@ -10681,7 +10681,6 @@ am_cv_func_iconv="no, consider installing GNU libiconv" am_cv_lib_iconv=no am_save_CPPFLAGS="$CPPFLAGS" - CPPFLAGS="$CPPFLAGS $INCICONV" cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ #include <stdlib.h> @@ -10743,7 +10742,7 @@ if test "$am_cv_func_iconv" != yes; then am_save_CPPFLAGS="$CPPFLAGS" am_save_LIBS="$LIBS" - CPPFLAGS="$LIBS $INCICONV" + CPPFLAGS="$LIBS" LIBS="$LIBS $LIBICONV" cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ --- intl/Makefile.in.orig 2016-11-08 01:34:50.000000000 -0500 +++ intl/Makefile.in 2016-11-08 01:37:15.000000000 -0500 @@ -136,7 +136,7 @@ $(YACC) $(YFLAGS) --output $@ $< rm -f $*.h -INCLUDES = -I. -I$(srcdir) +INCLUDES = -I. -I$(srcdir) -I$(LIBICONV_INCLUDE) check: all --- intl/configure.orig 2016-11-08 01:34:58.000000000 -0500 +++ intl/configure 2016-11-08 01:35:49.000000000 -0500 @@ -4973,7 +4973,6 @@ am_save_CPPFLAGS="$CPPFLAGS" am_save_LIBS="$LIBS" if test -n "$LIBICONV_INCLUDE"; then - CPPFLAGS="$CPPFLAGS $LIBICONV_INCLUDE" LIBS="$LIBS $LIBICONV_LIBDIR" fi LIBS="$LIBS -liconv" which has been successful up until a failed linkage of... /usr/bin/clang++ -arch x86_64 -std=gnu++98 -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-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -Wl,-no_pie gcov-dump.o \ hash-table.o ggc-none.o\ libcommon.a ../libcpp/libcpp.a -liconv ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -o gcov-dump Undefined symbols for architecture x86_64: "_libiconv", referenced from: convert_using_iconv(void*, unsigned char const*, unsigned long, _cpp_strbuf*) in libcpp.a(charset.o) "_libiconv_close", referenced from: __cpp_destroy_iconv in libcpp.a(charset.o) __cpp_convert_input in libcpp.a(charset.o) "_libiconv_open", referenced from: init_iconv_desc(cpp_reader*, char const*, char const*) in libcpp.a(charset.o) ld: symbol(s) not found for architecture x86_64
It appears that config/iconv.m4 needs to be reworked for its tests to succeed. Removing INCICONV from CPPFLAGS on darwin causes the headers from /usr/include to be accidentally used against the libs from /opt/local/lib... configure:10761: /usr/bin/clang++ -arch x86_64 -std=gnu++98 -o conftest -g -Wl,-no_pie conftest.cpp -L/opt/local/lib -liconv >&5 fails because -I/opt/local/include was dropped. This should be available to configure already from... --with-libiconv-prefix[=DIR] without resorting to CPPFLAGS to pass it around to the Makefile.
I've been avoiding this bug for years by just removing the unwind.h header. :-(
(In reply to Mike Stump from comment #3) > I've been avoiding this bug for years by just removing the unwind.h header. > :-( Confirming because I seem to remember solving a build issue like this in the past, too.
is this a GCC bug, or really a gettext /iconv one? (the comments at the top of the file suggest that these two m4 modules have been imported) A quick scan of the code suggests that the writers intended the CPPFLAGS to be saved. However, variable names like "am_save_CPPFLAGS" can overwrite previously saved values in the case of nested configuration tests; it's a very common choice of save name and I have seen this in GCC config problems before. If you change the am_save_CPPFLAGS in the iconv m4 to am_iconv_save_CPPFLAGS (and regenerate all configures that include it) does that resolve the issue? It looks like the gettext save value is already intended to be specific (gt_save_CPPFLAGS)
If configure tests are nested then that's a bug in the way the tests are written.
(In reply to Eric Gallager from comment #4) > (In reply to Mike Stump from comment #3) > > I've been avoiding this bug for years by just removing the unwind.h header. > > :-( > > Confirming because I seem to remember solving a build issue like this in the > past, too. Just happened to me again because MacPorts reinstalled libunwind-headers on me even though I had deactivated it, reconfirming.
r265896 might have affected this
(In reply to Eric Gallager from comment #8) > r265896 might have affected this Update: apparently not; I still had to deactivate libunwind-headers again on my latest build of gcc
(In reply to Eric Gallager from comment #9) > (In reply to Eric Gallager from comment #8) > > r265896 might have affected this > > Update: apparently not; I still had to deactivate libunwind-headers again on > my latest build of gcc Since I keep running into this, I'm adding that part to the title for easier findability
Created attachment 48375 [details] full build log for failing build
I’m also running into this bug: I have recently started linking strace against libunwind (for its handy --stack-traces option), and like having strace available in my package build dependencies to debug build failures interactively. I’m using gcc 9.3.0 and libunwind 1.4.0. The first build failure message I’m encountering is (I attached the full build log to this bug, too): libtool: compile: /usr/src/gcc-amd64-9.3.0-4/build/./gcc/xgcc -shared-libgcc -B/usr/src/gcc-amd64-9.3.0-4/build/./gcc -nostdinc++ -L/usr/src/gcc-amd64-9.3.0-4/build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/usr/src/gcc-amd64-9.3.0-4/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/usr/src/gcc-amd64-9.3.0-4/build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/ro/gcc-amd64-9.3.0-4/out/x86_64-pc-linux-gnu/bin/ -B/ro/gcc-amd64-9.3.0-4/out/x86_64-pc-linux-gnu/lib/ -isystem /ro/gcc-amd64-9.3.0-4/out/x86_64-pc-linux-gnu/include -isystem /ro/gcc-amd64-9.3.0-4/out/x86_64-pc-linux-gnu/sys-include -fno-checking -I/usr/src/gcc-amd64-9.3.0-4/libstdc++-v3/../libgcc -I/usr/src/gcc-amd64-9.3.0-4/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/usr/src/gcc-amd64-9.3.0-4/build/x86_64-pc-linux-gnu/libstdc++-v3/include -I/usr/src/gcc-amd64-9.3.0-4/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=eh_ptr.lo -g -O2 -D_GNU_SOURCE -c /usr/src/gcc-amd64-9.3.0-4/libstdc++-v3/libsupc++/eh_ptr.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o eh_ptr.o libtool: compile: /usr/src/gcc-amd64-9.3.0-4/build/./gcc/xgcc -shared-libgcc -B/usr/src/gcc-amd64-9.3.0-4/build/./gcc -nostdinc++ -L/usr/src/gcc-amd64-9.3.0-4/build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/usr/src/gcc-amd64-9.3.0-4/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/usr/src/gcc-amd64-9.3.0-4/build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/ro/gcc-amd64-9.3.0-4/out/x86_64-pc-linux-gnu/bin/ -B/ro/gcc-amd64-9.3.0-4/out/x86_64-pc-linux-gnu/lib/ -isystem /ro/gcc-amd64-9.3.0-4/out/x86_64-pc-linux-gnu/include -isystem /ro/gcc-amd64-9.3.0-4/out/x86_64-pc-linux-gnu/sys-include -fno-checking -I/usr/src/gcc-amd64-9.3.0-4/libstdc++-v3/../libgcc -I/usr/src/gcc-amd64-9.3.0-4/build/x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu -I/usr/src/gcc-amd64-9.3.0-4/build/x86_64-pc-linux-gnu/libstdc++-v3/include -I/usr/src/gcc-amd64-9.3.0-4/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=eh_personality.lo -g -O2 -D_GNU_SOURCE -c /usr/src/gcc-amd64-9.3.0-4/libstdc++-v3/libsupc++/eh_personality.cc -fPIC -DPIC -D_GLIBCXX_SHARED -o eh_personality.o In file included from /usr/src/gcc-amd64-9.3.0-4/libstdc++-v3/libsupc++/eh_call.cc:28: /usr/src/gcc-amd64-9.3.0-4/libstdc++-v3/libsupc++/unwind-cxx.h:92:3: error: '_Unwind_Ptr' does not name a type; did you mean '_Unwind_SetIP'? 92 | _Unwind_Ptr catchTemp; | ^~~~~~~~~~~ | _Unwind_SetIP /usr/src/gcc-amd64-9.3.0-4/libstdc++-v3/libsupc++/unwind-cxx.h:146:3: error: '_Unwind_Ptr' does not name a type; did you mean '_Unwind_SetIP'? 146 | _Unwind_Ptr catchTemp; | ^~~~~~~~~~~ | _Unwind_SetIP
Stephen Casner and Nick Alcock discussed what I think is this issue on the bug-gettext mailing list: https://lists.gnu.org/archive/html/bug-gettext/2021-02/msg00000.html
So, there's been some talk about how replacing GCC's local copies of stuff from gettext with an external gettext that might be relevant to this bug: https://gcc.gnu.org/pipermail/gcc/2022-June/238920.html