FreeBSD 11.2-STABLE #0 r344143
Maybe similar to 206179
References to emmintrin.h make both system and port builds to fail.
Building new world today:
c++ -O2 -pipe -I/usr/obj/usr/src/tmp/usr/src/lib/clang/libclang -I/usr/obj/usr/src/tmp/usr/src/lib/clang/libllvm -I/usr/src/contrib/llvm/tools/clang/lib/Basic -I/usr/src/contrib/llvm/tools/clang/lib/Driver -I/usr/src/contrib/llvm/tools/clang/include -I/usr/src/lib/clang/include -I/usr/src/contrib/llvm/include -DLLVM_BUILD_GLOBAL_ISEL -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.2\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.2\" -DDEFAULT_SYSROOT=\"/usr/obj/usr/src/tmp\" -DLLVM_TARGET_ENABLE_AARCH64 -DLLVM_TARGET_ENABLE_ARM -DLLVM_TARGET_ENABLE_MIPS -DLLVM_TARGET_ENABLE_POWERPC -DLLVM_TARGET_ENABLE_SPARC -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 -MD -MF.depend.Basic_Targets.o -MTBasic/Targets.o -Qunused-arguments -include ../freebsd_cc_version.h -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -c /usr/src/contrib/llvm/tools/clang/lib/Basic/Targets.cpp -o Basic/Targets.o
--- Basic/SourceManager.o ---
/usr/src/contrib/llvm/tools/clang/lib/Basic/SourceManager.cpp:1195:10: fatal error: 'emmintrin.h' file not found
1 error generated.
*** [Basic/SourceManager.o] Error code 1
Can you add the output of:
% clang --version
% ls /usr/lib/clang/
emmintrin.h should be in /usr/lib/clang/<version>/include/emmintrin.h
Too late I'm afraid, in the middle of an update to my precious home workstation.
What I did after the failing builds
Made sure that I had not run make delete-old and delete-old-libs after the normal update steps - confirmed - it was done after a Feb 15 update.
I am positive I did not rm anything manually
Ran svnlite up /usr/src again
Tried make buildworld again - failed
Checked /usr/lib/clang/ - empty!
Did cp -Rp /usr/local/llvm<version>/lib/clang/ /usr/lib/clang
Then everything worked fine - I suppose we have to assume I *did* something, however, I cannot see what it was unfortunately. This bug can probably be closed unless someone else have similar problems.
There is a message on todays freebsd-stable from firstname.lastname@example.org exactly what I experienced.
Thank you for your time,
FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM 8.0.0)
Thread model: posix
6.0.1 7.0.1 8.0.0
(In reply to peo from comment #2)
Thanks for the update.
This comes up every now and then so there must be come common set of steps/process that folks are following that leads to this case.
I have a system in this state doing an update from stable/12 to HEAD if you want to chase this to ground.
root@12:/usr/src # clang --version
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)
Thread model: posix
root@12:/usr/src # ls /usr/lib/clang/
(In reply to Josh Paetzel from comment #5)
> root@12:/usr/src # clang --version
> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM
> Target: x86_64-unknown-freebsd12.0
> Thread model: posix
> InstalledDir: /usr/bin
> root@12:/usr/src # ls /usr/lib/clang/
> root@12:/usr/src #
Right, but the actual question is: how did it get into this state? After a normal installation, this directory should exist, and it should have the clang internal headers under (in this case) a subdirectory 6.0.1.
Is this when people install a system using WITHOUT_CLANG, and then copy a /usr/bin/clang executable by hand onto it, or something?
(In reply to Dimitry Andric from comment #6)
I ran into this before on a frankeninstall where I did a make install in usr.bin/clang but not lib/clang (i.e., I had some 11.x installation but tried installing just the new compiler from a stable/11 build).
In my case this system has an empty /etc/src-conf and /etc/make.conf with the exception of META_MODE and was following head until stable/12 branched, I followed stable/12 for a while and am now trying to get it to head again.
(In reply to Ed Maste from comment #3)
To your question, I suspect that while folks perform a tidy-up of their environment, you know like "cd /usr/src && make delete-old" they proceed with something like "find -anewer /usr/lib/ -delete;" which inadvertently blows away the /usr/lib/clang/$VER/include - ta dah, kaput!
I know, because its a curse being tidy! ;)
If this happens to you, here's a hint do NOT copy
because you'll duplicate things like stddef.h and the compile will fail. You might be able to get by with just copying *intrin.h, but I was impatient.
I know this is tedious but much better to either:
- read the Makefile to identify only what you need; or
It really threw me to find that the build required something outside either /usr/obj or /usr/src. Learning something new everyday... Hmm I wonder why
pkg-static isn't part of a buildworld, I do after all build from source; perhaps, for tomorrow ;)
@peo What happens when you run 'make -k buildworld'?
(In reply to vidwer+fbsdbugs from comment #11)
I have had the same problem by running 'make delete-old' before installing newer files created by buildworld.
/usr/lib/clang/9.0.0/include/ thus was nonexistent/empty, and should contain: emmintrin.h mm_malloc.h mmintrin.h xmmintrin.h
These header files were extracted from base.txz which was downloaded from https://download.freebsd.org/ftp/snapshots/amd64/13.0-CURRENT/
FreeBSD 13.0-CURRENT r355582
$ clang -v
FreeBSD clang version 9.0.0 (tags/RELEASE_900/final 372316) (based on LLVM 9.0.0)
Thread model: posix