Re: External toolchain support broken for devel/llvm38 but not devel/llvm37
On Tue, Aug 30, 2016 at 02:50:03PM -0700, Matthew Macy wrote: > > > > On Tue, 30 Aug 2016 14:08:41 -0700 Brooks Davis> wrote > > On Mon, Aug 29, 2016 at 08:12:08PM -0700, Matthew Macy wrote: > > > It looks like there is something broken with the devel/llvm38 port or > external toolchain support has regressed: > > > > > > > > > This works: > > > make XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37 > XCPP=/usr/local/bin/clang-cpp37 buildworld -j12 -s > > > > > > This fails: > > > make XCC=/usr/local/bin/clang38 XCXX=/usr/local/bin/clang++38 > XCPP=/usr/local/bin/clang-cpp38 buildworld -j12 -s > > > > > > with: > > > > > > > /home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/bin/ld: > > /usr/local/llvm38/bin/../lib/clang/3.8.1/lib/freebsd/libclang_rt.ubsan_standalone-x86_64.a: > No such file: No such file or directory > > > clang-3.8: error: linker command failed with exit code 1 (use -v to see > invocation) > > > > I've fixed the install problem. I'm rather confused about why clang > > would try to link with sanitizer libraries when building source. That's > > certainly not default behavior. > > Thanks for the extremely prompt response to both issues. I haven't figured > out why svn has problems but the libc/tests failure can be traced back to the > following commit: > > commit 3d2a537705eca33db3c523f4f92290d382aa7ab1 > Author: ngie > Date: Fri Jan 2 05:40:02 2015 + > > Don't install h_raw if dealing with clang 3.5.0+ to unbreak the tests2 > Jenkins > job > > The h_raw application doesn't do proper bounds checking without the option > being supplied via the build, which means that it doesn't throw signals > and > fail as expected > > PR: 196430 > X-MFC with: r276479 > > diff --git a/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh > b/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh > index 04adc67..362178f 100755 > --- a/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh > +++ b/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh > @@ -360,6 +360,9 @@ raw_head() > raw_body() > { > prog="$(atf_get_srcdir)/h_raw" > + # Begin FreeBSD > + [ -x $prog ] || atf_skip "$prog is missing; skipping testcase" > + # End FreeBSD > > h_pass "$prog 9" > # Begin FreeBSD > diff --git a/lib/libc/tests/ssp/Makefile b/lib/libc/tests/ssp/Makefile > index 1649cc2..7bc8660 100644 > --- a/lib/libc/tests/ssp/Makefile > +++ b/lib/libc/tests/ssp/Makefile > @@ -9,10 +9,7 @@ WARNS?=2 > > CFLAGS.h_raw+= -fstack-protector-all -Wstack-protector > .if ${COMPILER_TYPE} == "clang" > -# Disable -fsanitize=bounds until runtime support is done for clang 3.5.0. > -.if ${COMPILER_VERSION} < 30500 > CFLAGS.h_raw+= -fsanitize=bounds > -.endif Thanks for hunting this down. There's no strong reason to assume that a given clang has sanitizers available. In the current build system, you need a clang tree to build the sanitizers, but the build process is separate. If we're going to enable sanitizers in tests, we need to do so conditionally so we don't break the tests on non-x86 systems and so compiler installs don't need to provide them. -- Brooks signature.asc Description: PGP signature
Re: External toolchain support broken for devel/llvm38 but not devel/llvm37
On Tue, 30 Aug 2016 14:08:41 -0700 Brooks Daviswrote > On Mon, Aug 29, 2016 at 08:12:08PM -0700, Matthew Macy wrote: > > It looks like there is something broken with the devel/llvm38 port or > > external toolchain support has regressed: > > > > > > This works: > > make XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37 > > XCPP=/usr/local/bin/clang-cpp37 buildworld -j12 -s > > > > This fails: > > make XCC=/usr/local/bin/clang38 XCXX=/usr/local/bin/clang++38 > > XCPP=/usr/local/bin/clang-cpp38 buildworld -j12 -s > > > > with: > > > > /home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/bin/ld: > > > > /usr/local/llvm38/bin/../lib/clang/3.8.1/lib/freebsd/libclang_rt.ubsan_standalone-x86_64.a: > > No such file: No such file or directory > > clang-3.8: error: linker command failed with exit code 1 (use -v to see > > invocation) > > I've fixed the install problem. I'm rather confused about why clang > would try to link with sanitizer libraries when building source. That's > certainly not default behavior. Thanks for the extremely prompt response to both issues. I haven't figured out why svn has problems but the libc/tests failure can be traced back to the following commit: commit 3d2a537705eca33db3c523f4f92290d382aa7ab1 Author: ngie Date: Fri Jan 2 05:40:02 2015 + Don't install h_raw if dealing with clang 3.5.0+ to unbreak the tests2 Jenkins job The h_raw application doesn't do proper bounds checking without the option being supplied via the build, which means that it doesn't throw signals and fail as expected PR: 196430 X-MFC with: r276479 diff --git a/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh b/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh index 04adc67..362178f 100755 --- a/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh +++ b/contrib/netbsd-tests/lib/libc/ssp/t_ssp.sh @@ -360,6 +360,9 @@ raw_head() raw_body() { prog="$(atf_get_srcdir)/h_raw" + # Begin FreeBSD + [ -x $prog ] || atf_skip "$prog is missing; skipping testcase" + # End FreeBSD h_pass "$prog 9" # Begin FreeBSD diff --git a/lib/libc/tests/ssp/Makefile b/lib/libc/tests/ssp/Makefile index 1649cc2..7bc8660 100644 --- a/lib/libc/tests/ssp/Makefile +++ b/lib/libc/tests/ssp/Makefile @@ -9,10 +9,7 @@ WARNS?=2 CFLAGS.h_raw+= -fstack-protector-all -Wstack-protector .if ${COMPILER_TYPE} == "clang" -# Disable -fsanitize=bounds until runtime support is done for clang 3.5.0. -.if ${COMPILER_VERSION} < 30500 CFLAGS.h_raw+= -fsanitize=bounds -.endif .elif ${COMPILER_TYPE} == "gcc" CFLAGS.h_raw+= --param ssp-buffer-size=1 DPADD+=${LIBSSP} @@ -29,7 +26,11 @@ PROGS+= h_getcwd PROGS+=h_memcpy PROGS+=h_memmove PROGS+=h_memset +# This testcase doesn't run properly when not compiled with -fsantize=bounds +# with clang, which is currently contingent on a compiler_rt update +.if ${COMPILER_TYPE} == "clang" && ${COMPILER_VERSION} < 30500 PROGS+=h_raw +.endif PROGS+=h_read PROGS+=h_readlink PROGS+=h_snprintf ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: External toolchain support broken for devel/llvm38 but not devel/llvm37
On Mon, Aug 29, 2016 at 08:12:08PM -0700, Matthew Macy wrote: > It looks like there is something broken with the devel/llvm38 port or > external toolchain support has regressed: > > > This works: > make XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37 > XCPP=/usr/local/bin/clang-cpp37 buildworld -j12 -s > > This fails: > make XCC=/usr/local/bin/clang38 XCXX=/usr/local/bin/clang++38 > XCPP=/usr/local/bin/clang-cpp38 buildworld -j12 -s > > with: > > /home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/bin/ld: > > /usr/local/llvm38/bin/../lib/clang/3.8.1/lib/freebsd/libclang_rt.ubsan_standalone-x86_64.a: > No such file: No such file or directory > clang-3.8: error: linker command failed with exit code 1 (use -v to see > invocation) I've fixed the install problem. I'm rather confused about why clang would try to link with sanitizer libraries when building source. That's certainly not default behavior. -- Brooks signature.asc Description: PGP signature
Re: External toolchain support broken for devel/llvm38 but not devel/llvm37
On Monday, August 29, 2016, Volodymyr Kostyrkowrote: > Matthew Macy wrote: > >> It looks like there is something broken with the devel/llvm38 port or >> external toolchain support has regressed: >> >> >> This works: >> make XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37 >> XCPP=/usr/local/bin/clang-cpp37 buildworld -j12 -s >> >> This fails: >> make XCC=/usr/local/bin/clang38 XCXX=/usr/local/bin/clang++38 >> XCPP=/usr/local/bin/clang-cpp38 buildworld -j12 -s >> >> with: >> >> /home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/bin/ld: >> /usr/local/llvm38/bin/../lib/clang/3.8.1/lib/freebsd/libclan >> g_rt.ubsan_standalone-x86_64.a: No such file: No such file or directory >> clang-3.8: error: linker command failed with exit code 1 (use -v to see >> invocation) >> > > I second this - I also faced it. I think this is not a problem with a > ports but rather with a build as correspondent files can be found in > /usr/obj under /usr/obj/usr/src/tmp/usr/lib/clang/3.8.0/lib/freebsd/. > Looks like this files are compiled during build but taken from compilers's > directory. Linking 'em to the target directory makes build succeed. The point of using the external toolchain for me is to bypass building clang in src. ~31 of the ~47 minutes in buildworld are spent compiling pieces of llvm/clang. I'd much rather fix the ports than make buildworld require additional work. For the moment I've disconnected the two pieces that fail: svn and libc/tests. They don't really belong in base any more than git and piglit do. > > -- > Sphinx of black quartz judge my vow. > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: External toolchain support broken for devel/llvm38 but not devel/llvm37
On 30 Aug 2016, at 05:12, Matthew Macywrote: > > It looks like there is something broken with the devel/llvm38 port or > external toolchain support has regressed: > > > This works: > make XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37 > XCPP=/usr/local/bin/clang-cpp37 buildworld -j12 -s > > This fails: > make XCC=/usr/local/bin/clang38 XCXX=/usr/local/bin/clang++38 > XCPP=/usr/local/bin/clang-cpp38 buildworld -j12 -s > > with: > > /home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/bin/ld: > > /usr/local/llvm38/bin/../lib/clang/3.8.1/lib/freebsd/libclang_rt.ubsan_standalone-x86_64.a: > No such file: No such file or directory > clang-3.8: error: linker command failed with exit code 1 (use -v to see > invocation) Looks like the llvm38 port didn't build the libclang_rt libraries. These are needed for the sanitizers, and so on. The llvm37 port does have these: % ls -l llvm37/lib/clang/3.7.1/lib/freebsd total 4188 -rw-r--r-- 1 root wheel 2083354 2016-07-12 05:08:14 libclang_rt.asan-i386.a -rwxr-xr-x 1 root wheel 705264 2016-07-12 05:09:27 libclang_rt.asan-i386.so* -rw-r--r-- 1 root wheel 1620 2016-07-12 05:08:06 libclang_rt.asan-preinit-i386.a -rw-r--r-- 1 root wheel35914 2016-07-12 05:08:12 libclang_rt.asan_cxx-i386.a -rw-r--r-- 1 root wheel 120524 2016-07-12 05:08:18 libclang_rt.builtins-i386.a -rw-r--r-- 1 root wheel33904 2016-07-12 05:08:19 libclang_rt.profile-i386.a -rw-r--r-- 1 root wheel 417872 2016-07-12 05:08:19 libclang_rt.safestack-i386.a -rw-r--r-- 1 root wheel 659270 2016-07-12 05:08:02 libclang_rt.ubsan_standalone-i386.a -rw-r--r-- 1 root wheel21234 2016-07-12 05:08:02 libclang_rt.ubsan_standalone_cxx-i386.a -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: External toolchain support broken for devel/llvm38 but not devel/llvm37
Matthew Macy wrote: It looks like there is something broken with the devel/llvm38 port or external toolchain support has regressed: This works: make XCC=/usr/local/bin/clang37 XCXX=/usr/local/bin/clang++37 XCPP=/usr/local/bin/clang-cpp37 buildworld -j12 -s This fails: make XCC=/usr/local/bin/clang38 XCXX=/usr/local/bin/clang++38 XCPP=/usr/local/bin/clang-cpp38 buildworld -j12 -s with: /home/mmacy/devel/build/mnt/storage/mmacy/devel/drm-next-merge/tmp/usr/bin/ld: /usr/local/llvm38/bin/../lib/clang/3.8.1/lib/freebsd/libclang_rt.ubsan_standalone-x86_64.a: No such file: No such file or directory clang-3.8: error: linker command failed with exit code 1 (use -v to see invocation) I second this - I also faced it. I think this is not a problem with a ports but rather with a build as correspondent files can be found in /usr/obj under /usr/obj/usr/src/tmp/usr/lib/clang/3.8.0/lib/freebsd/. Looks like this files are compiled during build but taken from compilers's directory. Linking 'em to the target directory makes build succeed. -- Sphinx of black quartz judge my vow. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: External toolchain support
On Mon, Dec 01, 2014 at 10:05:29PM -0700, Warner Losh wrote: On Nov 29, 2014, at 8:04 AM, Baptiste Daroussin b...@freebsd.org wrote: Hi all, It is now possible to use an external toolchain to build the kernel and base (tested with gcc 4.9.1 and latest binutils) Of course a lot of work is needed to make it build cleanly (aka lots of warning to fix). What have been tested so far: - sparc64 kernel + world - amd64 kernel + world - powerpc64 kernel + world mips cannot be tested because upstream gcc never heard of FreeBSD running on mips, and I did not receive any patches for mips. I have patches for 4.8 or so knocking around somewhere... Seems like kan@ have patches for 4.9.1 and was able to build world with it! (that is mips64) [...snip...] also notes that for the kernel a lots of warnings are disabled in share/sys/kern.mk so do not hesitate to remove yourself those -Wno-error= and fix the issue they are hidding! Cool. Please coordinate with me before removing the -Wno-error because they vary by architecture. Sure that was implied or build with all supported toolchains. regards, Bapt pgpgvcrj4Oyt0.pgp Description: PGP signature
Re: External toolchain support
On Dec 2, 2014, at 1:31 AM, Baptiste Daroussin b...@freebsd.org wrote: On Mon, Dec 01, 2014 at 10:05:29PM -0700, Warner Losh wrote: On Nov 29, 2014, at 8:04 AM, Baptiste Daroussin b...@freebsd.org wrote: Hi all, It is now possible to use an external toolchain to build the kernel and base (tested with gcc 4.9.1 and latest binutils) Of course a lot of work is needed to make it build cleanly (aka lots of warning to fix). What have been tested so far: - sparc64 kernel + world - amd64 kernel + world - powerpc64 kernel + world mips cannot be tested because upstream gcc never heard of FreeBSD running on mips, and I did not receive any patches for mips. I have patches for 4.8 or so knocking around somewhere... Seems like kan@ have patches for 4.9.1 and was able to build world with it! (that is mips64) Cool. I also ported the arm patches as well. I thought I’d sent them to you, but it may have only been in the raw form. I also have patches for the extended printf checking for the kernel, though those are much more fragile than architecture support. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: External toolchain support
On Tue, Dec 02, 2014 at 09:23:00AM -0700, Warner Losh wrote: On Dec 2, 2014, at 1:31 AM, Baptiste Daroussin b...@freebsd.org wrote: On Mon, Dec 01, 2014 at 10:05:29PM -0700, Warner Losh wrote: On Nov 29, 2014, at 8:04 AM, Baptiste Daroussin b...@freebsd.org wrote: Hi all, It is now possible to use an external toolchain to build the kernel and base (tested with gcc 4.9.1 and latest binutils) Of course a lot of work is needed to make it build cleanly (aka lots of warning to fix). What have been tested so far: - sparc64 kernel + world - amd64 kernel + world - powerpc64 kernel + world mips cannot be tested because upstream gcc never heard of FreeBSD running on mips, and I did not receive any patches for mips. I have patches for 4.8 or so knocking around somewhere... Seems like kan@ have patches for 4.9.1 and was able to build world with it! (that is mips64) Cool. I also ported the arm patches as well. I thought I’d sent them to you, but it may have only been in the raw form. I also have patches for the extended printf checking for the kernel, though those are much more fragile than architecture support. The format extension I have them already, otherwise I won't be able to boot the kernel (provided by kan as well). See devel/powerp64-gcc/files/* Regards, Bapt pgpscKUJgDowj.pgp Description: PGP signature
Re: External toolchain support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 29.11.2014 18:04, Baptiste Daroussin wrote: mips cannot be tested because upstream gcc never heard of FreeBSD running on mips, and I did not receive any patches for mips. I'm afraid, arm has same problem. I was need to patch arm-for-uC toolchain to be able built it on ARM host, and this fix is very cross-specific. As far as I know, gcc for freebsd-arm target needs patches too, but different ones. At least to configure scripts gcc host-drivers. - -- // Lev Serebryakov AKA Black Lion -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUfKyGXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP8ZsP/jIWqU+9ACCR4/Rdf5A7SaGc msCsofot9YrClKNJWPdjL0V2jMtKAURJVFf3OpRi6jXY9HJKzjIjHAoXDfwr97qP 9VyLgfvtNn+ffNuFuwUalwkiFcyzqvsADTHxFqFmCnhAAnjnHzn0CzushzKSRKYN 9yEhQphipCZ1DuP1cTE8z9/BOPAfXNjgjavfAYpnJARm+XZzPn2XG83rFnlLcZFo UcByyuZznxfImH6hxoNsRVkdj5yvuGmzxQJQf+ilipiI3pDZk5/Q+ZWzWGap/gC/ 0k2zWqyKO2O5pSNb8i8vsW2J+zg++BmMnO0VAt3pjxd4dqbrV5qk/g4oXiuxB2uX 8YnvbDJuLKzvI31GCrjOOa462yZlmoCBHRoqjUBZxeHh5QQSJyZjDc0ClRGbdfi/ FNLTx/jPhouxh1vEC1nV44FGS2v5Go9urKa1OhWYRrf+NyNlt7Ao5VutujgfQlvF sLo663/Ja9W2MzLHmPanHMJcPl/Y7v9S7Mwh/EPCIe8Fd8VeYUPhOlT349Z7FnhT e7Nu4zcnY82PJ4fU/yREHxZWsEwtRxx5vr1YrLClt8R7nx8ZXzq8A9JBLjqt/RfK 4BOe0D1t8zMARroiw9RaYFm8Md8nybWp+Q++ouME51jWWPgDxV9BbKaIx6Y4r+6V RO63nTfg3A8uT/D60bIA =aiOJ -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: External toolchain support
On Nov 29, 2014, at 8:04 AM, Baptiste Daroussin b...@freebsd.org wrote: Hi all, It is now possible to use an external toolchain to build the kernel and base (tested with gcc 4.9.1 and latest binutils) Of course a lot of work is needed to make it build cleanly (aka lots of warning to fix). What have been tested so far: - sparc64 kernel + world - amd64 kernel + world - powerpc64 kernel + world mips cannot be tested because upstream gcc never heard of FreeBSD running on mips, and I did not receive any patches for mips. I have patches for 4.8 or so knocking around somewhere... for amd64, in the kernel two things had to be removed from the build: - aesni: (it request a header which is compiler specific and on recent gcc will end up including stdlib.h which gives errors because kernel version of free and malloc are not compatible with the version defined in stdlib.h) - hptmv: I had to remove it from GENERIC and kernel building. The result is: $ sysctl kern.ostype kern.osrelease kern.osrevision kern.compiler_version kern.ostype: FreeBSD kern.osrelease: 11.0-CURRENT kern.osrevision: 199506 kern.compiler_version: gcc version 4.9.1 (FreeBSD Ports Collection for amd64) so yes it boots and runs How to do you own testing: in the ports tree/packages (the amd64 version will appear in packages next week) install: amd64-xtoolchain-gcc or powerpc64-xtoolchain-gcc or sparc64-xtoolchain-gcc if your source tree: make CROSS_TOOLCHAIN=amd64-gcc -j8 buildkernel or make CROSS_TOOLCHAIN=powerpc64-gcc -j8 buildkernel or make CROSS_TOOLCHAIN=sparc64-gcc -j8 buildkernel To build world: same operation with buildworld. Please note that for world you will need to add define NO_WERROR (world will also require a change in share/mk/bsd.lib.mk: s/--fatal-warnings/--no-fatal-warnings/) also notes that for the kernel a lots of warnings are disabled in share/sys/kern.mk so do not hesitate to remove yourself those -Wno-error= and fix the issue they are hidding! Cool. Please coordinate with me before removing the -Wno-error because they vary by architecture. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: External toolchain support
On 29/11/14 16:04, Baptiste Daroussin wrote: Hi all, It is now possible to use an external toolchain to build the kernel and base (tested with gcc 4.9.1 and latest binutils) make CROSS_TOOLCHAIN=sparc64-gcc -j8 buildkernel I built a sparc64 kernel on amd64 using sparc64-xtoolchain-gcc and was able to boot it successfully. $ uname -a FreeBSD v240 11.0-CURRENT FreeBSD 11.0-CURRENT #0 r275267M: Sat Nov 29 22:23:38 CET root@storage:/usr/obj/sparc64.sparc64/usr/src/sys/GENERIC sparc64 $ sysctl kern.ostype kern.osrelease kern.osrevision kern.compiler_version kern.ostype: FreeBSD kern.osrelease: 11.0-CURRENT kern.osrevision: 199506 kern.compiler_version: gcc version 4.9.1 (FreeBSD Ports Collection for sparc64) Florian signature.asc Description: OpenPGP digital signature
Re: External toolchain support
On 11/29/14, 7:04 AM, Baptiste Daroussin wrote: Hi all, It is now possible to use an external toolchain to build the kernel and base (tested with gcc 4.9.1 and latest binutils) Of course a lot of work is needed to make it build cleanly (aka lots of warning to fix). What have been tested so far: - sparc64 kernel + world - amd64 kernel + world - powerpc64 kernel + world mips cannot be tested because upstream gcc never heard of FreeBSD running on mips, and I did not receive any patches for mips. for amd64, in the kernel two things had to be removed from the build: - aesni: (it request a header which is compiler specific and on recent gcc will end up including stdlib.h which gives errors because kernel version of free and malloc are not compatible with the version defined in stdlib.h) - hptmv: I had to remove it from GENERIC and kernel building. The result is: $ sysctl kern.ostype kern.osrelease kern.osrevision kern.compiler_version kern.ostype: FreeBSD kern.osrelease: 11.0-CURRENT kern.osrevision: 199506 kern.compiler_version: gcc version 4.9.1 (FreeBSD Ports Collection for amd64) so yes it boots and runs How to do you own testing: in the ports tree/packages (the amd64 version will appear in packages next week) install: amd64-xtoolchain-gcc or powerpc64-xtoolchain-gcc or sparc64-xtoolchain-gcc if your source tree: make CROSS_TOOLCHAIN=amd64-gcc -j8 buildkernel or make CROSS_TOOLCHAIN=powerpc64-gcc -j8 buildkernel or make CROSS_TOOLCHAIN=sparc64-gcc -j8 buildkernel To build world: same operation with buildworld. Please note that for world you will need to add define NO_WERROR (world will also require a change in share/mk/bsd.lib.mk: s/--fatal-warnings/--no-fatal-warnings/) also notes that for the kernel a lots of warnings are disabled in share/sys/kern.mk so do not hesitate to remove yourself those -Wno-error= and fix the issue they are hidding! Best regards, Bapt This is amazing work, thank you Bapt! -Alfred ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org