Bug 190669 - 'emmintrin.h' file not found - in /usr/src/lib/clang/libclangbasic
Summary: 'emmintrin.h' file not found - in /usr/src/lib/clang/libclangbasic
Status: Closed Not A Bug
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 10.0-STABLE
Hardware: Any Any
: Normal Affects Many People
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-05 20:00 UTC by Thierry Thomas
Modified: 2019-04-22 09:28 UTC (History)
9 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thierry Thomas freebsd_committer 2014-06-05 20:00:03 UTC
Make buildworld failed on 10.0-STABLE amd64.
	See message:

--- mw.out begins here ---

8<	8<	8<

clang-tblgen -gen-clang-diags-defs -clang-component=Comment  -I /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic -d DiagnosticCommentKinds.inc.d  -o DiagnosticCommentKinds.inc.h /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td
clang-tblgen -gen-clang-diags-defs -clang-component=Common  -I /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic -d DiagnosticCommonKinds.inc.d  -o DiagnosticCommonKinds.inc.h /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td
clang-tblgen -gen-clang-diags-defs -clang-component=Driver  -I /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic -d DiagnosticDriverKinds.inc.d  -o DiagnosticDriverKinds.inc.h /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td
clang-tblgen -gen-clang-diags-defs -clang-component=Frontend  -I /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic -d DiagnosticFrontendKinds.inc.d  -o DiagnosticFrontendKinds.inc.h /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td
clang-tblgen -gen-clang-diag-groups  -I /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic -d DiagnosticGroups.inc.d  -o DiagnosticGroups.inc.h /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td
clang-tblgen -gen-clang-diags-index-name  -I /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic -d DiagnosticIndexName.inc.d  -o DiagnosticIndexName.inc.h /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td
clang-tblgen -gen-clang-diags-defs -clang-component=Lex  -I /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic -d DiagnosticLexKinds.inc.d  -o DiagnosticLexKinds.inc.h /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td
clang-tblgen -gen-clang-diags-defs -clang-component=Parse  -I /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic -d DiagnosticParseKinds.inc.d  -o DiagnosticParseKinds.inc.h /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td
clang-tblgen -gen-clang-diags-defs -clang-component=Sema  -I /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic -d DiagnosticSemaKinds.inc.d  -o DiagnosticSemaKinds.inc.h /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td
clang-tblgen -gen-clang-diags-defs -clang-component=Serialization  -I /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic -d DiagnosticSerializationKinds.inc.d  -o DiagnosticSerializationKinds.inc.h /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td
clang-tblgen -gen-arm-neon-sema  -d arm_neon.inc.d -o arm_neon.inc.h /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/arm_neon.td
rm -f .depend
CC='/usr/local/libexec/ccache/world/cc --sysroot=/usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/bin' mkdep -f .depend -a    -I/usr/src/lib/clang/libclangbasic/../../../contrib/llvm/include -I/usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic -I. -I/usr/src/lib/clang/libclangbasic/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DNDEBUG -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_REWRITER -DCLANG_ENABLE_STATIC_ANALYZER -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd10.0\" -DDEFAULT_SYSROOT=\"\"        /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Builtins.cpp /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/CharInfo.cpp /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Bas
 ic/Diagn
 ostic.cpp /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/DiagnosticIDs.cpp /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/FileManager.cpp /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/FileSystemStatCache.cpp /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/IdentifierTable.cpp /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/LangOptions.cpp /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Module.cpp /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/ObjCRuntime.cpp /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/OpenMPKinds.cpp /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/OperatorPrecedence.cpp /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/SourceLocation.cpp /usr/src/lib/clang/libclangbas
 ic/../..
 /../contrib/llvm/tools/clang/lib/Basic/SourceManager.cpp /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/TargetInfo.cpp /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Targets.cpp /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/TokenKinds.cpp /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Version.cpp /usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/VersionTuple.cpp 
/usr/src/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/SourceManager.cpp:1208:10: fatal error:
      'emmintrin.h' file not found
#include <emmintrin.h>
         ^
error generated.
mkdep: compile failed
*** Error code 1

Stop.
make: stopped in /usr/src/lib/clang/libclangbasic
*** Error code 1

Stop.
make: stopped in /usr/src/lib/clang
*** Error code 1

Stop.
make: stopped in /usr/src/lib
*** Error code 1

Stop.
make: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src

Script done on Thu Jun  5 20:21:41 2014
--- mw.out ends here ---

Environment:
System: FreeBSD graf.pompo.net 10.0-STABLE FreeBSD 10.0-STABLE #0 r266396: Sun May 18 14:03:05 CEST 2014 thierry@graf.pompo.net:/usr/obj/usr/src/sys/GRAF140430 amd64

How-To-Repeat:
Source got from svn, latest revision 267117,
	cd /usr/src
	make buildworld

Fix:
N/A
Comment 1 Thierry Thomas freebsd_committer 2014-06-05 21:13:13 UTC
Source had been fetched via svn, latest revision is r267113 on 2014-06-05 17:21:25 +0200.
Comment 2 Thierry Thomas freebsd_committer 2014-06-05 21:51:03 UTC
Note: the build is fixed by setting -DNOCCACHE (I'm using ccache).
Thus a possible fix might be to undef CCACHE where it is'nt supported?
Comment 3 roberthuff 2014-06-15 03:59:57 UTC
I am also getting this on a system running 

FreeBSD 11.0-CURRENT #1 r264673: Sat Apr 19 09:43:10 EDT 2014  amd64
Comment 4 roberthuff 2014-06-15 04:01:36 UTC
(In reply to roberthuff from comment #3)
> I am also getting this on a system running 
> 
> FreeBSD 11.0-CURRENT #1 r264673: Sat Apr 19 09:43:10 EDT 2014  amd64

     (sorry - butterfingers)
     And I am not running any kind of caching.
Comment 5 roberthuff 2014-06-15 23:00:52 UTC
   And it's not just about base.  As of r375825 of ports, I am unable to build:

     devel/boost-libs
     graphics/opencv-core
     mail/thunderbird
     www/firefox
        /seamonkey
        /libxul

     due to "missing" {emmintrin.h , xmmintrin.h}.
Comment 6 Benedict Reuschling freebsd_committer 2014-06-19 11:29:59 UTC
I had the same issue on my 10-STABLE box when doing buildworld. Disabling the CCACHE fixed the issue for me. However, before that, I also made some changes to /etc/src.conf which might be helpful in your case (since you mentioned not using any compile caching):

NO_WERROR=
WERROR=

Can you try those and see whether they fix your problem?
What do you have in your /etc/make.conf and /etc/src.conf?
Comment 7 roberthuff 2014-06-19 12:10:07 UTC
==========  src.conf

KERNCONF="JERUSALEM"
WITH_LIBICONV_COMPAT="yes"


=========  make.conf

BDBCFLAGS+=		-O -pipe
DEBUG_FLAGS+=		-gdwarf-2
STRIP= 
SYMVER_ENABLED=	yes
X_WINDOW_SYSTEM=	xorg
HAVE_MOTIF=		yes

NO_BIND_ETC=   true    # Do not install files to /etc/namedb
NO_BLUETOOTH=  true    # do not build Bluetooth related stuff
MK_PROFILE=    false    # Avoid compiling profiled libraries

SENDMAIL_CFLAGS+=	-I/usr/local/include/ -DSASL=2
SENDMAIL_LDFLAGS+=	-L/usr/local/lib
SENDMAIL_LDADD+=	-lsasl2

CUPS_OVERWRITE_BASE=	yes
NO_LPR=			true

OVERRIDE_LINUX_BASE_PORT=f10
OVERRIDE_LINUX_NONBASE_PORTS=f10

WITH_MOZILLA=		libxul
WITH_GECKO=		libxul

WITH_BERKELEYDB=db6
WITH_BDB_VER=6
WANT_OPENLDAP_VER=24
WANT_OPENLDAP_SASL=true

SAMBA_ENABLE=YES

WITH_NEW_XORG="yes"
WITH_GALLIUM="yes"

WITH_BSD_SORT=

WITH_PKGNG=yes


==============

     I checked the script that runs "make buildworld", and it's had "-DNOCACHE" for at least the last week.  (I think someone elsewhere suggested the same thing.)
Comment 8 roberthuff 2014-06-19 15:56:05 UTC
     ... and setting the (*)WERROR variables has no effect.
Comment 9 Benedict Reuschling freebsd_committer 2014-06-19 17:16:13 UTC
Try this then:
- update to the latest sources from svn
- erase everything under /usr/obj/
- start with an empty /etc/make.conf (although the one you posted seems fine to me)
Comment 10 roberthuff 2014-06-19 21:00:11 UTC
(In reply to Benedict Reuschling from comment #9)
> Try this then:
> - update to the latest sources from svn
> - erase everything under /usr/obj/
> - start with an empty /etc/make.conf (although the one you posted seems fine
> to me)

     Did all of these.
     Same result.
Comment 11 Nils Beyer 2014-06-25 10:14:16 UTC
What happens if you try:

    cd /usr/include/clang
    ln -s 3.4.1 3.4

and then build world?
Comment 12 roberthuff 2014-06-25 13:53:36 UTC
(In reply to Nils Beyer from comment #11)

> What happens if you try:
> 
>     cd /usr/include/clang
>     ln -s 3.4.1 3.4
> 
> and then build world?

     "/usr/include/clang" is empty.
     Did some digging and found this in /usr/src/ObsoleteFiles.inc:

# 20140512: new clang import which bumps version from 3.4 to 3.4.1.
OLD_FILES+=usr/include/clang/3.4/__wmmintrin_aes.h
OLD_FILES+=usr/include/clang/3.4/__wmmintrin_pclmul.h
OLD_FILES+=usr/include/clang/3.4/altivec.h
OLD_FILES+=usr/include/clang/3.4/ammintrin.h
OLD_FILES+=usr/include/clang/3.4/avx2intrin.h
OLD_FILES+=usr/include/clang/3.4/avxintrin.h
OLD_FILES+=usr/include/clang/3.4/bmi2intrin.h
OLD_FILES+=usr/include/clang/3.4/bmiintrin.h
OLD_FILES+=usr/include/clang/3.4/cpuid.h
OLD_FILES+=usr/include/clang/3.4/emmintrin.h
OLD_FILES+=usr/include/clang/3.4/f16cintrin.h
OLD_FILES+=usr/include/clang/3.4/fma4intrin.h
OLD_FILES+=usr/include/clang/3.4/fmaintrin.h
OLD_FILES+=usr/include/clang/3.4/immintrin.h
OLD_FILES+=usr/include/clang/3.4/lzcntintrin.h

     Is this somehow related, given the system is

FreeBSD 11.0-CURRENT #1 r264673: Sat Apr 19 09:43:10 EDT 2014  amd64 

    ?
    If not: where do I find contents for that directory?  I have a 10.0 cd, but that only has (/usr/include/clang/)3.3 and I have not been able to find 3.4 anywhere.  Is it dynamically generated by the clang build process?
Comment 13 Benedict Reuschling freebsd_committer 2014-06-25 13:59:20 UTC
You could install lang/clan34 or lang/clang-devel from ports/pkg. That should get you the required files.
Comment 14 Nils Beyer 2014-06-25 14:04:55 UTC
(In reply to roberthuff from comment #12)
>     If not: where do I find contents for that directory?

You can copy the content of

    /usr/src/contrib/llvm/tools/clang/lib/Headers

to

    /usr/include/clang/3.4.1
resp.
    /usr/include/clang/3.4
Comment 15 roberthuff 2014-06-25 15:05:57 UTC
(In reply to Nils Beyer from comment #14)
> (In reply to roberthuff from comment #12)
> >     If not: where do I find contents for that directory?
> 
> You can copy the content of
> 
>     /usr/src/contrib/llvm/tools/clang/lib/Headers
> 
> to
> 
>     /usr/include/clang/3.4.1
> resp.
>     /usr/include/clang/3.4

     Doing this, and running 

     rm -f /usr/obj
     make -v cleandir
     make -d l -DNOCACHE buildworld

     produces:

echo ">>> stage 1.2: bootstrap tools"
>>> stage 1.2: bootstrap tools
echo "--------------------------------------------------------------"
--------------------------------------------------------------
cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj/usr/src/tmp  INSTALL="sh /usr/src/tools/install.sh"  PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/usr/games:/usr/obj/usr/src/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin  WORLDTMP=/usr/obj/usr/src/tmp  VERSION="FreeBSD 11.0-CURRENT amd64 1100023"  MAKEFLAGS="-m /usr/src/tools/build/mk  -d l -D NOCACHE -m /usr/src/share/mk" make  -f Makefile.inc1  DESTDIR=  BOOTSTRAPPING=1100019  SSP_CFLAGS= MK_PIE=no  MK_HTML=no MK_INFO=no NO_LINT=yes MK_MAN=no  -DNO_PIC MK_PROFILE=no -DNO_SHARED  -DNO_CPU_CFLAGS MK_WARNS=no MK_CTF=no  MK_CLANG_FULL=no MK_LLDB=no MK_TESTS=no bootstrap-tools
echo "===> lib/clang/libllvmsupport (obj,depend,all,install)";  cd /usr/src/lib/clang/libllvmsupport &&  make DIRPRFX=lib/clang/libllvmsupport/ obj &&  make DIRPRFX=lib/clang/libllvmsupport/ depend &&  make DIRPRFX=lib/clang/libllvmsupport/ all &&  make DIRPRFX=lib/clang/libllvmsupport/ DESTDIR=/usr/obj/usr/src/tmp/legacy install
===> lib/clang/libllvmsupport (obj,depend,all,install)
if ! test -d /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmsupport/; then  mkdir -p /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmsupport;  if ! test -d /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmsupport/; then  echo "Unable to create /usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmsupport.";  exit 1;  fi;  echo "/usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmsupport created for /usr/src/lib/clang/libllvmsupport";  fi
/usr/obj/usr/src/tmp/usr/src/lib/clang/libllvmsupport created for /usr/src/lib/clang/libllvmsupport
rm -f .depend
mkdep -f .depend -a    -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/tools/clang/include -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support -I. -I/usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\" -I/usr/obj/usr/src/tmp/legacy/usr/include -std=gnu99   /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/ConvertUTF.c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regcomp.c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regerror.c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regexec.c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regfree.c /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/regstrlcpy.c
/usr/include/clang/3.4/module.map:12:14: error: header 'arm_neon.h' not found
      header "arm_neon.h"
             ^
Comment 16 roberthuff 2014-06-25 15:57:19 UTC
    The problem is not that the file isn't there:

huff@>> find /usr/src -name emmiintrin.h
/usr/src/contrib/gcc/config/i386/emmintrin.h
/usr/src/contrib/llvm/tools/clang/lib/Headers/emmintrin.h
huff@>>

     The problem is the buildworld bootstrap process, which - as I understand it - shouldn't depend on anything outside itself except a working C/C++ compiler, can't find a .h which is part of the buildworld environment.
     Am I wrong?
Comment 17 John Baldwin freebsd_committer freebsd_triage 2014-07-01 17:24:19 UTC
Did you run 'make delete-old' after doing an 'svn up' but before doing a 'make buildworld'?  It's odd that /usr/include/clang is empty.  That should not be empty normally.  However, if you ran 'make delete-old' after the clang 3.4 -> 3.4.1 upgrade before doing a buildworld/installworld, delete-old would delete /usr/include/clang/3.4 but you wouldn't have the new /usr/include/clang/3.4.1 yet.  You can try coping the headers you put in /usr/include/clang/3.4.1 to /usr/include/clang/3.4 for now to get your buildworld re-bootstrapped if so.
Comment 18 Thierry Thomas freebsd_committer 2014-07-05 15:44:55 UTC
@jhb: as the original submitter, I use to run `make delete-old' after `make installworld', i.e. before the next update, and my problem was clearly related to ccache.

But it seems that other peoples encountered the same problem without using ccache, and I cannot answer for them.
Comment 19 Chris Hutchinson 2014-11-07 06:42:47 UTC
I find myself struggling with what looks like the same issue
on a recent 11-CURRENT install
(11-CURRENT #1 amd64 r274134 Nov 5 12:56:14 PST 2014)
svn info /usr/ports Revision: 372176

As you can see, I've built and installed kernel/world.
I did, perform a make delete-old, following the install
world. Which removed the clang that was delivered from the
base install on the bootonly iso. However, I have
installed lang/gcc-48, which does have xmmintrin.h
in it's include tree. It is also my understanding that
clang isn't mandatory. But I seem to have no end of
problems with ports looking for, and subsequently not
finding xmmintrin.h. Even though it's an included header
with lang/gcc-48. Where lies the problem? I should also
probably note; I haven't [intentionally] enabled, or
used ccache.

Thank you for all your time, and consideration.

--Chris
Comment 20 Chris Hutchinson 2014-11-07 21:29:02 UTC
(In reply to C Hutchinson from comment #19)
> I find myself struggling with what looks like the same issue
> on a recent 11-CURRENT install
> (11-CURRENT #1 amd64 r274134 Nov 5 12:56:14 PST 2014)
> svn info /usr/ports Revision: 372176
> 
> As you can see, I've built and installed kernel/world.
> I did, perform a make delete-old, following the install
> world. Which removed the clang that was delivered from the
> base install on the bootonly iso. However, I have
> installed lang/gcc-48, which does have xmmintrin.h
> in it's include tree. It is also my understanding that
> clang isn't mandatory. But I seem to have no end of
> problems with ports looking for, and subsequently not
> finding xmmintrin.h. Even though it's an included header
> with lang/gcc-48. Where lies the problem? I should also
> probably note; I haven't [intentionally] enabled, or
> used ccache.
> 
> Thank you for all your time, and consideration.
> 
> --Chris

OK. For me, and given that I followed my make installworld by a
make delete-old. I shouldn't have been surprised that while doing
so, did remove clang. It shouldn't remove what's in /usr/bin. As
the default toolchain for 10+ _is_ clang. So my problem stemmed
from the fact that /usr/bin is searched _prior_ to /usr/local/bin
where my gcc48 is located. Adding the appropriate directives
in make.conf(5) gave me the (g)cc environment I needed to get
past the errors mentioned above. By me, and by others.

Thanks, and sorry for any noise.

--Chris
Comment 21 John Baldwin freebsd_committer freebsd_triage 2014-11-11 17:02:32 UTC
So did you add WITHOUT_CLANG=yes to /etc/make.conf and then do 'make delete-old'?
Comment 22 Chris Hutchinson 2014-11-11 18:49:50 UTC
(In reply to John Baldwin from comment #21)
> So did you add WITHOUT_CLANG=yes to /etc/make.conf and then do 'make
> delete-old'?

I had already had WITHOUT_CLANG=true in make.conf, prior to
make build/install world. Just for clarity:
make.conf
WITHOUT_CLANG=true
FAVORITE_COMPILER=gcc

src.conf
WITHOUT_CLANG=true

For the record, I *believe* WITHOUT_CLANG *only* belongs in src.conf,
but I digress.

So with the above. I prformed:
make buildworld
make buildkernel KERNCONF...
make installkernel KERNCONF...
reboot into single user
make installworld
maegemaster
make delete-old

That's the whole of it. Hope this helps.

--Chris
Comment 23 Roger Leigh 2015-06-19 21:10:49 UTC
Hi,

Just for the record, I'm running into a failure to build the latest Boost (1.58) due to emmintrin.h being missing (bootstrapped with the 'clang' toolset):

/tmp/boost-install/include/boost/math/special_functions/detail/lanczos_sse2.hpp:13:10: fatal error: 'emmintrin.h' file not found
#include <emmintrin.h>

% find / -name emmintrin.h
/usr/include/clang/3.3/emmintrin.h
/usr/local/lib/gcc48/gcc/x86_64-portbld-freebsd10.1/4.8.4/include/emmintrin.h

There's a copy installed for clang 3.3, but it's missing for 3.4.  In fact, /usr/include/clang/3.4 doesn't exist at all.  This is with 10.1-RELEASE.  Is there any possibility of this being corrected in a point update?

Note that this is present when I install the clang34 port:
/usr/local/llvm34/lib/clang/3.4.2/include/emmintrin.h
(this includes all the headers missing from the base version)


Thanks,
Roger
Comment 24 j maser 2015-07-30 12:20:10 UTC
i fixed it i think, copy the contents of /usr/include/clang/3.3/ to /usr/include and it should work
Comment 25 Roger Leigh 2015-08-14 10:15:33 UTC
Seems fixed in current 10.1-RELEASE and 10.2-RELEASE?

I see /usr/include/clang/3.4.1/emmintrin.h is present on both after updating.
Comment 26 John Baldwin freebsd_committer freebsd_triage 2015-08-14 17:47:54 UTC
Nothing has changed in stable/10, and AFAIK, /usr/include/clang/<foo> headers should always be installed correctly.  I can't think of any good reason for those headers to go missing except for an errant rm or running 'make delete-old' before 'make buildworld/installworld' after updating /usr/src.

The CCACHE case is different as that one is probably due to the cache needing to be invalidated on each compiler version upgrade since the headers move each time (the version number is in the path).