On 30 May 2018, at 04:29, Dan Allen <danalle...@gmail.com> wrote:
> 
> I am building FreeBSD 11 stable i386 on an old Pentium 4 machine.  The 
> clang/llvm build is just horrific in length, so I am substituting gcc by the 
> appropriate /etc/src.conf defines such as WITHOUT_CLANG, 
> WITHOUT_CLANG_BOOTSTRAP, WITH_GCC, WITH_GCC_BOOTSTRAP.
> 
> After deleting clang via make delete-old in /usr/src, all of userland builds 
> fine, but the kernel will not build due to the aesni module.

Hmm, I wonder how you managed to build world, as my build ends with the
following errors:

In file included from /usr/obj/usr/src/tmp/usr/include/ieeefp.h:13,
                 from /usr/src/lib/msun/tests/exponential_test.c:41:
/usr/obj/usr/src/tmp/usr/include/machine/ieeefp.h:111:1: error: "__fldcw" 
redefined
In file included from /usr/src/lib/msun/tests/exponential_test.c:35:
/usr/obj/usr/src/tmp/usr/include/fenv.h:98:1: error: this is the location of 
the previous definition
In file included from /usr/obj/usr/src/tmp/usr/include/ieeefp.h:13,
                 from /usr/src/lib/msun/tests/exponential_test.c:41:
/usr/obj/usr/src/tmp/usr/include/machine/ieeefp.h:112:1: error: "__fldenv" 
redefined
In file included from /usr/src/lib/msun/tests/exponential_test.c:35:
/usr/obj/usr/src/tmp/usr/include/fenv.h:99:1: error: this is the location of 
the previous definition
In file included from /usr/obj/usr/src/tmp/usr/include/ieeefp.h:13,
                 from /usr/src/lib/msun/tests/exponential_test.c:41:
/usr/obj/usr/src/tmp/usr/include/machine/ieeefp.h:114:1: error: "__fnstcw" 
redefined
In file included from /usr/src/lib/msun/tests/exponential_test.c:35:
/usr/obj/usr/src/tmp/usr/include/fenv.h:105:1: error: this is the location of 
the previous definition
In file included from /usr/obj/usr/src/tmp/usr/include/ieeefp.h:13,
                 from /usr/src/lib/msun/tests/exponential_test.c:41:
/usr/obj/usr/src/tmp/usr/include/machine/ieeefp.h:115:1: error: "__fnstenv" 
redefined
In file included from /usr/src/lib/msun/tests/exponential_test.c:35:
/usr/obj/usr/src/tmp/usr/include/fenv.h:104:1: error: this is the location of 
the previous definition
In file included from /usr/obj/usr/src/tmp/usr/include/ieeefp.h:13,
                 from /usr/src/lib/msun/tests/exponential_test.c:41:
/usr/obj/usr/src/tmp/usr/include/machine/ieeefp.h:116:1: error: "__fnstsw" 
redefined
In file included from /usr/src/lib/msun/tests/exponential_test.c:35:
/usr/obj/usr/src/tmp/usr/include/fenv.h:106:1: error: this is the location of 
the previous definition
*** [exponential_test.o] Error code 1

make[6]: stopped in /usr/src/lib/msun/tests
1 error

This is on a cleanly installed 11.2-BETA2, with the following in
/etc/src.conf:

MK_CLANG=no
MK_CLANG_BOOTSTRAP=no
MK_CLANG_EXTRAS=no
MK_CLANG_FULL=no
MK_CLANG_IS_CC=no
MK_GCC=yes
MK_GCC_BOOTSTRAP=yes
MK_GNUCXX=yes
MK_LLD=no
MK_LLD_BOOTSTRAP=no
MK_LLD_IS_LD=no
MK_LLDB=no

It looks like the macros in fenv.h and ieeefp.h are clashing, and Ngie
Cooper worked around it in
https://svnweb.freebsd.org/changeset/base/321483, but for some reason
only for clang.

But even after I applied a band-aid for this, it dies on another part:

--- all_subdir_stand ---
cc1: warnings being treated as errors
/usr/src/stand/i386/gptboot/gptboot.c: In function 'main':
/usr/src/stand/i386/gptboot/gptboot.c:258: warning: declaration of 'autoboot' 
shadows a global declaration
/usr/src/stand/common/bootstrap.h:64: warning: shadowed declaration is here
*** [gptboot.o] Error code 1

make[5]: stopped in /usr/src/stand/i386/gptboot
1 error

Here the warning is right, as 'autoboot' is indeed shadowed, though it
may not be problematic in practice.


> The build break is due to compiling /usr/src/sys/crypto/aesni/aesni_ghash.c, 
> which in turn #includes wmmintrin.h, emmintrin.h, and smmintrin.h which are 
> all clang-specific headers.

In this case, you cannot compile it with gcc-in-base, since it is too
old to have the right intrinsics headers.


> I am rebuilding with MK_CRYPT=no to see if this works around the problem, but 
> it seems like perhaps just this one aesni module should not be built rather 
> than all of CRYPT having to be disabled.

Probably only the module should be disabled, if the version of gcc is
too old.  I have no idea where the needed intrinsics headers were added
upstream.

-Dimitry

Attachment: signature.asc
Description: Message signed with OpenPGP

Reply via email to