Bug 237461 - Serveral references to emmintrin.h fails
Summary: Serveral references to emmintrin.h fails
Status: Closed Unable to Reproduce
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 11.2-STABLE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2019-04-22 09:15 UTC by peo
Modified: 2019-09-11 09:26 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description peo 2019-04-22 09:15:05 UTC
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
#include <emmintrin.h>
         ^~~~~~~~~~~~~
1 error generated.
*** [Basic/SourceManager.o] Error code 1
Comment 1 Ed Maste freebsd_committer 2019-04-22 15:12:54 UTC
Can you add the output of:

% clang --version
% ls /usr/lib/clang/

emmintrin.h should be in /usr/lib/clang/<version>/include/emmintrin.h
Comment 2 peo 2019-04-22 15:35:39 UTC
Too late I'm afraid, in the middle of an update to my precious home workstation.

What I did after the failing builds

Read https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190669
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 eu9gu4@gmail.com exactly what I experienced.

Thank you for your time,

//per

clang --version:
FreeBSD clang version 8.0.0 (tags/RELEASE_800/final 356365) (based on LLVM 8.0.0)
Target: x86_64-unknown-freebsd11.2
Thread model: posix
InstalledDir: /usr/bin

ls /usr/lib/clang/
6.0.1   7.0.1   8.0.0
Comment 3 Ed Maste freebsd_committer 2019-04-22 16:09:49 UTC
(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.
Comment 4 Josh Paetzel freebsd_committer 2019-07-23 22:32:09 UTC
I have a system in this state doing an update from stable/12 to HEAD if you want to chase this to ground.
Comment 5 Josh Paetzel freebsd_committer 2019-07-23 22:46:41 UTC
root@12:/usr/src # clang --version
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)
Target: x86_64-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin
root@12:/usr/src # ls /usr/lib/clang/
root@12:/usr/src #
Comment 6 Dimitry Andric freebsd_committer 2019-07-24 05:53:08 UTC
(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
> 6.0.1)
> 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?
Comment 7 Ed Maste freebsd_committer 2019-07-24 13:39:14 UTC
(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).
Comment 8 Josh Paetzel freebsd_committer 2019-07-24 15:53:44 UTC
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.
Comment 9 Josh Paetzel freebsd_committer 2019-07-24 15:53:55 UTC
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.
Comment 10 dewayne 2019-09-11 09:26:03 UTC
(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 
/usr/src/contrib/llvm/tools/clang/lib/Headers/
into /usr/lib/clang/$VER/include 
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 
- /usr/obj/usr/src/i386.i386/tmp/usr/lib/clang/8.0.1/include/*

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 ;)