[Buildroot] [PATCH-FOR-NEXT v1 3/6] pkgconf: add host-pkg-config wrapper
Arnout Vandecappelle
arnout at mind.be
Thu Feb 22 09:27:13 UTC 2018
On 21-02-18 22:50, Thomas Petazzoni wrote:
> Hello,
>
> +Peter, Yann, Arnout, there's a question below about a small change but
> has a big impact.
>
> On Wed, 21 Feb 2018 09:27:58 -0500, Gaël PORTAY wrote:
>> The host-pkg-config wrapper gets package data compiled for host.
>>
>> Signed-off-by: Gaël PORTAY <gael.portay at savoirfairelinux.com>
>> ---
>> package/pkgconf/host-pkg-config | 4 ++++
>> package/pkgconf/pkgconf.mk | 6 ++++--
>> 2 files changed, 8 insertions(+), 2 deletions(-)
>> create mode 100644 package/pkgconf/host-pkg-config
>>
>> diff --git a/package/pkgconf/host-pkg-config b/package/pkgconf/host-pkg-config
>> new file mode 100644
>> index 0000000000..3362a3f927
>> --- /dev/null
>> +++ b/package/pkgconf/host-pkg-config
>> @@ -0,0 +1,4 @@
>> +#!/bin/sh
>> +PKGCONFDIR=$(dirname "$0")
>> +DEFAULT_PKG_CONFIG_PATH=${PKGCONFDIR}/../lib/pkgconfig:${PKGCONFDIR}/../share/pkgconfig
>> +PKG_CONFIG_PATH=${PKG_CONFIG_PATH:-${DEFAULT_PKG_CONFIG_PATH}} exec ${PKGCONFDIR}/pkgconf "$@"
>
> I've been thinking about this for a while, and I remember having a
> discussion about this with some other Buildroot developer a while ago.
> I think the most correct thing to do would be:
>
> $(HOST_DIR)/bin/pkg-config returns results valid for native compilation
>
> $(HOST_DIR)/bin/<tuple>-pkg-config returns results valid for cross-compilation
This sounds like a good idea, but as you note below, could lead to breakage as
well.
An alternative would be (IIRC this idea was launched by ThomasDS (added in Cc)):
$(HOST_DIR)/bin/ contains binaries valid for native compilation (i.e. no
cross-compiler, cross-pkg-config, ...)
$(HOST_DIR)/<tuple>/bin contains binaries valid for cross-compilation
When building for host, PATH contains $(HOST_DIR)/bin
When building for target, PATH contains $(HOST_DIR)/<tuple>/bin:$(HOST_DIR)/bin
So let's analyse that option:
> I.e, the current pkg-config wrapper should be renamed
> <tuple>-pkg-config, and pkg-config should behave like a normal native
> pkg-config, except that it provides results for libraries located in
> $(HOST_DIR).
>
> The autoconf PKG_CHECK_MODULES() macro uses PKG_PROG_PKG_CONFIG(),
> which internally uses AC_PATH_TOOL(). And AC_PATH_TOOL() will first
> search for the program with the host machine tuple, and warn if the
> program cannot be found with this tuple. From
> https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/Generic-Programs.html:
>
> """
> When cross-compiling, this macro will issue a warning if no program
> prefixed with the host type could be found. For more information, see
> Specifying Target Triplets.
Weird, I checked a couple of log files and I could see no such warning. Ah,
that's because we pass PKG_CONFIG=... in the environment. Is it the idea to
remove that from the environment then?
Anyway, the PATH-based alternative will not remove this warning, but that
shouldn't be different from the current situation.
> """
>
> I know this change will:
>
> - Potentially break a number of packages we have in Buildroot, which
> directly use pkg-config without first trying to use
> <tuple>-pkg-config
I.e. anything not using autotools? Well, most will probably heed the
PKG_CONFIG=... in the environment.
The PATH-based alternative doesn't have this potential breakage.
> - Potentially break a number of downstream users who are using
> pkg-config.
The PATH-based alternative reduces this problem, downstream users just have to
add $(HOST_DIR)/tuple/bin to their path (and Buildroot will do this for post-xxx
scripts).
> However:
>
> - It would solve that once you add $(HOST_DIR)/bin to your PATH, you
> cannot anymore do native builds because "pkg-config" returns results
> that are not relevant for native builds. I already saw a number of
> people affected by this.
The PATH-based alternative solves this as well.
Note BTW that neither alternative solves the problem when building a host-tool
during a target build (and yes, we have seen this problem already in some
packages). AFAICS, autotools will also for host builds use the PKG_CONFIG passed
in the environment or discovered through the tuple. Same for CMake.
> - It would comply with the standard autoconf expectations.
With the PATH-based alternative, it might make sense to have the cross-stuff
both in $(HOST_DIR)/bin with the tuple prefix, and in $(HOST_DIR)/tuple/bin
without the prefix. That way, we get the advantages of both: comply with
autoconf expectations, and avoid breaking packages or downstream users.
Regards,
Arnout
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
More information about the buildroot
mailing list