Cross compiling with python bindings fails

[julienmalik]

Commit 21023a5#diff-72e868772be40795455997094ac5215e now prevents cross compilation of python bindings.

The InstallWrapper class added in said commit tries to load the libiio shared lib during python wrapper installation. This obviously fails when cross compiling for different architecture, raising an expected OSError exception instead.

[tfcollins]

The bindings have to be able to find the library, which is also required to build the doc. We need some more information about how you are actually buildings things.

-Travis

[julienmalik]

I'm building libiio with yocto. The build platform is my x86_64 laptop, the target platform is a z7000 board.
The libiio recipe is here

The bindings will be able to load libiio on the target platform, but it is not possible on the build platform at install time. I'm not building the documentation for the target platform, so did not notice this.

I've seen in the cmake_install files that there is a CMAKE_CROSSCOMPILING variable that is correctly set to TRUE, but did not yet figured out how to properly inject this in the "execute_process" call, or if this is really the right thing to do : there seems to be some caveats in using this variable, see cmake doc

For now I've just patched the setup.py to comment the cmdclass={"install": InstallWrapper} line, and the bindings can now be installed correctly.

Strangely also, I needed to dive into the install logs to figure all this out since the "setup.py install" target actually does not fail. It just spits out error in the logs. It exits with success, and just does not install the bindings files.

[rgetz]

@commodo & @nunojsa might have some more/better insight.

How to build libiio with python bindings inside yocto.

[nunojsa]

I'm assuming you are enabling python bindings with PACKAGECONFIG?
It seems the libiio recipe needs to be updated to support the new changes in the bindings installation. Not sure if adding RDEPDENDS/DEPENDS on the PACKAGECONFIG will do any good...

Strangely also, I needed to dive into the install logs to figure all this out since the "setup.py install" target actually does not fail. It just spits out error in the logs. It exits with success, and just does not install the bindings files.

That looks like a problem of the setup.py rather than yocto...

[julienmalik]

I'm assuming you are enabling python bindings with PACKAGECONFIG?

Yes

It seems the libiio recipe needs to be updated to support the new changes in the bindings installation. Not sure if adding RDEPDENDS/DEPENDS on the PACKAGECONFIG will do any good...

This line obviously cannot succeed on the build host.

Strangely also, I needed to dive into the install logs to figure all this out since the "setup.py install" target actually does not fail. It just spits out error in the logs. It exits with success, and just does not install the bindings files.

That looks like a problem of the setup.py rather than yocto...

Either setup.py (but the logs clearly show the exception being raised) or cmake's execute_process not catching the exit status correctly. I did not investigate more.

[nunojsa]

This line obviously cannot succeed on the build host.

Yeah, this can be problematic for build systems as yocto. I would need to further investigate to check if there's anything that can be done in yocto to workaround this.

One thing that comes to my mind is that if InstallWrapper is only called when running make install? If so, is there really any way that make install won't install libiio? Just wondering if this check may not be redundant...

[tfcollins]

@nunojsa The reason that check exists is for the pypi package. When the pypi package installs it will look to make sure the library has been installed first, if not it will tell the users where to get it. The pypi package is the dominant use case for python support.

-Travis

[rgetz]

I think @balister owes me a couple minutes for some hardware I gave him; and groks yocto pretty well.

Phil? Any pointers?

[balister]

Can someone look for me on irc (Crofton) in #oe when I wake up? I thought there was an existing libiio recipe, but I am guessing it is built without python bindings.

[balister]

Use the cmake CROSSCOMPILING to bypass checks for packages installed in the build python that are only needed at runtime. One could install a -native version into the sysroot python, but easier to bypass the check and let the recipe define the DEPENDS for the package.

[rgetz]

@balister; thanks for the pointer - I think the doc says we should be able to do things like:

https://github.com/gottingen/carbin-py/blob/master/carbin/prefix.py#L182

but that would just turn off sphinx when building with the python bindings. (which might be all that is needed?)

[mnsgs]

Is there a reason why ADI is not using (or at least appending to) the meta-oe variant of the recipe referred to by @julienmalik ? I assume this is the variant most of us are using and thus serves as a "common ground"...

[nunojsa]

@mnsgs Do you refer to meta-adi? If so, that is definitely something on my todo list...

[mnsgs]

@nunojsa yes, I am thinking of of meta-adi - glad to hear it is on the roadmap 👍

[rgetz]

closing, based on the merged PR #576