[Buildroot] [PATCH 1/4] llvm: fix build of host-llvm

[Buildroot] [PATCH 1/4] llvm: fix build of host-llvm

[Fabrice Fontaine]

If BR2_PACKAGE_LLVM_TARGET_ARCH is empty because llvm is not supported
on target, build of the host-llvm will fail on "Unknown architecture".

This is an issue because host-llvm (and host-clang) can be needed on
host. For example the libv4l package uses clang to build BPF (in-kernel
bytecode machine) files.

To fix this, add a new "host" default value to
BR2_PACKAGE_LLVM_TARGET_ARCH

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
---
 package/llvm/Config.in | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/llvm/Config.in b/package/llvm/Config.in
index 83e94660eb..0e111f1b76 100644
--- a/package/llvm/Config.in
+++ b/package/llvm/Config.in
@@ -10,6 +10,7 @@ config BR2_PACKAGE_LLVM_TARGET_ARCH
 	default "AArch64" if BR2_aarch64
 	default "ARM" if BR2_arm || BR2_armeb
 	default "X86" if BR2_i386 || BR2_x86_64
+	default "host"
 
 config BR2_PACKAGE_LLVM
 	bool "llvm"
-- 
2.17.1

[Buildroot] [PATCH 2/4] llvm: enable bpf

[Fabrice Fontaine]

BPF (in-kernel bytecode machine) is needed by libv4l

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
---
 package/llvm/llvm.mk | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/package/llvm/llvm.mk b/package/llvm/llvm.mk
index 1f9bd447f5..dae5d3f16d 100644
--- a/package/llvm/llvm.mk
+++ b/package/llvm/llvm.mk
@@ -54,6 +54,9 @@ ifeq ($(BR2_PACKAGE_LLVM_AMDGPU),y)
 LLVM_TARGETS_TO_BUILD += AMDGPU
 endif
 
+# Build BPF (in-kernel bytecode machine)
+LLVM_TARGETS_TO_BUILD += BPF
+
 # Use native llvm-tblgen from host-llvm (needed for cross-compilation)
 LLVM_CONF_OPTS += -DLLVM_TABLEGEN=$(HOST_DIR)/bin/llvm-tblgen
 
-- 
2.17.1

[Buildroot] [PATCH 2/4] llvm: enable bpf

[Thomas Petazzoni]

Hello,

On Sat,  3 Nov 2018 13:27:56 +0100, Fabrice Fontaine wrote:
> BPF (in-kernel bytecode machine) is needed by libv4l
> 
> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
> ---
>  package/llvm/llvm.mk | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/package/llvm/llvm.mk b/package/llvm/llvm.mk
> index 1f9bd447f5..dae5d3f16d 100644
> --- a/package/llvm/llvm.mk
> +++ b/package/llvm/llvm.mk
> @@ -54,6 +54,9 @@ ifeq ($(BR2_PACKAGE_LLVM_AMDGPU),y)
>  LLVM_TARGETS_TO_BUILD += AMDGPU
>  endif
>  
> +# Build BPF (in-kernel bytecode machine)
> +LLVM_TARGETS_TO_BUILD += BPF

Perhaps we should make this optional ? Or maybe the build time
difference is not that significant ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 2/4] llvm: enable bpf

[Fabrice Fontaine]

Dear Thomas,
Le sam. 3 nov. 2018 ? 14:14, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> a ?crit :
>
> Hello,
>
> On Sat,  3 Nov 2018 13:27:56 +0100, Fabrice Fontaine wrote:
> > BPF (in-kernel bytecode machine) is needed by libv4l
> >
> > Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
> > ---
> >  package/llvm/llvm.mk | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/package/llvm/llvm.mk b/package/llvm/llvm.mk
> > index 1f9bd447f5..dae5d3f16d 100644
> > --- a/package/llvm/llvm.mk
> > +++ b/package/llvm/llvm.mk
> > @@ -54,6 +54,9 @@ ifeq ($(BR2_PACKAGE_LLVM_AMDGPU),y)
> >  LLVM_TARGETS_TO_BUILD += AMDGPU
> >  endif
> >
> > +# Build BPF (in-kernel bytecode machine)
> > +LLVM_TARGETS_TO_BUILD += BPF
>
> Perhaps we should make this optional ? Or maybe the build time
> difference is not that significant ?
llvm and clang are already taking a long time to build on my "old"
machine, I didn't notice a significant difference with or without BPF
but I didn't measure it.
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Best Regards,

Fabrice

[Buildroot] [PATCH 2/4] llvm: enable bpf

[Valentin Korenblit]

Fabrice, Thomas,

> Dear Thomas,
> Le sam. 3 nov. 2018 ? 14:14, Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> a ?crit :
>> Hello,
>>
>> On Sat,  3 Nov 2018 13:27:56 +0100, Fabrice Fontaine wrote:
>>> BPF (in-kernel bytecode machine) is needed by libv4l
>>>
>>> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
>>> ---
>>>   package/llvm/llvm.mk | 3 +++
>>>   1 file changed, 3 insertions(+)
>>>
>>> diff --git a/package/llvm/llvm.mk b/package/llvm/llvm.mk
>>> index 1f9bd447f5..dae5d3f16d 100644
>>> --- a/package/llvm/llvm.mk
>>> +++ b/package/llvm/llvm.mk
>>> @@ -54,6 +54,9 @@ ifeq ($(BR2_PACKAGE_LLVM_AMDGPU),y)
>>>   LLVM_TARGETS_TO_BUILD += AMDGPU
>>>   endif
>>>
>>> +# Build BPF (in-kernel bytecode machine)
>>> +LLVM_TARGETS_TO_BUILD += BPF
>> Perhaps we should make this optional ? Or maybe the build time
>> difference is not that significant ?
> llvm and clang are already taking a long time to build on my "old"
> machine, I didn't notice a significant difference with or without BPF
> but I didn't measure it.

I think we should add a new option just like we did with AMDGPU backend
as we said we were only going to build backend for target archictecture
by default.

>> Best regards,
>>
>> Thomas
>> --
>> Thomas Petazzoni, CTO, Bootlin
>> Embedded Linux and Kernel engineering
>> https://bootlin.com
> Best Regards,
>
> Fabrice

Best regards,

Valentin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20181103/bf3d35b5/attachment.html>

[Buildroot] [PATCH 2/4] llvm: enable bpf

[Fabrice Fontaine]

Dear Valentin,
Le sam. 3 nov. 2018 ? 15:24, Valentin Korenblit
<valentinkorenblit@gmail.com> a ?crit :
>
> Fabrice, Thomas,
>
> Dear Thomas,
> Le sam. 3 nov. 2018 ? 14:14, Thomas Petazzoni
> <thomas.petazzoni@bootlin.com> a ?crit :
>
> Hello,
>
> On Sat,  3 Nov 2018 13:27:56 +0100, Fabrice Fontaine wrote:
>
> BPF (in-kernel bytecode machine) is needed by libv4l
>
> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
> ---
>  package/llvm/llvm.mk | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/package/llvm/llvm.mk b/package/llvm/llvm.mk
> index 1f9bd447f5..dae5d3f16d 100644
> --- a/package/llvm/llvm.mk
> +++ b/package/llvm/llvm.mk
> @@ -54,6 +54,9 @@ ifeq ($(BR2_PACKAGE_LLVM_AMDGPU),y)
>  LLVM_TARGETS_TO_BUILD += AMDGPU
>  endif
>
> +# Build BPF (in-kernel bytecode machine)
> +LLVM_TARGETS_TO_BUILD += BPF
>
> Perhaps we should make this optional ? Or maybe the build time
> difference is not that significant ?
>
> llvm and clang are already taking a long time to build on my "old"
> machine, I didn't notice a significant difference with or without BPF
> but I didn't measure it.
>
> I think we should add a new option just like we did with AMDGPU backend
> as we said we were only going to build backend for target archictecture
> by default.
I would like some advice to add this option, this BPF option should be
selectable even if BR2_PACKAGE_LLVM is not set as llvm is not needed
on the target.

So should I put some kind of hidden option like:
config BR2_PACKAGE_HOST_LLVM_TARGET_BPF
        bool

and select it in libv4l/Config.in?
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
> Best Regards,
>
> Fabrice
>
> Best regards,
>
> Valentin
Best Regards,

Fabrice

[Buildroot] [PATCH 3/4] libv4l: add elfutils optional dependency

[Fabrice Fontaine]

Bump to version 1.61.1 added an optional dependency to elfutils:
https://git.linuxtv.org/v4l-utils.git/commit/?id=d6025b0e8c7f57b0f9390f987acc5eed57360d80

host-clang is also needed to build PBF protocols, see:
https://git.linuxtv.org/v4l-utils.git/commit/?id=91b37c0d9cb71fc2d5f78cc96aa2ef9f3bba145b

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
---
 package/libv4l/libv4l.mk | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/package/libv4l/libv4l.mk b/package/libv4l/libv4l.mk
index 4e82dea6ad..7be41f8fef 100644
--- a/package/libv4l/libv4l.mk
+++ b/package/libv4l/libv4l.mk
@@ -55,6 +55,12 @@ endif
 ifeq ($(BR2_PACKAGE_LIBV4L_UTILS),y)
 LIBV4L_CONF_OPTS += --enable-v4l-utils
 LIBV4L_DEPENDENCIES += $(TARGET_NLS_DEPENDENCIES)
+
+ifeq ($(BR2_PACKAGE_ELFUTILS),y)
+# host-clang is needed to build BPF protocols
+LIBV4L_DEPENDENCIES += elfutils host-clang
+endif
+
 ifeq ($(BR2_PACKAGE_QT5BASE)$(BR2_PACKAGE_QT5BASE_GUI)$(BR2_PACKAGE_QT5BASE_WIDGETS),yyy)
 LIBV4L_CONF_OPTS += --enable-qv4l2
 LIBV4L_DEPENDENCIES += qt5base
-- 
2.17.1

[Buildroot] [PATCH 3/4] libv4l: add elfutils optional dependency

[Thomas Petazzoni]

Hello,

On Sat,  3 Nov 2018 13:27:57 +0100, Fabrice Fontaine wrote:
> Bump to version 1.61.1 added an optional dependency to elfutils:
> https://git.linuxtv.org/v4l-utils.git/commit/?id=d6025b0e8c7f57b0f9390f987acc5eed57360d80
> 
> host-clang is also needed to build PBF protocols, see:

PBF -> BPF

> https://git.linuxtv.org/v4l-utils.git/commit/?id=91b37c0d9cb71fc2d5f78cc96aa2ef9f3bba145b

I'm not sure to understand: there are two separate commits upstream,
one that adds the elfutils dependency, one that adds the clang
dependency. Are they both needed to have BPF protocols ? If so, why
were those two dependencies introduced in separate commits upstream ?

> +ifeq ($(BR2_PACKAGE_ELFUTILS),y)
> +# host-clang is needed to build BPF protocols
> +LIBV4L_DEPENDENCIES += elfutils host-clang
> +endif

I think an explicit sub-option would make sense in this case, because
it's not trivial at all to know that you need elfutils. So I would
prefer to have

config BR2_PACKAGE_LIBV4L_KEYTABLE_BPF_PROTOCOLS
	bool "keytable BPF protocols"
	select BR2_PACKAGE_ELFUTILS
        depends on BR2_USE_WCHAR # elfutils
        depends on !BR2_STATIC_LIBS # elfutils
        depends on BR2_TOOLCHAIN_USES_UCLIBC || BR2_TOOLCHAIN_USES_GLIBC # elfutils

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 3/4] libv4l: add elfutils optional dependency

[Fabrice Fontaine]

Dear Thomas,
Le sam. 3 nov. 2018 ? 14:18, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> a ?crit :
>
> Hello,
>
> On Sat,  3 Nov 2018 13:27:57 +0100, Fabrice Fontaine wrote:
> > Bump to version 1.61.1 added an optional dependency to elfutils:
> > https://git.linuxtv.org/v4l-utils.git/commit/?id=d6025b0e8c7f57b0f9390f987acc5eed57360d80
> >
> > host-clang is also needed to build PBF protocols, see:
>
> PBF -> BPF
>
> > https://git.linuxtv.org/v4l-utils.git/commit/?id=91b37c0d9cb71fc2d5f78cc96aa2ef9f3bba145b
>
> I'm not sure to understand: there are two separate commits upstream,
> one that adds the elfutils dependency, one that adds the clang
> dependency. Are they both needed to have BPF protocols ? If so, why
> were those two dependencies introduced in separate commits upstream ?
Yes, BPF protocols are enabled only if elfutils is available:

AM_CONDITIONAL([HAVE_LIBELF], [test x$libelf_pkgconfig = xyes])
if test "x$libelf_pkgconfig" = "xyes"; then
AC_CHECK_PROG([CLANG], clang, clang)
AC_DEFINE([HAVE_LIBELF], [1], [libelf library is present])
else
AC_MSG_WARN(libelf library not available)
fi
>
> > +ifeq ($(BR2_PACKAGE_ELFUTILS),y)
> > +# host-clang is needed to build BPF protocols
> > +LIBV4L_DEPENDENCIES += elfutils host-clang
> > +endif
>
> I think an explicit sub-option would make sense in this case, because
> it's not trivial at all to know that you need elfutils. So I would
> prefer to have
>
> config BR2_PACKAGE_LIBV4L_KEYTABLE_BPF_PROTOCOLS
>         bool "keytable BPF protocols"
>         select BR2_PACKAGE_ELFUTILS
>         depends on BR2_USE_WCHAR # elfutils
>         depends on !BR2_STATIC_LIBS # elfutils
>         depends on BR2_TOOLCHAIN_USES_UCLIBC || BR2_TOOLCHAIN_USES_GLIBC # elfutils
OK, I will update the patch to add this option.
>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Best Regards,

Fabrice

[Buildroot] [PATCH 4/4] scripts/check-bin-arch: fix failure with bpf

[Fabrice Fontaine]

Do not return an error if architecture is "Linux BPF" (in-kernel
bytecode machine)

Fixes:
 - http://autobuild.buildroot.org/results/c18fb7f1ac81496db9c3a4e91ea028a26ca600b0

Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
---
 support/scripts/check-bin-arch | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/support/scripts/check-bin-arch b/support/scripts/check-bin-arch
index 7f97696735..a0de7a6ac4 100755
--- a/support/scripts/check-bin-arch
+++ b/support/scripts/check-bin-arch
@@ -74,6 +74,11 @@ while read f; do
 		continue
 	fi
 
+	# If architecture is Linux BPF (in-kernel bytecode machine), continue
+	if test "${arch}" = "Linux BPF" ; then
+		continue
+	fi
+
 	# Architecture is correct
 	if test "${arch}" = "${arch_name}" ; then
 		continue
-- 
2.17.1

[Buildroot] [PATCH 4/4] scripts/check-bin-arch: fix failure with bpf

[Thomas Petazzoni]

Hello,

On Sat,  3 Nov 2018 13:27:58 +0100, Fabrice Fontaine wrote:
> Do not return an error if architecture is "Linux BPF" (in-kernel
> bytecode machine)
> 
> Fixes:
>  - http://autobuild.buildroot.org/results/c18fb7f1ac81496db9c3a4e91ea028a26ca600b0
> 
> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
> ---
>  support/scripts/check-bin-arch | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/support/scripts/check-bin-arch b/support/scripts/check-bin-arch
> index 7f97696735..a0de7a6ac4 100755
> --- a/support/scripts/check-bin-arch
> +++ b/support/scripts/check-bin-arch
> @@ -74,6 +74,11 @@ while read f; do
>  		continue
>  	fi
>  
> +	# If architecture is Linux BPF (in-kernel bytecode machine), continue
> +	if test "${arch}" = "Linux BPF" ; then
> +		continue
> +	fi

In the build failure
http://autobuild.buildroot.org/results/c18fb7f1ac81496db9c3a4e91ea028a26ca600b0/build-end.log
that you point, the architecture is reported as "None", not as "Linux
BPF". Am I misunderstanding something here ?

As a first step, could we explicitly disable building BPF protocols,
before we merge the necessary LLVM/V4L logic to build these properly ?

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 4/4] scripts/check-bin-arch: fix failure with bpf

[Fabrice Fontaine]

Dear Thomas,
Le sam. 3 nov. 2018 ? 14:20, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> a ?crit :
>
> Hello,
>
> On Sat,  3 Nov 2018 13:27:58 +0100, Fabrice Fontaine wrote:
> > Do not return an error if architecture is "Linux BPF" (in-kernel
> > bytecode machine)
> >
> > Fixes:
> >  - http://autobuild.buildroot.org/results/c18fb7f1ac81496db9c3a4e91ea028a26ca600b0
> >
> > Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
> > ---
> >  support/scripts/check-bin-arch | 5 +++++
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/support/scripts/check-bin-arch b/support/scripts/check-bin-arch
> > index 7f97696735..a0de7a6ac4 100755
> > --- a/support/scripts/check-bin-arch
> > +++ b/support/scripts/check-bin-arch
> > @@ -74,6 +74,11 @@ while read f; do
> >               continue
> >       fi
> >
> > +     # If architecture is Linux BPF (in-kernel bytecode machine), continue
> > +     if test "${arch}" = "Linux BPF" ; then
> > +             continue
> > +     fi
>
> In the build failure
> http://autobuild.buildroot.org/results/c18fb7f1ac81496db9c3a4e91ea028a26ca600b0/build-end.log
> that you point, the architecture is reported as "None", not as "Linux
> BPF". Am I misunderstanding something here ?
I wasn't able to reproduce this "None" architecture issue.
But I think it was "None" because the llvm/clang found on Peter's
machine was very old (3.8):
clang -idirafter /usr/local/include -idirafter
/usr/lib/llvm-3.8/bin/../lib/clang/3.8.1/include -idirafter
/usr/include/x86_64-linux-gnu -idirafter /usr/include
-I../../../include -target bpf -O2 -c grundig.c

With my patch's serie, I'm building a host-clang in version 7.0 that
supports BPF and in this case the architecture is correctly set to
"Linux BPF".
I tested with a clang in version 6.0 installed from Ubuntu 18.04
repositories on my host machine and it was also "Linux BPF".
>
> As a first step, could we explicitly disable building BPF protocols,
> before we merge the necessary LLVM/V4L logic to build these properly ?
Ok, I will do that.
>
> Thanks,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Best Regards,

Fabrice

[Buildroot] [PATCH 4/4] scripts/check-bin-arch: fix failure with bpf

[Thomas Petazzoni]

Hello,

On Sat, 3 Nov 2018 14:53:48 +0100, Fabrice Fontaine wrote:

> I wasn't able to reproduce this "None" architecture issue.
> But I think it was "None" because the llvm/clang found on Peter's
> machine was very old (3.8):
> clang -idirafter /usr/local/include -idirafter
> /usr/lib/llvm-3.8/bin/../lib/clang/3.8.1/include -idirafter
> /usr/include/x86_64-linux-gnu -idirafter /usr/include
> -I../../../include -target bpf -O2 -c grundig.c
> 
> With my patch's serie, I'm building a host-clang in version 7.0 that
> supports BPF and in this case the architecture is correctly set to
> "Linux BPF".
> I tested with a clang in version 6.0 installed from Ubuntu 18.04
> repositories on my host machine and it was also "Linux BPF".

OK, but then you're not fixing the problem on Peter's machine: with
your patch series, if he doesn't enable BR2_PACKAGE_ELFUTILS, libv4l
configure script will still detect the system-wide clang/llvm
installed, which will produce those bogus "None" binaries.

Which is why there is a need to explicitly disable building the BPF
protocol support, except if we know that Buildroot is providing all the
necessary dependencies.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 1/4] llvm: fix build of host-llvm

[Romain Naour]

Hi Fabrice,

Le 03/11/2018 ? 13:27, Fabrice Fontaine a ?crit?:
> If BR2_PACKAGE_LLVM_TARGET_ARCH is empty because llvm is not supported
> on target, build of the host-llvm will fail on "Unknown architecture".
> 
> This is an issue because host-llvm (and host-clang) can be needed on
> host. For example the libv4l package uses clang to build BPF (in-kernel
> bytecode machine) files.
> 
> To fix this, add a new "host" default value to
> BR2_PACKAGE_LLVM_TARGET_ARCH
> 
> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
> ---
>  package/llvm/Config.in | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/package/llvm/Config.in b/package/llvm/Config.in
> index 83e94660eb..0e111f1b76 100644
> --- a/package/llvm/Config.in
> +++ b/package/llvm/Config.in
> @@ -10,6 +10,7 @@ config BR2_PACKAGE_LLVM_TARGET_ARCH
>  	default "AArch64" if BR2_aarch64
>  	default "ARM" if BR2_arm || BR2_armeb
>  	default "X86" if BR2_i386 || BR2_x86_64
> +	default "host"

I'm not sure this is the correct thing to do since BR2_PACKAGE_LLVM_TARGET_ARCH
will be used for the target variant.

"host" stand for "automatic detection"

Maybe you want to add "X86" along with LLVM_TARGETS_TO_BUILD for host-llvm ?

Something like:

HOST_LLVM_TARGETS_TO_BUILD = $(LLVM_TARGETS_TO_BUILD) X86

HOST_LLVM_CONF_OPTS += -DLLVM_TARGETS_TO_BUILD="$(subst
$(space),;,$(HOST_LLVM_TARGETS_TO_BUILD))"

Also your host must be an x86 or x86_64.

Best regards,
Romain

>  
>  config BR2_PACKAGE_LLVM
>  	bool "llvm"
> 

[Buildroot] [PATCH 1/4] llvm: fix build of host-llvm

[Thomas Petazzoni]

Hello,

On Sat, 3 Nov 2018 15:15:30 +0100, Romain Naour wrote:

> > @@ -10,6 +10,7 @@ config BR2_PACKAGE_LLVM_TARGET_ARCH
> >  	default "AArch64" if BR2_aarch64
> >  	default "ARM" if BR2_arm || BR2_armeb
> >  	default "X86" if BR2_i386 || BR2_x86_64
> > +	default "host"  
> 
> I'm not sure this is the correct thing to do since BR2_PACKAGE_LLVM_TARGET_ARCH
> will be used for the target variant.
> 
> "host" stand for "automatic detection"
> 
> Maybe you want to add "X86" along with LLVM_TARGETS_TO_BUILD for host-llvm ?
> 
> Something like:
> 
> HOST_LLVM_TARGETS_TO_BUILD = $(LLVM_TARGETS_TO_BUILD) X86

For the host, it makes sense to use "automatic detection", so what
about:

HOST_LLVM_TARGETS_TO_BUILD = $(LLVM_TARGETS_TO_BUILD) host

i.e, have support for the target architecture, but also the
architecture ?

However, presumably, LLVM may not have support for all host
architectures, so this calls for a BR2_PACKAGE_HOST_LLVM_ARCH_SUPPORTS ?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH 1/4] llvm: fix build of host-llvm

[Fabrice Fontaine]

Dear Thomas,
Le sam. 3 nov. 2018 ? 15:36, Thomas Petazzoni
<thomas.petazzoni@bootlin.com> a ?crit :
>
> Hello,
>
> On Sat, 3 Nov 2018 15:15:30 +0100, Romain Naour wrote:
>
> > > @@ -10,6 +10,7 @@ config BR2_PACKAGE_LLVM_TARGET_ARCH
> > >     default "AArch64" if BR2_aarch64
> > >     default "ARM" if BR2_arm || BR2_armeb
> > >     default "X86" if BR2_i386 || BR2_x86_64
> > > +   default "host"
> >
> > I'm not sure this is the correct thing to do since BR2_PACKAGE_LLVM_TARGET_ARCH
> > will be used for the target variant.
> >
> > "host" stand for "automatic detection"
> >
> > Maybe you want to add "X86" along with LLVM_TARGETS_TO_BUILD for host-llvm ?
> >
> > Something like:
> >
> > HOST_LLVM_TARGETS_TO_BUILD = $(LLVM_TARGETS_TO_BUILD) X86
>
> For the host, it makes sense to use "automatic detection", so what
> about:
>
> HOST_LLVM_TARGETS_TO_BUILD = $(LLVM_TARGETS_TO_BUILD) host
>
> i.e, have support for the target architecture, but also the
> architecture ?
The issue is not with LLVM_TARGETS_TO_BUILD but with LLVM_TARGET_ARCH.
LLVM_TARGET_ARCH can't be empty and it can only contain a single
value. That why I put a new default value of "host" for
BR2_PACKAGE_LLVM_TARGET_ARCH if no other values are provided.
>
> However, presumably, LLVM may not have support for all host
> architectures, so this calls for a BR2_PACKAGE_HOST_LLVM_ARCH_SUPPORTS ?
Indeed, that would make sense. From what I can read here:
https://llvm.org/docs/GettingStarted.html#hardware, it seems that llvm
should build on x86, ARM, powerpc.
I would suggest to add this new variable:
config BR2_PACKAGE_HOST_LLVM_ARCH_SUPPORTS
        bool
        default y if BR2_HOSTARCH = "x86_64"
        default y if BR2_HOSTARCH = "x86"
        default y if BR2_HOSTARCH = "powerpc"
        default y if BR2_HOSTARCH = "arm"
        default y if BR2_HOSTARCH = "aarch64"

and do:

config BR2_PACKAGE_LLVM_TARGET_ARCH
        string
        default "AArch64" if BR2_aarch64
        default "ARM" if BR2_arm || BR2_armeb
        default "X86" if BR2_i386 || BR2_x86_64
        default "host" if BR2_PACKAGE_HOST_LLVM_ARCH_SUPPORTS

Does it make sense?
>
> Best regards,
>
> Thomas
> --
> Thomas Petazzoni, CTO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
Best Regards,

Fabrice