Libepoxy: Build for riscv64 #11040
Libepoxy: Build for riscv64 #11040
Conversation
|
This PR introduces a work-around for a meson/BinaryBuilder incompatibility: |
|
Meson stubbornness is really frustrating at times. |
L/Libepoxy/build_tarballs.jl
Outdated
| # meson unconditionally (?) adds the command line argument | ||
| # `-Werror=unused-command-line-argument`. That would be fine, except | ||
| # that we (the `cc` script) add `-Wl,-sdk_version,11.0` on Darwin, | ||
| # which is actually unused when meson checks for supported compiler | ||
| # options. This means that each such check fails, and meson won't use | ||
| # any options. That's mostly fine, except for the option | ||
| # `-Wno-int-conversion` which is required by the source code. | ||
| # | ||
| # The code below modifies the `cc` script to filter out the option | ||
| # `-Werror=unused-command-line-argument`. This should arguably either | ||
| # happen by default, or `cc` should only add the | ||
| # `-Wl,-sdk_version,11.0` when the linker is actually called. | ||
| # | ||
| # We modify `cc` on all architectures to prevent possible similar | ||
| # errors there. |
There was a problem hiding this comment.
I'm moderately hopeful (but haven't tested) that adding -Wno-unused-command-line-argument to meson C/C++ flags would work around this issue in a less painful way. If only Meson didn't expect to control everything under the sun and left escape hatches for cases like this, it'd be a much nicer build system.
There was a problem hiding this comment.
But also, if this was meson-specific, we'd have this issue with all other meson-based packages, no? What am I missing?
There was a problem hiding this comment.
env CFLAGS='-Wno-unused-command-line-argument' meson .. -Dtests=false --buildtype=release --cross-file="${MESON_TARGET_TOOLCHAIN}"
is not working.
There was a problem hiding this comment.
I briefly considered patching cc instead of modifying it by line number but that's even more tedious. First, the source of cc isn't readily available, one has to run a container to get the scripts. And second, this script is very architecture dependent so I'd have to create a different patch for each architecture. That patch is likely to break whenever the script is updated, and updating the patch is quite tedious (since the cc source code isn't available online).
There was a problem hiding this comment.
I'm modifying the meson target toolchain now. That seems to be the only way to make meson listen.
There was a problem hiding this comment.
is not working
That's because meson completely ignores all environment variables. I've been telling you meson is stubborn.
There was a problem hiding this comment.
Do you have a different idea for addressing this?
No description provided.