Bug 190669

Comment 1 Thierry Thomas 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 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?

I am also getting this on a system running 

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

(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.

   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 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?

==========  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.)

     ... and setting the (*)WERROR variables has no effect.

Comment 9 Benedict Reuschling 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)

(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.

What happens if you try:

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

and then build world?

(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 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.

(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

(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"
             ^

    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 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 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.

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

(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 2014-11-11 17:02:32 UTC

So did you add WITHOUT_CLANG=yes to /etc/make.conf and then do 'make delete-old'?

(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

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

i fixed it i think, copy the contents of /usr/include/clang/3.3/ to /usr/include and it should work

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

MARKED AS SPAM