Summary: | Serveral references to emmintrin.h fails | ||
---|---|---|---|
Product: | Base System | Reporter: | peo |
Component: | bin | Assignee: | freebsd-bugs (Nobody) <bugs> |
Status: | Closed Unable to Reproduce | ||
Severity: | Affects Only Me | CC: | dewayne, dim, emaste, jpaetzel, vidwer+fbsdbugs |
Priority: | --- | Keywords: | needs-qa |
Version: | 11.2-STABLE | ||
Hardware: | Any | ||
OS: | Any | ||
See Also: |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206179 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190669 |
Description
peo
2019-04-22 09:15:05 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 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 (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) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin root@12:/usr/src # ls /usr/lib/clang/ root@12:/usr/src # (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? (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 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 /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 ;) @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/ Details: FreeBSD 13.0-CURRENT r355582 $ clang -v FreeBSD clang version 9.0.0 (tags/RELEASE_900/final 372316) (based on LLVM 9.0.0) Target: x86_64-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin |