[PATCH] mesa: do not rely on native llvm-config in target sysroot

[PATCH] mesa: do not rely on native llvm-config in target sysroot

[Alexander Kanavin]

Sadly the magic is not perfect: llvm-config contains a hardcoded
value for the libdir from the native configuration, and things will
break if the target build installs libraries somewhere else (e.g. lib64).

llvm-config in target bindir also needs a rpath adjustment,
otherwise it simply won't even run when e.g. building for arm on x86.

To avoid patching llvm-source let's simply add more cases to the
llvm-config wrapper script, so that falling through to llvm-config binary
is avoided. Fortunately those cases are all static in what they return,
even though llvm-config binary does poke around the file tree to arrive
at them (which is where breakage happens if native and target don't match
exactly wrt libdir).

I verified that this works by building mesa with llvm enabled for
qemuarm64 and with baselib set to 'lib64' - so that both the target
architecture and target libdir differ from native ones.

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 meta/recipes-devtools/llvm/llvm/llvm-config |  9 +++++++++
 meta/recipes-graphics/mesa/mesa.inc         | 10 ----------
 2 files changed, 9 insertions(+), 10 deletions(-)

diff --git a/meta/recipes-devtools/llvm/llvm/llvm-config b/meta/recipes-devtools/llvm/llvm/llvm-config
index a45f38c650..5e4ded2da5 100644
--- a/meta/recipes-devtools/llvm/llvm/llvm-config
+++ b/meta/recipes-devtools/llvm/llvm/llvm-config
@@ -29,6 +29,15 @@ for arg in "$@"; do
     --ldflags)
       output="${output} ${LDFLAGS}"
       ;;
+    --shared-mode)
+      output="${output} shared"
+      ;;
+    --libs)
+      output="${output} -lLLVM"
+      ;;
+    --link-shared)
+      break
+      ;;
     *)
       remain="${remain} ${arg}"
       ;;
diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
index 7dbca5876a..5839b6d6a7 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -55,17 +55,7 @@ ANY_OF_DISTRO_FEATURES:class-target = "opengl vulkan"
 
 PLATFORMS ??= "${@bb.utils.filter('PACKAGECONFIG', 'x11 wayland', d)}"
 
-# By placing llvm-config in the target sysroot bindir, it will then map values
-# to the target libdir magically. We can safely add to path as there are no other binaries
-# there.
-PATH:prepend = "${STAGING_BINDIR_CROSS}:${STAGING_BINDIR}:"
 MESA_LLVM_RELEASE ?= "${LLVMVERSION}"
-do_configure:prepend () {
-	if [ -e ${STAGING_BINDIR_NATIVE}/llvm-config${MESA_LLVM_RELEASE} ]; then
-		cp ${STAGING_BINDIR_NATIVE}/llvm-config${MESA_LLVM_RELEASE} ${STAGING_BINDIR}
-		cp ${STAGING_BINDIR_NATIVE}/llvm-config ${STAGING_BINDIR}
-	fi
-}
 
 # set the MESA_BUILD_TYPE to either 'release' (default) or 'debug'
 # by default the upstream mesa sources build a debug release
-- 
2.30.2

Re: [OE-core] [PATCH] mesa: do not rely on native llvm-config in target sysroot

[Richard Purdie]

On Mon, 2022-11-14 at 14:35 +0100, Alexander Kanavin wrote:
> Sadly the magic is not perfect: llvm-config contains a hardcoded
> value for the libdir from the native configuration, and things will
> break if the target build installs libraries somewhere else (e.g. lib64).
> 
> llvm-config in target bindir also needs a rpath adjustment,
> otherwise it simply won't even run when e.g. building for arm on x86.
> 
> To avoid patching llvm-source let's simply add more cases to the
> llvm-config wrapper script, so that falling through to llvm-config binary
> is avoided. Fortunately those cases are all static in what they return,
> even though llvm-config binary does poke around the file tree to arrive
> at them (which is where breakage happens if native and target don't match
> exactly wrt libdir).
> 
> I verified that this works by building mesa with llvm enabled for
> qemuarm64 and with baselib set to 'lib64' - so that both the target
> architecture and target libdir differ from native ones.
> 
> Signed-off-by: Alexander Kanavin <alex@linutronix.de>
> ---
>  meta/recipes-devtools/llvm/llvm/llvm-config |  9 +++++++++
>  meta/recipes-graphics/mesa/mesa.inc         | 10 ----------
>  2 files changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/meta/recipes-devtools/llvm/llvm/llvm-config b/meta/recipes-devtools/llvm/llvm/llvm-config
> index a45f38c650..5e4ded2da5 100644
> --- a/meta/recipes-devtools/llvm/llvm/llvm-config
> +++ b/meta/recipes-devtools/llvm/llvm/llvm-config
> @@ -29,6 +29,15 @@ for arg in "$@"; do
>      --ldflags)
>        output="${output} ${LDFLAGS}"
>        ;;
> +    --shared-mode)
> +      output="${output} shared"
> +      ;;
> +    --libs)
> +      output="${output} -lLLVM"
> +      ;;
> +    --link-shared)
> +      break
> +      ;;
>      *)
>        remain="${remain} ${arg}"
>        ;;
> diff --git a/meta/recipes-graphics/mesa/mesa.inc b/meta/recipes-graphics/mesa/mesa.inc
> index 7dbca5876a..5839b6d6a7 100644
> --- a/meta/recipes-graphics/mesa/mesa.inc
> +++ b/meta/recipes-graphics/mesa/mesa.inc
> @@ -55,17 +55,7 @@ ANY_OF_DISTRO_FEATURES:class-target = "opengl vulkan"
>  
>  PLATFORMS ??= "${@bb.utils.filter('PACKAGECONFIG', 'x11 wayland', d)}"
>  
> -# By placing llvm-config in the target sysroot bindir, it will then map values
> -# to the target libdir magically. We can safely add to path as there are no other binaries
> -# there.
> -PATH:prepend = "${STAGING_BINDIR_CROSS}:${STAGING_BINDIR}:"
>  MESA_LLVM_RELEASE ?= "${LLVMVERSION}"
> -do_configure:prepend () {
> -	if [ -e ${STAGING_BINDIR_NATIVE}/llvm-config${MESA_LLVM_RELEASE} ]; then
> -		cp ${STAGING_BINDIR_NATIVE}/llvm-config${MESA_LLVM_RELEASE} ${STAGING_BINDIR}
> -		cp ${STAGING_BINDIR_NATIVE}/llvm-config ${STAGING_BINDIR}
> -	fi
> -}
>  
>  # set the MESA_BUILD_TYPE to either 'release' (default) or 'debug'
>  # by default the upstream mesa sources build a debug release

The trouble is how many people are ever going to check whether the
output of llvm-config changes? We really need to work with upstream to
make this util cross safe...

Cheers,

Richard

Re: [OE-core] [PATCH] mesa: do not rely on native llvm-config in target sysroot

[Alexander Kanavin]

On Mon, 14 Nov 2022 at 14:41, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:

> The trouble is how many people are ever going to check whether the
> output of llvm-config changes? We really need to work with upstream to
> make this util cross safe...

Yes, by making it a thin wrapper over pkg-config. I am completely
baffled why many projects, llvm included, have some kind of lifetime
allergy to pkg-config.

Alex

Re: [OE-core] [PATCH] mesa: do not rely on native llvm-config in target sysroot

[Alexander Kanavin]

Anyway. I filed an upstream ticket:
https://github.com/llvm/llvm-project/issues/58984

Alex

On Mon, 14 Nov 2022 at 14:50, Alexander Kanavin via
lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org>
wrote:
>
> On Mon, 14 Nov 2022 at 14:41, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
>
> > The trouble is how many people are ever going to check whether the
> > output of llvm-config changes? We really need to work with upstream to
> > make this util cross safe...
>
> Yes, by making it a thin wrapper over pkg-config. I am completely
> baffled why many projects, llvm included, have some kind of lifetime
> allergy to pkg-config.
>
> Alex
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#173243): https://lists.openembedded.org/g/openembedded-core/message/173243
> Mute This Topic: https://lists.openembedded.org/mt/95018621/1686489
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [PATCH] mesa: do not rely on native llvm-config in target sysroot

[Vincent Davis Jr]

[-- Attachment #1: Type: text/plain, Size: 43 bytes --]

Can also confirm that patch worked for me

[-- Attachment #2: Type: text/html, Size: 43 bytes --]

Re: [OE-core] [PATCH] mesa: do not rely on native llvm-config in target sysroot

[Alexander Kanavin]

And here's the ticket for meson where this issue originates:
https://github.com/mesonbuild/meson/issues/11043

Apparently llvm-config is not the only, or even the recommended way to
get settings, it's just that meson is using it instead of relying
entirely on cmake configs.

Alex

On Mon, 14 Nov 2022 at 15:25, Alexander Kanavin <alex.kanavin@gmail.com> wrote:
>
> Anyway. I filed an upstream ticket:
> https://github.com/llvm/llvm-project/issues/58984
>
> Alex
>
> On Mon, 14 Nov 2022 at 14:50, Alexander Kanavin via
> lists.openembedded.org <alex.kanavin=gmail.com@lists.openembedded.org>
> wrote:
> >
> > On Mon, 14 Nov 2022 at 14:41, Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> >
> > > The trouble is how many people are ever going to check whether the
> > > output of llvm-config changes? We really need to work with upstream to
> > > make this util cross safe...
> >
> > Yes, by making it a thin wrapper over pkg-config. I am completely
> > baffled why many projects, llvm included, have some kind of lifetime
> > allergy to pkg-config.
> >
> > Alex
> >
> > -=-=-=-=-=-=-=-=-=-=-=-
> > Links: You receive all messages sent to this group.
> > View/Reply Online (#173243): https://lists.openembedded.org/g/openembedded-core/message/173243
> > Mute This Topic: https://lists.openembedded.org/mt/95018621/1686489
> > Group Owner: openembedded-core+owner@lists.openembedded.org
> > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> >