| Message ID | 20221114133504.2392154-1-alex@linutronix.de |
|---|---|
| State | Accepted, archived |
| Commit | 056431883e94296b767a479d029b914392e4fd7c |
| Headers | show |
| Series | mesa: do not rely on native llvm-config in target sysroot | expand |
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
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
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] > -=-=-=-=-=-=-=-=-=-=-=- >
Can also confirm that patch worked for me
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] > > -=-=-=-=-=-=-=-=-=-=-=- > >
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
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(-)