[feature] Cross compilation on same os / architecture #10923
Comments
|
Hi @eirikb Indeed a non expected case. I think something else is necessary into the model to dissambiguate between those builds/binaries. What would be the variable thing in the packages? Something in the Yocto built image? Versioning or classifying the Linux distro? |
|
I'm not very well traversed in the land of Yocto, but the toolchain files at least seem to contain pieces such as;
All of these variables might end up creating different binaries. I think it is possible to distinguish binaries in cache today by introducing extra parameters in Update / EditWhen building with Any combination of these might create a different binary, at least the ones not relevant to build system. |
|
Since I have a docker image for the sole purpose of cross compiling I decided to test out some hacks based on my findings from my initial test. Note that this is very hacky, only for testing purposes, and it is done in a toolchain-purposed docker image. # This will force Conan to always consider the build as cross compiling
RUN sed -i '/def cross_build/a \ return True' /usr/local/lib/python3.8/dist-packages/conans/client/tools/oss.py
# This will trick automake configure to consider the build cross compile
RUN sed -i '/self.build,/a \ self.build = "x86_64-linux"' /usr/local/lib/python3.8/dist-packages/conans/client/build/autotools_environment.pyI'm not sure if that last one is a problem with automake or the library, or something else. With the changes above I can successfully run |
|
Hi, I'm also facing an issue when "cross-building" from x86_64 Debian10 (build server,
ERROR: Full console outputFull autoconf log (config.log)see also #11437 Here is my current workaround: |
|
Bumping because I ran into the exact same issue when building for Yocto x64 on an Ubuntu x64 host. Interestingly everything worked and I didn't notice that Conan thought it's not cross-compiling, until I added gRPC as a dependency. gRPC needs a runnable So I guess there are two issues here:
With the emerge of ARM laptops this can become a more common issue, e.g. when building from an ARM Linux laptop to Raspberry. Also note that there is a possible duplicate issue: #9808 |
|
Bump. Ran into an issue with the |
|
I ran into a similar issue here, maybe the suggested workaround also works for you? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As strange as it sounds I'm trying to cross compile from Linux x86_64 to Linux x86_64, using a Yocto SDK Toolchain.
I use two profiles (
-pr:band-pr:h).A lot of recipes work out-of-the-box, but not all. Currently struggling with libbacktrace (because of boost).
It uses autotools.
Here is output of building with two Yocto toolchains, one from x86_64 to armv7hf and one from x86_64 to x86_64:
https://github.com/eirikb/proof-of-conan/runs/5742649170?check_suite_focus=true
The one failing will say:
The
--host(and--target) is not passed.This seems logical enough, and the check in https://github.com/conan-io/conan/blob/develop/conans/client/tools/oss.py#L460 will check if
host_osorhost_archis not likebuild_osorbuild_arch.I'm not sure how to solve this, perhaps some additional flag somewhere? Maybe it is already possible?
As I understand using two profiles by itself doesn't necessarily mean cross building.
In addition I did some tests, by forcing
cross_buildingin oss.py to always returnTrue.Then
--hostand--targetwould be passed, but automake didn't consider it cross build. I'm not 100% sure why not, could be a similar arch vs arch check? The parameters were x86_64-linux-gnu . If I changed these, to for example x86_64-linux it would cross build, even when they were equal. I did this directly in autotools_environment.py.The text was updated successfully, but these errors were encountered: