[Qemu-devel] issue: linking 64bit glib when building for cpu=i386

[Qemu-devel] issue: linking 64bit glib when building for cpu=i386

[John Snow]

I was running a series of tests on 32 and 64 bit hosts to test for 
endianness and variable width issues when I noticed that I couldn't 
properly perform a build of "make check" against a 32bit target from a 
64bit host:

../../configure --cpu=i386 && make -j4 && make check

This produces some warnings in tests-cutils about overflowing variables 
that are of type guint64. It's been mentioned on the mailing lists 
before, actually: 
http://lists.gnu.org/archive/html/qemu-devel/2014-05/msg00452.html

The problem is that guint64 is being aliased against "unsigned long", 
which is only 4 bytes instead of the implied 8. This occurs because we 
link against the 64bit headers for glib instead of the 32bit ones when 
we're building for i386 from an x86_64 host.

Our include flags wind up looking like: -I/usr/include/glib-2.0 but 
-I/usr/lib64/glib-2.0/include

I was discussing the problem with Stefan:

On 08/21/2014 05:03 AM, Stefan Hajnoczi wrote:
> The problem is that pkg-config uses libdir=/usr/lib64 by default on
> amd64 hosts.  It doesn't know that gcc -m32 is being used.
>
> This results in glib's 64-bit headers being used where guint64 is just
> unsigned long.  On 32-bit hosts this is incorrect.
>
> Two workarounds:
>
> 1. yum install pkgconfig.i686 and run it instead of pkgconfig.x86_64
>
> 2. Use the pkg-config --define-variable libdir=/usr/lib option
>
> You can set PKG_CONFIG=path/to/pkg-config.i686 on QEMU's ./configure
> command-line.
>
> This is all distro-specific :(.  Any other solutions?
>
> Stefan
>

I am not extremely well versed in configure or pkg-config ninjutsu, but 
I must imagine that the ARCH/cpu variables we are setting in configure 
could help us know to call the 32bit pkg-config instead of the native 
64bit version and fix this issue.

Does anyone have any good ideas? Surely other projects must have run 
into this elsewhere.

-- 
—js

Re: [Qemu-devel] issue: linking 64bit glib when building for cpu=i386

[Markus Armbruster]

John Snow <jsnow@redhat.com> writes:

> I was running a series of tests on 32 and 64 bit hosts to test for
> endianness and variable width issues when I noticed that I couldn't
> properly perform a build of "make check" against a 32bit target from a
> 64bit host:
>
> ../../configure --cpu=i386 && make -j4 && make check
>
> This produces some warnings in tests-cutils about overflowing
> variables that are of type guint64. It's been mentioned on the mailing
> lists before, actually:
> http://lists.gnu.org/archive/html/qemu-devel/2014-05/msg00452.html
>
> The problem is that guint64 is being aliased against "unsigned long",
> which is only 4 bytes instead of the implied 8. This occurs because we
> link against the 64bit headers for glib instead of the 32bit ones when
> we're building for i386 from an x86_64 host.

>From glibconfig.h:

    typedef signed char gint8;
    typedef unsigned char guint8;
    typedef signed short gint16;
    typedef unsigned short guint16;
    typedef signed int gint32;
    typedef unsigned int guint32;
    typedef signed long gint64;
    typedef unsigned long guint64;

Anyone redoing <stdint.h> in this day and age is a weirdo.

Anyone getting it wrong is a weirdo and a fool.

But getting it wrong in code expressively generated to configure for a
specific platform with a perfectly working <stdint.h>, that's in a
category of weird foolishness of its own.

But wait, it gets even better:

    typedef signed long gssize;
    typedef unsigned long gsize;

Oh yeah, can't rely on size_t, it's been reliably available only since a
decade before GLib was born!

[...]

Re: [Qemu-devel] issue: linking 64bit glib when building for cpu=i386

[Peter Maydell]

On 22 August 2014 01:10, John Snow <jsnow@redhat.com> wrote:
> I was running a series of tests on 32 and 64 bit hosts to test for
> endianness and variable width issues when I noticed that I couldn't properly
> perform a build of "make check" against a 32bit target from a 64bit host:
>
> ../../configure --cpu=i386 && make -j4 && make check

The 32-bit-on-64-bit x86 stuff is a weird special case and I'm
not terribly surprised it's broken. For pretty much every other
non-native build case, --cpu is only there to override configure's
guesses if it guesses wrong: you just tell configure the correct
compiler to use, and then it will automatically figure out it's i386
because of the compiler #defines. If you use --cross-prefix= this
will tell configure to use all of the correct compiler and the
correct pkgconfig, assuming your distro has set up the compiler
and the pkgconfig with the right prefixes. But i386-on-x86_64
seems to be odd in that rather than just having a correct
compiler for it there's the same compiler with a bunch of
flags, and a pkg-config in a non-standard place.

thanks
-- PMM

Re: [Qemu-devel] issue: linking 64bit glib when building for cpu=i386

[Daniel P. Berrange]

On Thu, Aug 21, 2014 at 08:10:54PM -0400, John Snow wrote:
> I was running a series of tests on 32 and 64 bit hosts to test for
> endianness and variable width issues when I noticed that I couldn't properly
> perform a build of "make check" against a 32bit target from a 64bit host:
> 
> ../../configure --cpu=i386 && make -j4 && make check
> 
> This produces some warnings in tests-cutils about overflowing variables that
> are of type guint64. It's been mentioned on the mailing lists before,
> actually: http://lists.gnu.org/archive/html/qemu-devel/2014-05/msg00452.html
> 
> The problem is that guint64 is being aliased against "unsigned long", which
> is only 4 bytes instead of the implied 8. This occurs because we link
> against the 64bit headers for glib instead of the 32bit ones when we're
> building for i386 from an x86_64 host.
> 
> Our include flags wind up looking like: -I/usr/include/glib-2.0 but
> -I/usr/lib64/glib-2.0/include
> 
> I was discussing the problem with Stefan:
> 
> On 08/21/2014 05:03 AM, Stefan Hajnoczi wrote:
> >The problem is that pkg-config uses libdir=/usr/lib64 by default on
> >amd64 hosts.  It doesn't know that gcc -m32 is being used.
> >
> >This results in glib's 64-bit headers being used where guint64 is just
> >unsigned long.  On 32-bit hosts this is incorrect.
> >
> >Two workarounds:
> >
> >1. yum install pkgconfig.i686 and run it instead of pkgconfig.x86_64
> >
> >2. Use the pkg-config --define-variable libdir=/usr/lib option
> >
> >You can set PKG_CONFIG=path/to/pkg-config.i686 on QEMU's ./configure
> >command-line.
> >
> >This is all distro-specific :(.  Any other solutions?
> >
> >Stefan
> >
> 
> I am not extremely well versed in configure or pkg-config ninjutsu, but I
> must imagine that the ARCH/cpu variables we are setting in configure could
> help us know to call the 32bit pkg-config instead of the native 64bit
> version and fix this issue.
> 
> Does anyone have any good ideas? Surely other projects must have run into
> this elsewhere.

Distros will install pkg-config .pc files for non-native architectures
in a different location normally. The supported / recommended way to
tell pkg-config to look in these alternative dirs is to set the env
variable  PKG_CONFIG_LIBDIR. This replaces the built-in default search
directory that looks for native.

So on a Fedora / RHELL system, to make pkg-config use 32-bit libs you
want to set

   PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig

which replaces the default location of /usr/lib64/pkgconfig. This is
the same thing you'd need to do to build QEMU for say, mingw32 where
you must set something like

   PKG_CONFIG_LIBDIR=/usr/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig/

Note, i say PKG_CONFIG_LIBDIR here, *not* PKG_CONFIG_PATH. The latter
variable adds the default search path - you want to stop it looking in
the default search path completely because it is the wrong arch, so
must use PKG_CONFIG_LIBDIR


Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] issue: linking 64bit glib when building for cpu=i386

[Peter Maydell]

On 22 August 2014 09:20, Daniel P. Berrange <berrange@redhat.com> wrote:
> Distros will install pkg-config .pc files for non-native architectures
> in a different location normally. The supported / recommended way to
> tell pkg-config to look in these alternative dirs is to set the env
> variable  PKG_CONFIG_LIBDIR. This replaces the built-in default search
> directory that looks for native.
>
> So on a Fedora / RHELL system, to make pkg-config use 32-bit libs you
> want to set
>
>    PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig
>
> which replaces the default location of /usr/lib64/pkgconfig. This is
> the same thing you'd need to do to build QEMU for say, mingw32 where
> you must set something like
>
>    PKG_CONFIG_LIBDIR=/usr/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig/

Yes, but this should be done by the i686-w64-mingw32-pkg-config
wrapper IMHO. (That's how I have my mingw setup configured,
anyway.)

> Note, i say PKG_CONFIG_LIBDIR here, *not* PKG_CONFIG_PATH. The latter
> variable adds the default search path - you want to stop it looking in
> the default search path completely because it is the wrong arch, so
> must use PKG_CONFIG_LIBDIR

Interestingly, Debian's cross-compile pkg-config wrapper
(aarch64-linux-gnu-pkg-config etc) sets PKG_CONFIG_PATH,
not PKG_CONFIG_LIBDIR. Maybe that's a bug, but it works...

thanks
-- PMM

Re: [Qemu-devel] issue: linking 64bit glib when building for cpu=i386

[Daniel P. Berrange]

On Fri, Aug 22, 2014 at 09:28:05AM +0100, Peter Maydell wrote:
> On 22 August 2014 09:20, Daniel P. Berrange <berrange@redhat.com> wrote:
> > Distros will install pkg-config .pc files for non-native architectures
> > in a different location normally. The supported / recommended way to
> > tell pkg-config to look in these alternative dirs is to set the env
> > variable  PKG_CONFIG_LIBDIR. This replaces the built-in default search
> > directory that looks for native.
> >
> > So on a Fedora / RHELL system, to make pkg-config use 32-bit libs you
> > want to set
> >
> >    PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig
> >
> > which replaces the default location of /usr/lib64/pkgconfig. This is
> > the same thing you'd need to do to build QEMU for say, mingw32 where
> > you must set something like
> >
> >    PKG_CONFIG_LIBDIR=/usr/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig/
> 
> Yes, but this should be done by the i686-w64-mingw32-pkg-config
> wrapper IMHO. (That's how I have my mingw setup configured,
> anyway.)

Sure if your distro wants to rebuild the pkg-config binary for each
arch that is a valid approach too, but it is by no means required
in order to get non-native builds working.

> > Note, i say PKG_CONFIG_LIBDIR here, *not* PKG_CONFIG_PATH. The latter
> > variable adds the default search path - you want to stop it looking in
> > the default search path completely because it is the wrong arch, so
> > must use PKG_CONFIG_LIBDIR
> 
> Interestingly, Debian's cross-compile pkg-config wrapper
> (aarch64-linux-gnu-pkg-config etc) sets PKG_CONFIG_PATH,
> not PKG_CONFIG_LIBDIR. Maybe that's a bug, but it works...

Yes, that would be a bug. Consider if you have mistakenly only installed
the 64-bit dev package for libusb and not the 32-bit package. Now the
'libusb-1.0.pc' file will only be present in the directory
/usr/lib64/pkgconfig but not in /usr/lib/pkgconfig.

If you used PKG_CONFIG_PATH to point to the 32-bit directory, then
it won't find the 32-bit libusb-1.0, so will fallback to looking in
the 64-bit directory and repo the 64-bit version which is definitely
not what you want. That'll lead to pain & suffering with wierd build
and/or link errors. If you used PKG_CONFIG_LIBDIR then you'll get an
immediate error from pkg-config telling you the 32-bit libusb-1.0
package was not installed.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [Qemu-devel] issue: linking 64bit glib when building for cpu=i386

[Peter Maydell]

On 22 August 2014 09:34, Daniel P. Berrange <berrange@redhat.com> wrote:
> On Fri, Aug 22, 2014 at 09:28:05AM +0100, Peter Maydell wrote:
>> Yes, but this should be done by the i686-w64-mingw32-pkg-config
>> wrapper IMHO. (That's how I have my mingw setup configured,
>> anyway.)
>
> Sure if your distro wants to rebuild the pkg-config binary for each
> arch that is a valid approach too, but it is by no means required
> in order to get non-native builds working.

It's just a wrapper script, not a complete fresh binary. The
point is that all the compilation tools needed for a build for
$TRIPLET are $TRIPLET-toolname. That's what QEMU's
configure script expects and it's easy for users.

>> Interestingly, Debian's cross-compile pkg-config wrapper
>> (aarch64-linux-gnu-pkg-config etc) sets PKG_CONFIG_PATH,
>> not PKG_CONFIG_LIBDIR. Maybe that's a bug, but it works...
>
> Yes, that would be a bug. Consider if you have mistakenly only installed
> the 64-bit dev package for libusb and not the 32-bit package. Now the
> 'libusb-1.0.pc' file will only be present in the directory
> /usr/lib64/pkgconfig but not in /usr/lib/pkgconfig.

Mmm, this does seem to be a bug. I'll see if it's been
reported to Debian yet...

-- PMM

Re: [Qemu-devel] issue: linking 64bit glib when building for cpu=i386

[Stefan Hajnoczi]

On Fri, Aug 22, 2014 at 9:20 AM, Daniel P. Berrange <berrange@redhat.com> wrote:
> On Thu, Aug 21, 2014 at 08:10:54PM -0400, John Snow wrote:
>> I was running a series of tests on 32 and 64 bit hosts to test for
>> endianness and variable width issues when I noticed that I couldn't properly
>> perform a build of "make check" against a 32bit target from a 64bit host:
>>
>> ../../configure --cpu=i386 && make -j4 && make check
>>
>> This produces some warnings in tests-cutils about overflowing variables that
>> are of type guint64. It's been mentioned on the mailing lists before,
>> actually: http://lists.gnu.org/archive/html/qemu-devel/2014-05/msg00452.html
>>
>> The problem is that guint64 is being aliased against "unsigned long", which
>> is only 4 bytes instead of the implied 8. This occurs because we link
>> against the 64bit headers for glib instead of the 32bit ones when we're
>> building for i386 from an x86_64 host.
>>
>> Our include flags wind up looking like: -I/usr/include/glib-2.0 but
>> -I/usr/lib64/glib-2.0/include
>>
>> I was discussing the problem with Stefan:
>>
>> On 08/21/2014 05:03 AM, Stefan Hajnoczi wrote:
>> >The problem is that pkg-config uses libdir=/usr/lib64 by default on
>> >amd64 hosts.  It doesn't know that gcc -m32 is being used.
>> >
>> >This results in glib's 64-bit headers being used where guint64 is just
>> >unsigned long.  On 32-bit hosts this is incorrect.
>> >
>> >Two workarounds:
>> >
>> >1. yum install pkgconfig.i686 and run it instead of pkgconfig.x86_64
>> >
>> >2. Use the pkg-config --define-variable libdir=/usr/lib option
>> >
>> >You can set PKG_CONFIG=path/to/pkg-config.i686 on QEMU's ./configure
>> >command-line.
>> >
>> >This is all distro-specific :(.  Any other solutions?
>> >
>> >Stefan
>> >
>>
>> I am not extremely well versed in configure or pkg-config ninjutsu, but I
>> must imagine that the ARCH/cpu variables we are setting in configure could
>> help us know to call the 32bit pkg-config instead of the native 64bit
>> version and fix this issue.
>>
>> Does anyone have any good ideas? Surely other projects must have run into
>> this elsewhere.
>
> Distros will install pkg-config .pc files for non-native architectures
> in a different location normally. The supported / recommended way to
> tell pkg-config to look in these alternative dirs is to set the env
> variable  PKG_CONFIG_LIBDIR. This replaces the built-in default search
> directory that looks for native.
>
> So on a Fedora / RHELL system, to make pkg-config use 32-bit libs you
> want to set
>
>    PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig
>
> which replaces the default location of /usr/lib64/pkgconfig.

Nice, and Paolo sent me an automated way of doing that:

On Fri, Aug 22, 2014 at 12:14:28AM +0200, Paolo Bonzini wrote:
> You need to set PKG_CONFIG_LIBDIR to
>
> /usr/lib/$MULTILIBDIR/pkgconfig
>
> where MULTILIBDIR is
>
>     if $CC -print-multiarch >/dev/null 2>&1; then
>       MULTILIBDIR=`$CC -print-multiarch $CFLAGS $CPPFLAGS`
>     fi
>     if test -z "$MULTILIBDIR"; then
>       MULTILIBDIR=`$CC --print-multi-os-directory $CFLAGS $CPPFLAGS`
>     fi
>
> This will point at /usr/lib/pkgconfig/glib-2.0.pc instead of
> /usr/lib64/pkgconfig/glib-2.0.pc

I tested that it works.

Stefan

Re: [Qemu-devel] issue: linking 64bit glib when building for cpu=i386

[John Snow]

On 08/22/2014 05:05 AM, Stefan Hajnoczi wrote:
> On Fri, Aug 22, 2014 at 9:20 AM, Daniel P. Berrange <berrange@redhat.com> wrote:
>> On Thu, Aug 21, 2014 at 08:10:54PM -0400, John Snow wrote:
>>> I was running a series of tests on 32 and 64 bit hosts to test for
>>> endianness and variable width issues when I noticed that I couldn't properly
>>> perform a build of "make check" against a 32bit target from a 64bit host:
>>>
>>> ../../configure --cpu=i386 && make -j4 && make check
>>>
>>> This produces some warnings in tests-cutils about overflowing variables that
>>> are of type guint64. It's been mentioned on the mailing lists before,
>>> actually: http://lists.gnu.org/archive/html/qemu-devel/2014-05/msg00452.html
>>>
>>> The problem is that guint64 is being aliased against "unsigned long", which
>>> is only 4 bytes instead of the implied 8. This occurs because we link
>>> against the 64bit headers for glib instead of the 32bit ones when we're
>>> building for i386 from an x86_64 host.
>>>
>>> Our include flags wind up looking like: -I/usr/include/glib-2.0 but
>>> -I/usr/lib64/glib-2.0/include
>>>
>>> I was discussing the problem with Stefan:
>>>
>>> On 08/21/2014 05:03 AM, Stefan Hajnoczi wrote:
>>>> The problem is that pkg-config uses libdir=/usr/lib64 by default on
>>>> amd64 hosts.  It doesn't know that gcc -m32 is being used.
>>>>
>>>> This results in glib's 64-bit headers being used where guint64 is just
>>>> unsigned long.  On 32-bit hosts this is incorrect.
>>>>
>>>> Two workarounds:
>>>>
>>>> 1. yum install pkgconfig.i686 and run it instead of pkgconfig.x86_64
>>>>
>>>> 2. Use the pkg-config --define-variable libdir=/usr/lib option
>>>>
>>>> You can set PKG_CONFIG=path/to/pkg-config.i686 on QEMU's ./configure
>>>> command-line.
>>>>
>>>> This is all distro-specific :(.  Any other solutions?
>>>>
>>>> Stefan
>>>>
>>>
>>> I am not extremely well versed in configure or pkg-config ninjutsu, but I
>>> must imagine that the ARCH/cpu variables we are setting in configure could
>>> help us know to call the 32bit pkg-config instead of the native 64bit
>>> version and fix this issue.
>>>
>>> Does anyone have any good ideas? Surely other projects must have run into
>>> this elsewhere.
>>
>> Distros will install pkg-config .pc files for non-native architectures
>> in a different location normally. The supported / recommended way to
>> tell pkg-config to look in these alternative dirs is to set the env
>> variable  PKG_CONFIG_LIBDIR. This replaces the built-in default search
>> directory that looks for native.
>>
>> So on a Fedora / RHELL system, to make pkg-config use 32-bit libs you
>> want to set
>>
>>     PKG_CONFIG_LIBDIR=/usr/lib/pkgconfig
>>
>> which replaces the default location of /usr/lib64/pkgconfig.
>
> Nice, and Paolo sent me an automated way of doing that:
>
> On Fri, Aug 22, 2014 at 12:14:28AM +0200, Paolo Bonzini wrote:
>> You need to set PKG_CONFIG_LIBDIR to
>>
>> /usr/lib/$MULTILIBDIR/pkgconfig
>>
>> where MULTILIBDIR is
>>
>>      if $CC -print-multiarch >/dev/null 2>&1; then
>>        MULTILIBDIR=`$CC -print-multiarch $CFLAGS $CPPFLAGS`
>>      fi
>>      if test -z "$MULTILIBDIR"; then
>>        MULTILIBDIR=`$CC --print-multi-os-directory $CFLAGS $CPPFLAGS`
>>      fi
>>
>> This will point at /usr/lib/pkgconfig/glib-2.0.pc instead of
>> /usr/lib64/pkgconfig/glib-2.0.pc
>
> I tested that it works.
>
> Stefan
>

A barrier into introducing this into the configuration script is that 
clang, used on OSX hosts, does not support these print flags.

Even worse, clang --print-multi-os-directory produces "x86_64" on Fedora 
20, which will lead to an erroneous configuration.

So we'll have to look into another way to support cross-compilation for 
i386 on x86_64 to avoid script breakage on other platforms.

Any other ideas? It looks as if there have been proposals in the past to 
add some multi-arch awareness into pkg-config, but they haven't gone 
anywhere. So some tool needs to tell pkg-config where to look, but clang 
is apparently not up to the job.

Where does gcc/g++ find out about the lib directories? Or are they 
baked-in per distro?

Any ideas?

--j

Re: [Qemu-devel] issue: linking 64bit glib when building for cpu=i386

[Peter Maydell]

On 23 September 2014 11:52, John Snow <jsnow@redhat.com> wrote:
> On 08/22/2014 05:05 AM, Stefan Hajnoczi wrote:
>> Nice, and Paolo sent me an automated way of doing that:
>>
>> On Fri, Aug 22, 2014 at 12:14:28AM +0200, Paolo Bonzini wrote:
>>>
>>> You need to set PKG_CONFIG_LIBDIR to
>>>
>>> /usr/lib/$MULTILIBDIR/pkgconfig
>>>
>>> where MULTILIBDIR is
>>>
>>>      if $CC -print-multiarch >/dev/null 2>&1; then
>>>        MULTILIBDIR=`$CC -print-multiarch $CFLAGS $CPPFLAGS`
>>>      fi
>>>      if test -z "$MULTILIBDIR"; then
>>>        MULTILIBDIR=`$CC --print-multi-os-directory $CFLAGS $CPPFLAGS`
>>>      fi
>>>
>>> This will point at /usr/lib/pkgconfig/glib-2.0.pc instead of
>>> /usr/lib64/pkgconfig/glib-2.0.pc

> A barrier into introducing this into the configuration script is that clang,
> used on OSX hosts, does not support these print flags.
>
> Even worse, clang --print-multi-os-directory produces "x86_64" on Fedora 20,
> which will lead to an erroneous configuration.
>
> So we'll have to look into another way to support cross-compilation for i386
> on x86_64 to avoid script breakage on other platforms.
>
> Any other ideas? It looks as if there have been proposals in the past to add
> some multi-arch awareness into pkg-config, but they haven't gone anywhere.
> So some tool needs to tell pkg-config where to look, but clang is apparently
> not up to the job.

If you're cross compiling you should probably pass configure
--cross-prefix=whatever-
and make sure your compiler and the pkg-config wrapper which sets
PKG_CONFIG_LIBDIR are all suitably named whatever-cc,
whatever-pkg-config etc. This is the sort of cross compile environment
which configure is designed to work with (and it's the distro's
job to get that environment set up, not QEMU's).

The runes above are specifically for Fedora x86_64-to-i386
compilation, which is a very special case (though you
can treat this like a full cross compile if you want,
which is the direction Debian are taking cross builds with
multiarch).

(In particular, for a cross compile from Fedora to OSX you want a
cross-clang targeting MacOSX and a cross set of libraries and
includes and a cross set of pkg-config config files, so you
definitely don't want to be running the build host's clang or
its pkg-config.)

-- PMM