On 30 May 2017 at 09:24, Jussi Kukkonen <jussi.kukko...@intel.com> wrote:
> 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:${SYSROOT}/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.
>
Yes adding $target_dir into the LIBDIR is a bit of a hack/workaround.
And yes the example won't work OOTB, since I've forgot to list
something I've mentioned a while back.
Namely - the prepare stage is responsible for getting the sources in
the right "shape and form". I'm not familiar if/how Yocto does it, but
here is what I have in mind:
- prepare:
a) Fetch sources
b) Apply patches
c) (Re)Generate sources, if applicable. If you trust the distribution
tarballs this is a no-op. Alternatively it involves repeating the
process locally.
Since it involves something like ./configure && make dist, the
respective dependencies must be met. And since only the generators are
used, one can use $target_dir within LIBDIR
Alternatively: has anyone check how distributions deal with this? I
believe Arch uses a clean chroot - not sure about others.
AFAICT none of Arch, Debian, Fedora and OpenSuse carry similar patches.
Tl;Dr; I'm _not_ against extending things on our end, but considering
that it's a problem only(?) for Yocto I think we want to attempt and
address that in there.
Thanks
Emil
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev
