Created attachment 865533 [details] bootstrap prefix script output Hello, The link to gdbm fails with this error: make[1]: Entering directory '/Users/alarig/Gentoo/var/tmp/portage/dev-lang/perl-5.38.0-r1/work/perl-5.38.0/ext/Hash-Util' LD_RUN_PATH="/Users/alarig/Gentoo/lib" env MACOSX_DEPLOYMENT_TARGET=13.0 gcc -Wl,-rpath,"/Users/alarig/Gentoo/lib" -Wl,-dead_strip_dylibs -mmacosx-version-min=13.0 -bundle -undefined dynamic_lookup -Wl,-dead_strip_dylibs GDBM_File.o -o ../../lib/auto/GDBM_File/GDBM_File.bundle \ -lgdbm \ ld: library not found for -lgdbm clang: error: linker command failed with exit code 1 (use -v to see invocation) mv CN.xsc CN.c make[1]: *** [Makefile:479: ../../lib/auto/GDBM_File/GDBM_File.bundle] Error 1 make[1]: Leaving directory '/Users/alarig/Gentoo/var/tmp/portage/dev-lang/perl-5.38.0-r1/work/perl-5.38.0/ext/GDBM_File' Thanks
At that point, `gcc` should really be the GCC we just built. This feels consistent with some other bugs we've seen recently where later stages don't seem to be really using the just-built prefixified compiler... Wonder if this was introduced by https://github.com/gentoo/prefix/commit/ae09a2683a18f7148048d0b037ec80227e1571ce?
problem is the linker isn't merged yet, I saw the same problem on x86_64-apple-darwin17 I thought I pushed a fix for this: https://gitweb.gentoo.org/repo/proj/prefix.git/patch/?id=7e645768dc069ea0a416e7e57b96c996d085d82b Apparently not?
Maybe it got started before that fix. You know, we should really make the bootstrap script print a SHA256 of itself at the beginning of the log...
(In reply to Sam James from comment #3) > Maybe it got started before that fix. > > You know, we should really make the bootstrap script print a SHA256 of > itself at the beginning of the log... and/or we just version it (Emacs has a nice auto-update thing, not sure about vim: see the hook timestamp stuff in https://gist.github.com/thesamesam/4ddaa95f3f42c2be312b676476cbf505).
SHA would be nice, and I could do something in the rsync tree to identify it as well with the git SHA-1 or something
Created attachment 865542 [details] stage3.log.xz I am seeing a similar failure in my class. I instructed my student to turn off the USE flag of dev-lang/perl[gdbm] , and the bootstrap finished. Reported-by: Yufeng Li <liyufeng21@mails.tsinghua.edu.cn>
(In reply to Fabian Groffen from comment #2) > problem is the linker isn't merged yet, I saw the same problem on > x86_64-apple-darwin17 > > I thought I pushed a fix for this: > https://gitweb.gentoo.org/repo/proj/prefix.git/patch/ > ?id=7e645768dc069ea0a416e7e57b96c996d085d82b > > Apparently not? I just tested this fix on darwin, and now the linker command works.
*** Bug 912961 has been marked as a duplicate of this bug. ***
Does that mean perl merges fine for you? It doesn't for me. The problem I see on Darwin specifically is that configure script tests whether gdbm is in libc, which it isn't on Darwin. Thus it decides it cannot use gdbm, but "hints" override this decision and make it use gdbm anyway. <gdbm.h> found. gdbm_open() NOT found. Hmm. Based on the hints in hints/darwin.sh, the recommended value for $i_gdbm on this machine was "define"! Keep the recommended value? [y] lateron it fails LD_RUN_PATH="/Scratch-Local/Gentoo/bootstrap64-20230905/lib" env MACOSX_DEPLOYMENT_TARGET=10.13 x86_64-apple-darwin17-gcc -Wl,-rpath,"/Scratch- Local/Gentoo/bootstrap64-20230905/lib" -Wl,-dead_strip_dylibs -mmacosx-version- min=10.13 -bundle -undefined dynamic_lookup -Wl,-dead_strip_dylibs GDBM_File. o -o ../../lib/auto/GDBM_File/GDBM_File.bundle \ -lgdbm \ ld: library not found for -lgdbm gdbm was just emerged before this, so it's there, but the linker isn't using the prefix paths at this point, or so it seems. I have the impression the LDFLAGS are either ignored or not setup.
I think I know why this happens, and am currently testing a change.
(In reply to Fabian Groffen from comment #9) > Does that mean perl merges fine for you? It doesn't for me. The problem I > see on Darwin specifically is that configure script tests whether gdbm is in > libc, which it isn't on Darwin. Thus it decides it cannot use gdbm, but > "hints" override this decision and make it use gdbm anyway. > > <gdbm.h> found. > gdbm_open() NOT found. > Hmm. Based on the hints in hints/darwin.sh, > the recommended value for $i_gdbm on this machine was "define"! > Keep the recommended value? [y] > > lateron it fails > > LD_RUN_PATH="/Scratch-Local/Gentoo/bootstrap64-20230905/lib" env > MACOSX_DEPLOYMENT_TARGET=10.13 x86_64-apple-darwin17-gcc > -Wl,-rpath,"/Scratch- Local/Gentoo/bootstrap64-20230905/lib" > -Wl,-dead_strip_dylibs -mmacosx-version- min=10.13 -bundle -undefined > dynamic_lookup -Wl,-dead_strip_dylibs GDBM_File. o -o > ../../lib/auto/GDBM_File/GDBM_File.bundle \ > -lgdbm \ > > ld: library not found for -lgdbm > > gdbm was just emerged before this, so it's there, but the linker isn't using > the prefix paths at this point, or so it seems. > > I have the impression the LDFLAGS are either ignored or not setup. Yes, if I remove LDFLAGS from the unset perl merges fine. After that, it fails merging python and some other packages. It complains about headers not found (like yaml.h), from packages that were merged before, while those headers are in fact in ${ROOT}/usr/include. Similar issue reported on bug 913876. Removing CPPFLAGS from the 2 previous unset statements solves this for me.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/proj/prefix.git/commit/?id=580a9d39d536e6740450bed591a326980e24ffdb commit 580a9d39d536e6740450bed591a326980e24ffdb Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2023-09-10 10:54:02 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2023-09-10 10:54:02 +0000 scripts/bootstrap-prefix: do not use stacked-prefix on non-RAP bootstraps The stacked-prefix approach keeps packages in ROOT/tmp instead of the final destination Prefix. This causes problems for tools (most notably binutils-config) do not get configured for the destination Prefix, which stage3 relies on. Closes: https://bugs.gentoo.org/910396 Signed-off-by: Fabian Groffen <grobian@gentoo.org> scripts/bootstrap-prefix.sh | 68 ++++++++++++++------------------------------- 1 file changed, 21 insertions(+), 47 deletions(-)
I confirm that the prefix bootstrap worked, thanks a lot for the fix!
