On 29 May 2017 at 18:10, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 29 May 2017 at 14:05, Jussi Kukkonen <jussi.kukko...@intel.com> wrote:
> > On 29 May 2017 at 15:20, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> >>
> >> On 26 May 2017 at 14:55, Jussi Kukkonen <jussi.kukko...@intel.com>
> wrote:
> >> > On 26 May 2017 at 14:32, Emil Velikov <emil.l.veli...@gmail.com>
> wrote:
> >> >>
> >> >> On 26 May 2017 at 08:52, Jussi Kukkonen <jussi.kukko...@intel.com>
> >> >> wrote:
> >> >> >
> >> >> >
> >> >> > On 24 May 2017 at 16:39, Emil Velikov <emil.l.veli...@gmail.com>
> >> >> > wrote:
> >> >> AFAICT there are a couple of alternative solutions - have you
> >> >> considered/tried any of them?
> >> >>
> >> >> a) w/o a wrapper script
> >> >> $ export PKG_CONFIG_PATH= // you need this if using the system
> >> >> pkgo-config. if the local/native one is used, this should be optional
> >> >> $ export
> >> >>
> >> >> PKG_CONFIG_LIBDIR=$path_to_non_system_host_pkgconfig:${SYSRO
> OT}/usr/{lib,share}/pkgconfig
> >> >> $ export PKG_CONFIG_SYSROOT_DIR=${SYSROOT}
> >> >
> >> > We're using a natively built pkg-config which sets all the pkg-config
> >> > variables to what I believe are the correct values: the problem is
> that
> >> > none
> >> > of those variable is for the _native_ sysroot location so they don't
> >> > help in
> >> > this case. There is now way to say in a .pc file that this path should
> >> > be
> >> > prefixed with something like "${pc_native_sysroot_dir}" if it's
> >> > defined.
> >> >
> >> >> b) with a wrapper script - see [1].
> >> >> I think that the "export PKG_CONFIG_DIR=" is a typo (should be ..PATH
> >> >> instead) and is not strictly required - feel free to check either
> way.
> >> >> Note that the exec at the end might need to be amended to
> >> >> /path/to/$(CHOST)-pkg-config.
> >> >
> >> > We don't provide a target wrapper -- I believe because it provides no
> >> > value
> >> > at all on top of the setup we have (the pkg-config that autotools
> finds
> >> > has
> >> > all the environment variables set correctly. It is essentially
> >> > $(CHOST)-pkg-config already).
> >> >
> >> > If I've missed something, I'd be happy to hear that. At the moment I
> >> > think
> >> > pkg-config just does not help in this case.
> >> >
> >> I'm confused a bit - did you try the above suggestions? If so can you
> >> share which one and how it fails?
> >
> >
> > I'm sorry but I do not see what I could test that could help: I mentioned
> > that the pkg-config that gets used by PKG_CHECK_MODULES() is essentially
> a
> > wrapped one: In more detail the build tool sets these variables:
> >
> Giving it a try won't hurt, right ;-)
>
> But on a more serious note:
> [1] Like any project in the wild Yocto might have bugs, please try w/o it.
> [2] A simple test [w/o Yocto] with my earlier suggestion seems to work fine
>
>
You're right, definitely doesn't hurt to try (and yocto surely has bugs in
it). I'll take a step back, have another look at the whole pkg-config setup
and try some tests -- your comment about PKG_CONFIG_DIR seems completely
correct.
The example test you gave still doesn't seem to work right though, see
below.
> Thanks
> Emil
>
> [1] From a quick look Yocto seems to be doing things a bit strange, wrong
> even?
> This is the first time I'm looking through it, so I may be wrong.
>
> Some examples, with the first and foremost being the prime suspect why
> things don't work as expected.
> * Yocto uses PKG_CONFIG_DIR. The variable is not a thing used by
> pkg-config (or pkgconf).
> Yes sometimes it's used only to be fed into LIBDIR/PATH
> (meta/conf/bitbake.conf), but it does not seem consistent.
> IMHO a good first step would be is to drop or rename it to PATH.
>
> * The native pkg-config has correct PATH/LIBDIR burned into the binary
> * A pkg-config-native wrapper also sets the PATH/LIBDIR variables
> - those are the default already stored within the binary
> - SYSROOT_DIR is explicitly discarded
> * Any PKG_CHECK_MODULES(.*) calls are discarded(??) - see
> wayland_1.11.0.bb
>
> [2] The following seems to work based on a quick test.
>
> -- Layout
>
> /usr/bin/{pkg-config,wayland-scanner}
> /usr/lib/pkgconfig/wayland-scanner.pc
>
> /native/usr/bin/{pkg-config,wayland-scanner}
> /native/usr/lib/pkgconfig/wayland-scanner.pc
>
> /target/usr/bin/{pkg-config,wayland-scanner} // just an example, one
> or both can be missing
> /target/usr/lib/pkgconfig/wayland-scanner.pc
>
> -- cat $(CHOST)-pkg-config
> #!/bin/sh
>
> export SYSROOT=/target/
> export PKG_CONFIG_LIBDIR=/native/usr/lib/pkgconfig/:${SYSROOT}/usr/
> lib/pkgconfig
> export PKG_CONFIG_SYSROOT_DIR=${SYSROOT}
>
> /native/usr/bin/pkg-config "$@"
>
The test above does work for wayland-scanner lookup specifically but you've
now added into PKG_CONFIG_LIBDIR a new directory with .pc files that are
meant for compiling native binaries when we're trying to build target
binaries.
E.g. adding these now:
/native/usr/lib/pkgconfig/zlib.pc
/target/usr/lib/pkgconfig/zlib.pc
Leads to "$(CHOST)-pkg-config --libs zlib" giving out answers from the
native pc file (this happens with waylands own libs too unless you happen
to use --disable-libraries like we do for native). The values may in some
circumstances look ok but there's no guarantee of that. Same goes for
--cflags of course: you may now be using flags meant for a completely
different architecture.
I think adding both native and target pkgconfig directories into
PKG_CONFIG_LIBDIR at the same time is just wrong: we're compiling mesa for
target so we should be using target .pc files. The fact that we need to
find a native tool to do that should not mean we use pc files meant for
building for another arch.
Thanks,
Jussi
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
