On Wed, Jun 24, 2026 at 06:56:57AM -0300, Alexandre Oliva wrote: > > libstdc++-v3 in gcc-15 gained uses of a make function that was added > in GNU make 3.81, but ppc-vx6 is GNU make 3.80, so calling the > function returns an empty string, and the build fails. > > gcc/doc/install.texi states GCC requires make 3.80 to build, so > rewrite those bits to avoid the new function. > > Install locations don't need abspath because they're already supposed > to be absolute, since installation can't work with relative paths and > DESTDIR is supposed to be prependable. > > $? may gain the srcdir VPATH, which would complicate dropping abspath, > so iterate over the two filenames. > > Regstrapped on x86_64-linux-gnu. Also tested with ppc-vx6's make for > i686-linux-gnu with gcc-15. Ok to install? > > > for libstdc++-v3/ChangeLog > > * src/c++23/Makefile.am (libstdc++.modules.json): Rewrite > without abspath make function. > (stamp-modules-bits): Likewise. > * src/c++23/Makefile.in: Rebuilt.
This change broke various module tests (and got backported even to 15 :( ). I'm using objdir as a subdirectory of the gcc tree, so ../configure ... > @@ -57,7 +57,9 @@ std.compat.cc: std.compat.cc.in std-clib.cc.in > # Also put the interface units in the build-includes bits directory. > stamp-modules-bits: $(includebits_DATA) > @-mkdir -p $(top_builddir)/include/bits > - -cd $(top_builddir)/include/bits && $(LN_S) $(abspath $?) . 2>/dev/null > + -for f in $(includebits_DATA); do \ > + $(LN_S) $(abs_srcdir)/$$f $(top_builddir)/include/bits; \ > + done 2>/dev/null > @$(STAMP) $@ > > all-local: stamp-module-manifest stamp-modules-bits Before this change, the /home/jakub/src/gcc/obj38/x86_64-pc-linux-gnu/libstdc++-v3/include/bits std.cc symlink used to point to /home/jakub/src/gcc/obj38/x86_64-pc-linux-gnu/libstdc++-v3/src/c++23/std.cc Now it points to /home/jakub/src/gcc/obj40/x86_64-pc-linux-g~-v3/../../../libstdc++-v3/src/c++23/std.cc which doesn't exist, the source directory only has std.cc.in file from which the std.cc file is generated in the build directory. The following patch fixes it by using abs_builddir instead of abs_srcdir. Fixes up -FAIL: g++.dg/modules/compile-std1.C -std=c++29 (test for excess errors) -FAIL: g++.dg/modules/compile-std1.C -std=c++29 module-cmi std (gcm.cache/std.gcm) -FAIL: g++.dg/modules/compile-std1.C -std=c++29 module-cmi std.compat (gcm.cache/std.compat.gcm) -FAIL: g++.dg/plugin/std-module-exports-c++20.C -fplugin=./std_module_exports_plugin.so (test for excess errors) -FAIL: g++.dg/plugin/std-module-exports-c++23.C -fplugin=./std_module_exports_plugin.so (test for excess errors) -FAIL: g++.dg/plugin/std-module-exports-c++26.C -fplugin=./std_module_exports_plugin.so (test for excess errors) Ok for trunk/release branches? 2026-06-25 Jakub Jelinek <[email protected]> * src/c++23/Makefile.am (stamp-modules-bits): Use abs_builddir instead of abs_srcdir. * src/c++23/Makefile.in: Regenerate. --- libstdc++-v3/src/c++23/Makefile.am.jj 2026-06-25 00:10:29.319324548 +0200 +++ libstdc++-v3/src/c++23/Makefile.am 2026-06-25 09:09:35.276266154 +0200 @@ -58,7 +58,7 @@ std.compat.cc: std.compat.cc.in std-clib stamp-modules-bits: $(includebits_DATA) @-mkdir -p $(top_builddir)/include/bits -for f in $(includebits_DATA); do \ - $(LN_S) $(abs_srcdir)/$$f $(top_builddir)/include/bits; \ + $(LN_S) $(abs_builddir)/$$f $(top_builddir)/include/bits; \ done 2>/dev/null @$(STAMP) $@ --- libstdc++-v3/src/c++23/Makefile.in.jj 2026-06-25 00:10:29.319324548 +0200 +++ libstdc++-v3/src/c++23/Makefile.in 2026-06-25 09:09:59.614642142 +0200 @@ -866,7 +866,7 @@ std.compat.cc: std.compat.cc.in std-clib stamp-modules-bits: $(includebits_DATA) @-mkdir -p $(top_builddir)/include/bits -for f in $(includebits_DATA); do \ - $(LN_S) $(abs_srcdir)/$$f $(top_builddir)/include/bits; \ + $(LN_S) $(abs_builddir)/$$f $(top_builddir)/include/bits; \ done 2>/dev/null @$(STAMP) $@ Jakub
