On Thu, 18 Oct 2018 at 16:05, Pascal Bach <[email protected]> wrote:
> > My suspicion is that for systems where the host has python3-devel
> > installed, libcomp-native's cmake is using the host python instead of
> > the native python in the sysroot. I'm not sure yet if BOTH means it
> > searches the host before the sysroots, or if it is finding the python
> > binary in HOSTTOOLS and then asking that what the paths are. Either
> > way, it ends up linking to the host libpython3.5.so and going into
> > sstate. Another machine in the pool reuses this sstate but it doesn't
> > have Python 3.6 installed, so the library link is broken.
> That is definitively not the intention here.
>
> For target builds it is pretty clear that there should be no usage of host
> dependencies.
> For native it is not so clear to me. There seems to be some dependencies like
> the compiler and associated libs.
I think ensuring the ordering for native searches is sysroot then host
would be sufficient.
> What I'm traying to solve here was to get rid of these two lines in the
> wireshark recipe [1]:
>
> -DM_INCLUDE_DIR=${includedir} \
> -DM_LIBRARY=${libdir} \
>
> As they effectively add /usr/include and /usr/lib to the search path of cmake.
Well that's terrifying. What is that trying to solve? It's building
for the target, right? So why is it passing host paths?
Ross
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
