Do use host-specific pkg-config when cross-compiling (PR #23037)
VZ
This re-enables the use of $host-pkg-config after it was disabled again by d6ddfe8 (Disable build system pkg-config when cross-compiling to non-Linux, 2022-11-30).
@paulcor Does this address your concerns?
You can view, comment on, or merge this pull request online at:
https://github.com/wxWidgets/wxWidgets/pull/23037
Commit Summary
- 2a9e333 Do use host-specific pkg-config when cross-compiling
File Changes
(2 files)
- M configure (22)
- M configure.in (38)
Patch Links:
- https://github.com/wxWidgets/wxWidgets/pull/23037.patch
- https://github.com/wxWidgets/wxWidgets/pull/23037.diff
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
paulcor
@paulcor Does this address your concerns?
It would fix my specific use case. But I'm not at all convinced that it should be our job to fix anyone's broken cross-build setup. Particularly when it has a chance of breaking a legitimate one.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
I get problems cross-compiling for wxMSW all the time because I don't have x86_64-w64-mingw32-pkg-config installed (and why would I? I don't have any MSW libraries I want to use on my Linux system anyhow) because pkg-config finds libcurl which results in adding -I/usr/include/x86_64-linux-gnu to the compilation flags which breaks compiling code targeting MSW as this directory contains Linux-specific headers.
I don't know what's the best solution is here but it seems bad to break the build in this common case, especially as it's not really obvious to understand why it is broken. And the only solution I know of is to set PKG_CONFIG_LIBDIR=/dev/null when running configure which is far from obvious neither.
But most importantly, I just don't see when would it ever make sense to use build system pkg-config. Can you think of any case when anyone would want to do it? IMNSHO this is just a bad default and autoconf should never fall back to build system tools if a host-specific one can't be found.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
paulcor
I get problems cross-compiling for wxMSW all the time because I don't have x86_64-w64-mingw32-pkg-config installed (and why would I?
I don't understand your logic here. You would install the cross pkg-config so you don't "get problems ... all the time".
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
I don't understand your logic here. You would install the cross
pkg-configso you don't "get problems ... all the time".
I'd like to make 2 separate points here:
- It's very much not obvious that you need to install
$host-pkg-configto build wxWidgets correctly even though you absolutely do not need to use it at all for actually finding the libraries, as wxWidgets comes with its own built-in versions of them. I hadn't realized it myself and I really don't think many wxWidgets users would think to do it. We could document it, of course, but explaining that you need to install it even if you don't use any external libraries is going to be an interesting logical exercise. How exactly would you justify having a requirement that is not needed on its own? From a purely theoretical viewpoint, I believe it's just wrong to require something that we don't actually use. - From a more practical point of view, this PR does nothing if
$host-pkg-configis installed, so it only avoids difficult to diagnose errors if it happens not to be available. And it basically allows things to work out of the box in a configuration where they mysteriously broke with weird error messages before. How can it be seen as anything other than an improvement?
IMO we only have 2 choices here: either complain and stop with an error if $host-pkg-config is not available when cross-compiling because we know that things will break without it when targeting MSW and libcurl is installed (which is a pretty common case) or do what this PR does. And the latter seems much more helpful to me.
Do you (or anybody else) disagree with this?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
I'd appreciate getting a reply to the above or at least a confirmation that you don't violently object to merging this PR. TIA!
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
paulcor
You may take my silence as tacit capitulation.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
You may take my silence as tacit capitulation.
Thanks, I wasn't sure if it was that or just due to the seasonal pleasantness (or maybe just vacations).
In any case, I really don't think this makes things worse and we can always re-re-revert this later if it turns out to still create any problems.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.