| Message ID | 1531963618-29674-1-git-send-email-daniel.diaz@linaro.org |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [RFC] glibc: Avoid multilibbing on wordsize.h | expand |
On Wed, 18 Jul 2018 at 20:27, Daniel Díaz <daniel.diaz@linaro.org> wrote: > Once another header #includes <bits/wordsize.h>, there is a > potential recursion going on because the > multilib_header_wrapper.h #includes <bits/wordsize.h> again! > > This should not happen because an __arm__ (32-bits) or an > __aarch64__ (64-bits) environment guarantees that we will > be getting the correct definition, but when building against > a different target (like BPF), recursion is what happens. > > This can be seen, for instance, when building eBPF programs > from the kernel with `clang -target bpf', such as the ones > located in linux/tools/testing/selftests/bpf/. > > Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org> > Signed-off-by: Aníbal Limón <anibal.limon@linaro.org> > --- > meta/recipes-core/glibc/glibc-package.inc | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/meta/recipes-core/glibc/glibc-package.inc > b/meta/recipes-core/glibc/glibc-package.inc > index ae3f2f6..a4f61f8 100644 > --- a/meta/recipes-core/glibc/glibc-package.inc > +++ b/meta/recipes-core/glibc/glibc-package.inc > @@ -136,8 +136,7 @@ do_install_append_armeb () { > } > > do_install_armmultilib () { > - > - oe_multilib_header bits/endian.h bits/fcntl.h bits/fenv.h > bits/fp-fast.h bits/hwcap.h bits/ipc.h bits/link.h bits/wordsize.h > + oe_multilib_header bits/endian.h bits/fcntl.h bits/fenv.h > bits/fp-fast.h bits/hwcap.h bits/ipc.h bits/link.h > oe_multilib_header bits/local_lim.h bits/mman.h bits/msq.h > bits/pthreadtypes.h bits/pthreadtypes-arch.h bits/sem.h bits/semaphore.h > bits/setjmp.h > oe_multilib_header bits/shm.h bits/sigstack.h bits/stat.h > bits/statfs.h bits/typesizes.h > > -- > 2.7.4 > > -- > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.openembedded.org/mailman/listinfo/openembedded-core > <div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, 18 Jul 2018 at 20:27, Daniel Díaz <<a href="mailto:daniel.diaz@linaro.org">daniel.diaz@linaro.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Once another header #includes <bits/wordsize.h>, there is a<br> potential recursion going on because the<br> multilib_header_wrapper.h #includes <bits/wordsize.h> again!<br> <br> This should not happen because an __arm__ (32-bits) or an<br> __aarch64__ (64-bits) environment guarantees that we will<br> be getting the correct definition, but when building against<br> a different target (like BPF), recursion is what happens.<br> <br> This can be seen, for instance, when building eBPF programs<br> from the kernel with `clang -target bpf', such as the ones<br> located in linux/tools/testing/selftests/bpf/.<br> <br> Signed-off-by: Daniel Díaz <<a href="mailto:daniel.diaz@linaro.org" target="_blank">daniel.diaz@linaro.org</a>><br></blockquote><div><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Signed-off-by: Aníbal Limón <<a href="mailto:anibal.limon@linaro.org">anibal.limon@linaro.org</a></span><span style="font-size:small;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">></span> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> ---<br> meta/recipes-core/glibc/glibc-package.inc | 3 +--<br> 1 file changed, 1 insertion(+), 2 deletions(-)<br> <br> diff --git a/meta/recipes-core/glibc/glibc-package.inc b/meta/recipes-core/glibc/glibc-package.inc<br> index ae3f2f6..a4f61f8 100644<br> --- a/meta/recipes-core/glibc/glibc-package.inc<br> +++ b/meta/recipes-core/glibc/glibc-package.inc<br> @@ -136,8 +136,7 @@ do_install_append_armeb () {<br> }<br> <br> do_install_armmultilib () {<br> -<br> - oe_multilib_header bits/endian.h bits/fcntl.h bits/fenv.h bits/fp-fast.h bits/hwcap.h bits/ipc.h bits/link.h bits/wordsize.h<br> + oe_multilib_header bits/endian.h bits/fcntl.h bits/fenv.h bits/fp-fast.h bits/hwcap.h bits/ipc.h bits/link.h<br> oe_multilib_header bits/local_lim.h bits/mman.h bits/msq.h bits/pthreadtypes.h bits/pthreadtypes-arch.h bits/sem.h bits/semaphore.h bits/setjmp.h<br> oe_multilib_header bits/shm.h bits/sigstack.h bits/stat.h bits/statfs.h bits/typesizes.h<br> <br> -- <br> 2.7.4<br> <br> -- <br> _______________________________________________<br> Openembedded-core mailing list<br> <a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br> <a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" rel="noreferrer" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br> </blockquote></div></div> -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
diff --git a/meta/recipes-core/glibc/glibc-package.inc b/meta/recipes-core/glibc/glibc-package.inc index ae3f2f6..a4f61f8 100644 --- a/meta/recipes-core/glibc/glibc-package.inc +++ b/meta/recipes-core/glibc/glibc-package.inc @@ -136,8 +136,7 @@ do_install_append_armeb () { } do_install_armmultilib () { - - oe_multilib_header bits/endian.h bits/fcntl.h bits/fenv.h bits/fp-fast.h bits/hwcap.h bits/ipc.h bits/link.h bits/wordsize.h + oe_multilib_header bits/endian.h bits/fcntl.h bits/fenv.h bits/fp-fast.h bits/hwcap.h bits/ipc.h bits/link.h oe_multilib_header bits/local_lim.h bits/mman.h bits/msq.h bits/pthreadtypes.h bits/pthreadtypes-arch.h bits/sem.h bits/semaphore.h bits/setjmp.h oe_multilib_header bits/shm.h bits/sigstack.h bits/stat.h bits/statfs.h bits/typesizes.h
Once another header #includes <bits/wordsize.h>, there is a potential recursion going on because the multilib_header_wrapper.h #includes <bits/wordsize.h> again! This should not happen because an __arm__ (32-bits) or an __aarch64__ (64-bits) environment guarantees that we will be getting the correct definition, but when building against a different target (like BPF), recursion is what happens. This can be seen, for instance, when building eBPF programs from the kernel with `clang -target bpf', such as the ones located in linux/tools/testing/selftests/bpf/. Signed-off-by: Daniel Díaz <daniel.diaz@linaro.org> --- meta/recipes-core/glibc/glibc-package.inc | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)