Bug 273323 - buildworld broken due to __string on releng/13.2 building releng/13.2
Summary: buildworld broken due to __string on releng/13.2 building releng/13.2
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: misc (show other bugs)
Version: 13.2-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: Jessica Clarke
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-08-24 09:11 UTC by Ulrich Spörlein
Modified: 2023-10-01 14:45 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ulrich Spörlein freebsd_committer freebsd_triage 2023-08-24 09:11:14 UTC
Hi folks, I run on releng/13.2 and have last updated Apr 12. Wanted to buildworld again like so, but it fails:

% cd /usr/src && git fetch origin && git checkout origin/releng/13.2 && git status && nice make buildworld
HEAD is now at 4341433a673f Add UPDATING entries and bump version
HEAD detached at origin/releng/13.2
nothing to commit, working tree clean
make[1]: "/usr/src/Makefile.inc1" line 338: SYSTEM_COMPILER: Determined that CC=cc matches the source tree.  Not bootstrapping a cross-compiler.
make[1]: "/usr/src/Makefile.inc1" line 343: SYSTEM_LINKER: Determined that LD=ld matches the source tree.  Not bootstrapping a cross-linker.
--------------------------------------------------------------
>>> World build started on Thu Aug 24 11:03:39 CEST 2023
--------------------------------------------------------------
...
--------------------------------------------------------------
>>> stage 1.2: bootstrap tools
--------------------------------------------------------------
cd /usr/src; INSTALL="sh /usr/src/tools/install.sh"  TOOLS_PREFIX=/usr/obj/usr/src/amd64.amd64/tmp  PATH=/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec:/sbin:/bin:/usr/sbin:/usr/bin  WORLDTMP=/usr/obj/usr/src/amd64.amd64/tmp  MAKEFLAGS="-m /usr/src/tools/build/mk  -m /usr/src/share/mk" make  -f Makefile.inc1  DESTDIR=  OBJTOP='/usr/obj/usr/src/amd64.amd64/tmp/obj-tools'  OBJROOT='${OBJTOP}/'  MAKEOBJDIRPREFIX=  BOOTSTRAPPING=1302001  BWPHASE=bootstrap-tools  -DNO_CPU_CFLAGS  -DNO_LINT  -DNO_PIC  -DNO_SHARED  MK_CTF=no  MK_CLANG_EXTRAS=no  MK_CLANG_FORMAT=no  MK_CLANG_FULL=no  MK_HTML=no  MK_MAN=no  MK_PROFILE=no  MK_RETPOLINE=no  MK_SSP=no  MK_TESTS=no  MK_WERROR=no  MK_INCLUDES=yes  MK_MAN_UTILS=yes MK_LLVM_TARGET_ALL=no bootstrap-tools
===> lib/clang/libllvmminimal (obj,all,install)
[Creating objdir /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvmminimal...]
make[3]: "/usr/src/lib/clang/llvm.pre.mk" line 8: warning: "which llvm-tblgen" returned non-zero status
[Creating nested objdir /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvmminimal/Demangle...]
[Creating nested objdir /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvmminimal/Support...]
[Creating nested objdir /usr/obj/usr/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvmminimal/TableGen...]
c++  -O2 -pipe -fno-common -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm-project/llvm/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAVE_VCS_VERSION_INC -DNDEBUG -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd13.2\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd13.2\" -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/amd64.amd64/tmp\" -DLLVM_TARGET_ENABLE_X86 -DLLVM_NATIVE_ASMPARSER=LLVMInitializeX86AsmParser -DLLVM_NATIVE_ASMPRINTER=LLVMInitializeX86AsmPrinter -DLLVM_NATIVE_DISASSEMBLER=LLVMInitializeX86Disassembler -DLLVM_NATIVE_TARGET=LLVMInitializeX86Target -DLLVM_NATIVE_TARGETINFO=LLVMInitializeX86TargetInfo -DLLVM_NATIVE_TARGETMC=LLVMInitializeX86TargetMC -ffunction-sections -fdata-sections -gline-tables-only -MD -MF.depend.Demangle_ItaniumDemangle.o -MTDemangle/ItaniumDemangle.o -Wno-format-zero-length -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-error=unused-but-set-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments -I/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/include  -fno-exceptions -fno-rtti -gline-tables-only -std=c++14    -stdlib=libc++ -Wno-c++11-extensions   -c /usr/src/contrib/llvm-project/llvm/lib/Demangle/ItaniumDemangle.cpp -o Demangle/ItaniumDemangle.o
In file included from /usr/src/contrib/llvm-project/llvm/lib/Demangle/ItaniumDemangle.cpp:13:
In file included from /usr/src/contrib/llvm-project/llvm/include/llvm/Demangle/Demangle.h:13:
In file included from /usr/include/c++/v1/string:535:
/usr/include/c++/v1/string_view:205:10: error: '__string' file not found, did you mean 'string'?
#include <__string>
         ^

My /usr/include/c++/v1/string_view is from Apr 12 as well

% ll /usr/include/c++/v1/string_view
-r--r--r--  1 root  wheel  40049 12 Apr 17:09 /usr/include/c++/v1/string_view


I then tried running make delete-old which I haven't run in years, and it cleared out a whole bunch of old clang include dirs, but the error persists.
Comment 1 Jessica Clarke freebsd_committer freebsd_triage 2023-08-24 09:12:39 UTC
> I then tried running make delete-old which I haven't run in years, and it cleared out a whole bunch of old clang include dirs, but the error persists.

That's going to make things even worse; you should only run that for the source tree you already have installed.
Comment 2 Ulrich Spörlein freebsd_committer freebsd_triage 2023-08-24 10:43:45 UTC
Not really in my case, as I'm staying on releng/13.2 only to get security updates.

No one is messing with compiler versions or includes there.
Comment 3 Jessica Clarke freebsd_committer freebsd_triage 2023-08-24 10:57:01 UTC
Does /usr/include/c++/v1/__string exist? What's the history of this system? __string has been installed since 7b173dd64639 ("Add additional libc++ 4.0.0 headers.") in 2017, so it really sounds like your system is just hosed, and without knowing its history it's hard to say how you got to that state.
Comment 4 Ulrich Spörlein freebsd_committer freebsd_triage 2023-08-24 19:06:04 UTC
% ll -d /usr/include/c++/v1/__string; ll /usr/include/c++/v1/__string
drwxr-xr-x  2 root  wheel  4 11 Apr 13:28 /usr/include/c++/v1/__string/
total 13
-r--r--r--  1 root  wheel  29948 11 Apr 13:28 char_traits.h
-r--r--r--  1 root  wheel  12718 11 Apr 13:28 extern_template_lists.h

I bought this laptop mid-2019, so it started out with whatever was -STABLE back then, likely jumping to -CURRENT to get some things working earlier, but it has been running stable or releng for at least a year or two now.

The build on April 11 still worked fine though (upgrade from releng/13.1 to releng/13.2, I guess), so I wonder how I effed it up?

A different stable/13 system (not releng!) looks the same though:

% ll -d /usr/include/c++/v1/__string; ll /usr/include/c++/v1/__string
drwxr-xr-x  2 root  wheel  4 17 Apr 09:54 /usr/include/c++/v1/__string/
total 13
-r--r--r--  1 root  wheel  29948 17 Apr 09:54 char_traits.h
-r--r--r--  1 root  wheel  12718 17 Apr 09:54 extern_template_lists.h

and there, buildworld is trudging along just fine.


Here's a difference though, broken:
% ll /usr/include/c++/v1/string_view /usr/include/c++/v1/string
-r--r--r--  1 root  wheel  168508 12 Apr 17:09 /usr/include/c++/v1/string
-r--r--r--  1 root  wheel   40049 12 Apr 17:09 /usr/include/c++/v1/string_view

working:
% ll /usr/include/c++/v1/string_view /usr/include/c++/v1/string
-r--r--r--  1 root  wheel  194876 17 Apr 09:54 /usr/include/c++/v1/string
-r--r--r--  1 root  wheel   40822 17 Apr 09:54 /usr/include/c++/v1/string_view

But the releng/13.2 system is on
% clang --version
FreeBSD clang version 14.0.5 (https://github.com/llvm/llvm-project.git llvmorg-14.0.5-0-gc12386ae247c)

and the stable/13 system is on
% clang --version
FreeBSD clang version 15.0.7 (https://github.com/llvm/llvm-project.git llvmorg-15.0.7-0-g8dfdcc7b7bf6)
Comment 5 Jessica Clarke freebsd_committer freebsd_triage 2023-08-24 19:11:57 UTC
What happened on 12th April? It looks like something updated some of your libc++ headers but not all of them.
Comment 6 Jessica Clarke freebsd_committer freebsd_triage 2023-08-24 19:12:16 UTC
(In reply to Jessica Clarke from comment #5)
(and specifically "updated" to an older source version)
Comment 7 Ulrich Spörlein freebsd_committer freebsd_triage 2023-08-25 12:33:11 UTC
I tarred the working /usr/include of the stable/13 system over to the releng/13.2 system, then buildworld completes just fine.

So I ran buildworld&installworld, did delete-old and rebooted, and tried to buildworld again. But it breaks same as before.

In summary: buildworld/installworld on releng/13.2 will mess up /usr/include so that it can not build a second time.

I guess no one uses releng/13.2 really (and when it was branched off stable/13 something didn't get backported properly.)

Fine by me, I'm not wedded to releng/13.2 and will move to stable/13 instead.