Date: Thu, 20 Mar 2014 10:08:48 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net>, John-Mark Gurney <jmg@funkthat.com>, Lev Serebryakov <lev@freebsd.org> Subject: Re: Building with external toolchain was broken 6 months ago with r255187 Message-ID: <201403201008.48610.jhb@freebsd.org> In-Reply-To: <7423EF12-9DD4-4C03-9FF6-7BAAB75820F6@lists.zabbadoz.net> References: <323697891.20140319013757@serebryakov.spb.ru> <20140318220140.GA32089@funkthat.com> <7423EF12-9DD4-4C03-9FF6-7BAAB75820F6@lists.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, March 18, 2014 6:20:50 pm Bjoern A. Zeeb wrote:
>
> On 18 Mar 2014, at 22:01 , John-Mark Gurney <jmg@funkthat.com> wrote:
>
> > Lev Serebryakov wrote this message on Wed, Mar 19, 2014 at 01:37 +0400:
> >> I did't build my NanoBSD images for almost year, and in this time our
> >> not-finished and fragile support for using "external" toolchain is
rotten,
> >> due to r255187 (and, may meb, some other commits too).
> >>
> >> I have very fresh -CURRENT (r263296)
> >>
> >> I have these settings for my buildworld & buildkernel targets:
> >>
> >> XCC=/usr/bin/cc
> >> XCXX=/usr/bin/c++
> >> XCPP=/usr/bin/cpp
> >> XAS=/usr/bin/as
> >> XAR=/usr/bin/ar
> >> XLD=/usr/bin/ld
> >> XNM=/usr/bin/nm
> >> XOBJDUMP=/usr/bin/objdump
> >> XRANLIB=/usr/bin/ranlib
> >> XSTRINGS=/usr/bin/strings
> >> COMPILER_TYPE=clang
> >> WITHOUT_CROSS_COMPILER=yes
> >> WITHOUT_BINUTILS=yes
> >> WITHOUT_CLANG=yes
> >>
> >> It worked 7 months ago. Now it works for "buildworld" but not for
> >> "buildkernel:
> >>
> >> --- aeskeys_amd64.o ---
> >> /usr/bin/cc --sysroot=/data/obj.nano/gateway.v2/data/src/tmp -
B/data/obj.nano/gateway.v2/data/src/tmp/usr/bin -O2 -pipe -fno-strict-aliasing
-Werror -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -
include /data/obj.nano/gateway.v2/data/src/sys/D2500CC/opt_global.h -I. -I@ -
I@/contrib/altq -fno-common -g -fno-omit-frame-pointer -mno-omit-leaf-frame-
pointer -I/data/obj.nano/gateway.v2/data/src/sys/D2500CC -mno-aes -mno-avx -
mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-
asynchronous-unwind-tables -ffreestanding -fstack-protector -std=iso9899:1999
-Qunused-arguments -fstack-protector -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
-Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -
fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-
body -Wno-error-parentheses-equality -Wno-unused-function -c
/data/src/sys/modules/aesni/../../cryp
> > to/aesni/aeskeys_amd64.S
> >> --- aesni_wrap.o ---
> >> In file included from
/data/src/sys/modules/aesni/../../crypto/aesni/aesni_wrap.c:40:
> >> /data/src/sys/modules/aesni/../../crypto/aesni/aesencdec.h:30:10: fatal
error: 'wmmintrin.h' file not found
> >> #include <wmmintrin.h>
> >> ^
> >> 1 error generated.
> >> *** [aesni_wrap.o] Error code 1
> >>
> >> It could not find header file with intrinsics from "system" ("external")
> >> clang. I could disable building of this module with
WITHOUT_MODULES=aesni,
> >> and it works, but what if I need this module?
> >>
> >> Could it be fixed, pleeeeeeease?
> >
> > Sounds like your tool chain doesn't have the necessary support for
> > AES-NI... Are you using gcc as cc? If so, do you have the necessary
> > tool chain work that I did in r255185 in your local tree?
>
>
> The problem is that the kernel is deepening on a compiler header which is
not in the right place in objdir if the compiler is not built. I thought I
had reported this before (maybe just informally). I have been helping myself
locally using this:
No, the compiler should provide a working "wmmintrin.h" header in one of
its built-in paths if it supports the AES instructions. This is akin to
saying that code that uses "stdio.h" should use -I/usr/src/include.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201403201008.48610.jhb>