[U-Boot] [PATCH 0/2] fix building tools on FreeBSD/clang
Building tools from v2014.07-rc2 with clang as host cc produces many warnings and fails on FreeBSD. The first patch removes the warnings by restoring original behaviour. The second patch fixes the build failure on FreeBSD by explicitly including the correct header.
Jeroen Hofstee (2): Makefile: fix clang warnings due to clang support tools: include u-boot version of sha256.h
Makefile | 28 ---------------------------- tools/Makefile | 1 + 2 files changed, 1 insertion(+), 28 deletions(-)
Building u-boot tools with clang as a host compiler e.g. on FreeBSD with `gmake HOSTCC=clang CONFIG_USE_PRIVATE_LIBGCC=y tools` leads to many warnings [1] for every compiler invocation since commit 598e2d33. Part of mentioned commit imports linux patches:
- kbuild: LLVMLinux: Adapt warnings for compilation with clang - kbuild: LLVMLinux: Add Kbuild support for building kernel with Clang
No version of clang supports the gcc fno-delete-null-pointer-checks though, but it is only passed to clang. Gcc does not have the clang specific Qunused-arguments for the target. Furthermore several warnings are disabled which aren't encountered in u-boot. Since such a build has worked for quite some time and works after removing these changes, just remove the clang specific handling to restore normal building with clang as hostcc.
[1] Actual warnings ------------------- GEN include/autoconf.mk.dep arm-freebsd-gcc: unrecognized option '-Qunused-arguments'
HOSTCC scripts/basic/fixdep clang: warning: argument unused during compilation: '-fno-delete-null-pointer-checks'
cc: Masahiro Yamada yamada.m@jp.panasonic.com Signed-off-by: Jeroen Hofstee jeroen@myspectrum.nl --- Makefile | 28 ---------------------------- 1 file changed, 28 deletions(-)
diff --git a/Makefile b/Makefile index e38fd2f..bde41aa 100644 --- a/Makefile +++ b/Makefile @@ -209,11 +209,6 @@ HOSTCXX = g++ HOSTCFLAGS = -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer HOSTCXXFLAGS = -O2
-ifeq ($(shell $(HOSTCC) -v 2>&1 | grep -c "clang version"), 1) -HOSTCFLAGS += -Wno-unused-value -Wno-unused-parameter \ - -Wno-missing-field-initializers -fno-delete-null-pointer-checks -endif - ifeq ($(HOSTOS),cygwin) HOSTCFLAGS += -ansi endif @@ -320,15 +315,6 @@ endif
export quiet Q KBUILD_VERBOSE
-ifneq ($(CC),) -ifeq ($(shell $(CC) -v 2>&1 | grep -c "clang version"), 1) -COMPILER := clang -else -COMPILER := gcc -endif -export COMPILER -endif - # Look for make include files relative to root of kernel src MAKEFLAGS += --include-dir=$(srctree)
@@ -545,20 +531,6 @@ endif
KBUILD_CFLAGS += $(call cc-option,-fno-stack-protector)
-ifeq ($(COMPILER),clang) -KBUILD_CPPFLAGS += $(call cc-option,-Qunused-arguments,) -KBUILD_CPPFLAGS += $(call cc-option,-Wno-unknown-warning-option,) -KBUILD_CFLAGS += $(call cc-disable-warning, unused-variable) -KBUILD_CFLAGS += $(call cc-disable-warning, format-invalid-specifier) -KBUILD_CFLAGS += $(call cc-disable-warning, gnu) -# Quiet clang warning: comparison of unsigned expression < 0 is always false -KBUILD_CFLAGS += $(call cc-disable-warning, tautological-compare) -# CLANG uses a _MergedGlobals as optimization, but this breaks modpost, as the -# source of a reference will be _MergedGlobals and not on of the whitelisted names. -# See modpost pattern 2 -KBUILD_CFLAGS += $(call cc-option, -mno-global-merge,) -endif - KBUILD_CFLAGS += -g # $(KBUILD_AFLAGS) sets -g, which causes gcc to pass a suitable -g<format> # option to the assembler.
Hi Jeroen,
On Fri, 30 May 2014 15:45:27 +0200 Jeroen Hofstee jeroen@myspectrum.nl wrote:
Building u-boot tools with clang as a host compiler e.g. on FreeBSD with `gmake HOSTCC=clang CONFIG_USE_PRIVATE_LIBGCC=y tools` leads to many warnings [1] for every compiler invocation since commit 598e2d33. Part of mentioned commit imports linux patches:
- kbuild: LLVMLinux: Adapt warnings for compilation with clang
- kbuild: LLVMLinux: Add Kbuild support for building kernel with Clang
No version of clang supports the gcc fno-delete-null-pointer-checks though, but it is only passed to clang. Gcc does not have the clang specific Qunused-arguments for the target. Furthermore several warnings are disabled which aren't encountered in u-boot. Since such a build has worked for quite some time and works after removing these changes, just remove the clang specific handling to restore normal building with clang as hostcc.
I have to admit I just copied these line from Kernel without testing it, just for syncing with Kernel makefiles.
As far as I tested, Clang did not recognize -fno-delete-null-pointer-checks.
It is OK with me if you rip Clang stuff off the top Makefile.
Sorry, honestly I am not familiar enough with Clang to make deeper review.
This might be useful information for you. some discussion why Linux folks added those lines: https://patchwork.kernel.org/patch/3719881/
Do you also need this to use Clang? https://patchwork.kernel.org/patch/3720041/
Best Regards Masahiro Yamada
Hello Masahiro,
On di, 2014-06-10 at 21:20 +0900, Masahiro Yamada wrote:
Hi Jeroen,
On Fri, 30 May 2014 15:45:27 +0200 Jeroen Hofstee jeroen@myspectrum.nl wrote:
Building u-boot tools with clang as a host compiler e.g. on FreeBSD with `gmake HOSTCC=clang CONFIG_USE_PRIVATE_LIBGCC=y tools` leads to many warnings [1] for every compiler invocation since commit 598e2d33. Part of mentioned commit imports linux patches:
- kbuild: LLVMLinux: Adapt warnings for compilation with clang
- kbuild: LLVMLinux: Add Kbuild support for building kernel with Clang
No version of clang supports the gcc fno-delete-null-pointer-checks though, but it is only passed to clang. Gcc does not have the clang specific Qunused-arguments for the target. Furthermore several warnings are disabled which aren't encountered in u-boot. Since such a build has worked for quite some time and works after removing these changes, just remove the clang specific handling to restore normal building with clang as hostcc.
I have to admit I just copied these line from Kernel without testing it, just for syncing with Kernel makefiles.
As far as I tested, Clang did not recognize -fno-delete-null-pointer-checks.
It is OK with me if you rip Clang stuff off the top Makefile.
Sorry, honestly I am not familiar enough with Clang to make deeper review.
yup, it should be removed.. since with clang 3.5 trunk it actually errors. You should be able to verify it without cross target support with:
`make CC="clang -no-integrated-as" HOSTCC="clang -no-integrated-as" HOST_TOOLS_ALL=y sandbox_config tools`
and you get (with clang 3.5) "clang: error: unknown argument: '-fno-delete-null-pointer-checks'" (and yes the commit mentions warns, which more then likely is the case for clang 3.3 / 3.4). Undoing the Linux clang additions (as this patch does) makes the build work again.
Since there is no target clang support in U-boot at the moment the target warnings suppression can be removed as well, since it is just dead code at the moment and I would like to see how far we can get with actually fixing warnings, not blindly silencing them...
Regards, Jeroen
On Fri, May 30, 2014 at 03:45:27PM +0200, Jeroen Hofstee wrote:
Building u-boot tools with clang as a host compiler e.g. on FreeBSD with `gmake HOSTCC=clang CONFIG_USE_PRIVATE_LIBGCC=y tools` leads to many warnings [1] for every compiler invocation since commit 598e2d33. Part of mentioned commit imports linux patches:
- kbuild: LLVMLinux: Adapt warnings for compilation with clang
- kbuild: LLVMLinux: Add Kbuild support for building kernel with Clang
No version of clang supports the gcc fno-delete-null-pointer-checks though, but it is only passed to clang. Gcc does not have the clang specific Qunused-arguments for the target. Furthermore several warnings are disabled which aren't encountered in u-boot. Since such a build has worked for quite some time and works after removing these changes, just remove the clang specific handling to restore normal building with clang as hostcc.
[1] Actual warnings
GEN include/autoconf.mk.dep arm-freebsd-gcc: unrecognized option '-Qunused-arguments'
HOSTCC scripts/basic/fixdep clang: warning: argument unused during compilation: '-fno-delete-null-pointer-checks'
cc: Masahiro Yamada yamada.m@jp.panasonic.com Signed-off-by: Jeroen Hofstee jeroen@myspectrum.nl
Applied to u-boot/master, thanks!
When building tools the u-boot specific sha256.h is required, but the host version of sha256.h is used when present. This leads to build errors on FreeBSD which does have a system sha256.h include. Like libfdt_env.h explicitly include u-boot's sha256.h.
cc: Simon Glass sjg@chromium.org Signed-off-by: Jeroen Hofstee jeroen@myspectrum.nl --- tools/Makefile | 1 + 1 file changed, 1 insertion(+)
diff --git a/tools/Makefile b/tools/Makefile index 6e43a01..5105360 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -185,6 +185,7 @@ endif # !LOGO_BMP # Define _GNU_SOURCE to obtain the getline prototype from stdio.h # HOST_EXTRACFLAGS += -include $(srctree)/include/libfdt_env.h \ + -include $(srctree)/include/sha256.h \ $(patsubst -I%,-idirafter%, $(UBOOTINCLUDE)) \ -I$(srctree)/lib/libfdt \ -I$(srctree)/tools \
On 30 May 2014 07:45, Jeroen Hofstee jeroen@myspectrum.nl wrote:
When building tools the u-boot specific sha256.h is required, but the host version of sha256.h is used when present. This leads to build errors on FreeBSD which does have a system sha256.h include. Like libfdt_env.h explicitly include u-boot's sha256.h.
cc: Simon Glass sjg@chromium.org Signed-off-by: Jeroen Hofstee jeroen@myspectrum.nl
There might be a general approach here, but this is just as reasonable as the libfdt_env.h inclusion.
Acked-by: Simon Glass sjg@chromium.org
(tested with buildman - no build regressions on all boards)
tools/Makefile | 1 + 1 file changed, 1 insertion(+)
diff --git a/tools/Makefile b/tools/Makefile index 6e43a01..5105360 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -185,6 +185,7 @@ endif # !LOGO_BMP # Define _GNU_SOURCE to obtain the getline prototype from stdio.h # HOST_EXTRACFLAGS += -include $(srctree)/include/libfdt_env.h \
-include $(srctree)/include/sha256.h \ $(patsubst -I%,-idirafter%, $(UBOOTINCLUDE)) \ -I$(srctree)/lib/libfdt \ -I$(srctree)/tools \-- 1.8.3.2
Hello Simon,
On di, 2014-06-03 at 08:11 -0600, Simon Glass wrote:
On 30 May 2014 07:45, Jeroen Hofstee jeroen@myspectrum.nl wrote:
When building tools the u-boot specific sha256.h is required, but the host version of sha256.h is used when present. This leads to build errors on FreeBSD which does have a system sha256.h include. Like libfdt_env.h explicitly include u-boot's sha256.h.
cc: Simon Glass sjg@chromium.org Signed-off-by: Jeroen Hofstee jeroen@myspectrum.nl
There might be a general approach here, but this is just as reasonable as the libfdt_env.h inclusion.
Acked-by: Simon Glass sjg@chromium.org
(tested with buildman - no build regressions on all boards)
Thanks for testing. One of the more generic solutions I considered is to actually move all such headers to include/u-boot. I tried that, but it rapidly becomes a big patch touching files in all archs, which is a bit too big after an rc2 is already out.
Tom, since this does fix a build error, can you consider including this in the next release? (and preferably "Makefile: fix clang warnings due to clang support" as well, as it gains nothing but introduces quite some compile noise [but is waiting for feedback from Masahiro]).
Regards, Jeroen
On Fri, May 30, 2014 at 03:45:28PM +0200, Jeroen Hofstee wrote:
When building tools the u-boot specific sha256.h is required, but the host version of sha256.h is used when present. This leads to build errors on FreeBSD which does have a system sha256.h include. Like libfdt_env.h explicitly include u-boot's sha256.h.
cc: Simon Glass sjg@chromium.org Signed-off-by: Jeroen Hofstee jeroen@myspectrum.nl Acked-by: Simon Glass sjg@chromium.org
Applied to u-boot/master, thanks!
participants (4)
-
Jeroen Hofstee -
Masahiro Yamada -
Simon Glass -
Tom Rini