I had a weird problem with building -11 from mercurial (src-public). I have a hg repository which was following -current (cleanly, as far as I am aware) but I switched it over to the netbsd-11 branch. Then I built with my usual wrapper script that provides my preferred options to build.sh. Normally I build the cvs tree so I adjusted the path names for the different repo location. The source tree was not read-only here although for my builds from cvs it would be.
I got a link error stemming from the file
external/gpl3/gcc/dist/gcc/objcp/objcp-lang.cc
create cc1objplus/.depend
compile cc1objplus/cc1objplus-checksum.o
link cc1objplus/cc1objplus
/mnt/scratch/scratch/hg/tools.amd64/lib/gcc/x86_64--netbsd/12.5.0/../../../../x86_64--netbsd/bin/ld:
objcp-lang.o:(.data.rel.ro+0x80): undefined reference to
`gt_pch_rs_gt_c_c_decl_h'
/mnt/scratch/scratch/hg/tools.amd64/lib/gcc/x86_64--netbsd/12.5.0/../../../../x86_64--netbsd/bin/ld:
objcp-lang.o:(.data.rel.ro+0x100): undefined reference to
`gt_ggc_rd_gt_c_c_decl_h'
(more errors like this followe)
Since it wasn't immediately clear what the issue was, I downloaded the
source tarbals from the latest releng build and built from those. This
went fine.
I checked if there were any differences in the source trees, and there
were. This was of course after a build in both trees so the build may
have corrupted some files.
--- src-public/external/gpl3/gcc/dist/gcc/objcp/objcp-lang.cc 2025-10-09
18:50:20.059694094 +0200
+++ tars/usr/src/external/gpl3/gcc/dist/gcc/objcp/objcp-lang.cc 2023-07-30
07:21:14.000000000 +0200
@@ -1,5 +1,5 @@
-/* Language-dependent hooks for Objective-C.
- Copyright (C) 2001-2022 Free Software Foundation, Inc.
+/* Language-dependent hooks for Objective-C++.
+ Copyright (C) 2005-2022 Free Software Foundation, Inc.
... many more differences
In fact, the differing file is a symlink in mercurial and a plain file
in the tarball:
hg$ l src-public/external/gpl3/gcc/dist/gcc/objcp/objcp-lang.cc
tars/usr/src/external/gpl3/gcc/dist/gcc/objcp/objcp-lang.cc
lrwxr-xr-x 1 rhialto wheel 79 Oct 9 20:27
src-public/external/gpl3/gcc/dist/gcc/objcp/objcp-lang.cc@ ->
/mnt/scratch/scratch/hg/src-public/external/gpl3/gcc/dist/gcc/objc/objc-lang.cc
-rw-r--r-- 1 rhialto wheel 2685 Jul 30 2023
tars/usr/src/external/gpl3/gcc/dist/gcc/objcp/objcp-lang.cc
Did the build in the mercurial directory somehow create the symlink, or
is this somehow a fault in the switching between branches?
A hint in the former direction would be this line of output from the
first build log (-j 6, so there is interleaving):
compile cc1obj/genchecksum.lo
compile cc1objplus/genchecksum.lo
symlink cc1/gmp.h
symlink cc1/mpc-log.h
symlink cc1/mpc.h
symlink cc1/mpf2mpfr.h
symlink cc1/mpfr.h
compile cc1/genchecksum.lo
create gcov-dump/.depend
symlink cc1objplus/objcp-act.cc
symlink
cc1objplus//mnt/scratch/scratch/hg/src-public/external/gpl3/gcc/dist/gcc/objcp/objcp-lang.cc
<<=== THIS ONE
compile cc1plus/cp-lang.o
compile cc1obj/objc-lang.o
compile cc1objplus/objcp-decl.o
create gcov/json.d
In the succeeding build, the only occurrence of "objcp-lang" is in this
fragment:
compile cc1objplus/c-cppbuiltin.o
link cc1objplus/genchecksum
create cc1objplus/objcp-act.d
create cc1plus/ptree.d
compile cc1objplus/objcp-act.o
create cc1plus/rtti.d
create cc1objplus/objcp-lang.d
create cc1plus/search.d
compile cc1objplus/objcp-lang.o
Why was the build making this symlink (and even to an absolute path
instead of a relative one, which would be better)? Was it because there
was something wrong in the hg repo?
Potentially this Makefile could be responsible for this:
src-public/external/gpl3/gcc/usr.bin/cc1objplus/Makefile
which contains
BUILDSYMLINKS+= ${DIST}/gcc/objc/objc-act.cc objcp-act.cc \
${DIST}/gcc/objc/objc-lang.cc objcp-lang.cc
Was perhaps the file in the repository changed from a symlink to a plain
file, and hg didn't update it correctly? (Or vice versa; here the
switch was from trunk to netbsd-11) Or was it absent?
Was perhaps the build changed from using a symlink to using a plain
file, and then the symlink action not removed from the Makefile?
Both, acting together to make this particular scenario fail?
At this point it seems to me that, since the file is present in the
tarball version of the repo, this is likely correct, and the
BUILDSYMLINKS should be removed. I did not find a trace of a file
named objcp-act.cc.
I did an experiment with the hg repo. First I removed the symlink and reverted
the file, to restore to a clean checkout. Then I switched it to trunk again,
and the file became
/* Language-dependent hooks for Objective-C++.
Copyright (C) 2005-2024 Free Software Foundation, Inc.
i.e. seemingly a correct version.
Then I changed to branch netbsd-11 again and still the file was a plain file,
but it had changed size. There was still no symlink.
So I don't think I re-created the issue. Unless the Makefile machinery
can replace the plain file with a symlink forcibly, perheps when the
time stamps on the files relate in a certain way?
-Olaf.
--
___ Olaf 'Rhialto' Seibert <rhialto/at/falu.nl>
\X/ There is no AI. There is just someone else's work. --I. Rose
signature.asc
Description: PGP signature
