-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[package] m4/1.4.18: Cannot cross-compile x86_64 -> armhf #6777
Comments
A verbose build would be nice.
with autotools.make(args=["V=1"]) Then we can see what invocation failed. |
Verbose log is a bit longer so I attach file |
Can you please give a as much information about the toolchain you're using as you can? I think it's weird that Can you try the following things, in sequence? And report back your findings.
If the last command fails, please patch the |
Sorry, I fix link to my toolchain in first post (dockerfile)
Yep, it looks strange. |
@madebr I tried your suggestions, nothing changes. I attach logs with your pr |
The Please tell me how to get your toolchain setup. |
@madebr Debian Buster, then
And then you can use my profile from the first post. |
Thanks for the detailed build instructions. Looks like the It fails now when linking
Perhaps it is missing a linker flag? |
It looks like a bug in clang because android/ndk#184 (comment) and https://bugs.webkit.org/attachment.cgi?id=351411&action=diff maybe we can try smth similar but I'm not familar with autotools |
I think you need to pass the compiler runtime library ( The error then becomes:
I don't know how to install |
This comment has been minimized.
This comment has been minimized.
Is it safe to say that at this point, the |
I'm sure it's ok with native armhf compilation (only upstream CCI) but not your PR due to new commit 5222d9c (i think it should be reverted). Cross-compilation don't work as it was. I tried with libclang-common-11-dev:armhf but recipe fails too and libclang-common-11-dev:armhf : Conflicts: libclang-common-11-dev Maybe you have ideas what i do wrong |
I don't think so.
|
I've tested building #6694 with #6822 using armv7hf and armv8 and it works fine. armv8 profile:
armv7hf profile:
I need a standalone LLVM arm toolchain.. |
#6822 is packaging a gcc compiler.
Your compiler toolchain does not even have compiler-rt, so forcing this is not okay. |
But __mulodi4 is unique to libclang so you cannot compile m4 without libclang
The main is problem is my toolchain has compiler-rt (but for x86_64). I have libclang-common-11-dev: amd64 with clang-11: amd64, meanwhile clang wanna libclang-common-11-dev: armhf (which contains libclang_rt.builtins-armhf.a) but libclang-common-11-dev : armhf conflicts with clang-11: amd64 ... It looks like a vicious circle because I have either compiler without rt or only rt without compiler (except gcc)
It can be packaged with gcc and libclang (no conflict here) |
Have you got it working? |
nothing, packages conflict |
@planetmarshall |
I don't recall exactly but think it was related to this - https://lists.llvm.org/pipermail/llvm-dev/2017-December/119635.html More specifically, clang implicitly links to the compiler runtime provided by GNU or LLVM depending n the platform. Clang may handle this better since I submitted that PR - see also https://clang.llvm.org/docs/Toolchain.html#compiler-runtime |
I think if you compile M4 with clang it generates some symbols which are only available in |
There is no builds with clang on linux (and libstdc++) https://c3i.jfrog.io/c3i/misc/summary.html?json=https://c3i.jfrog.io/c3i/misc/logs/pr/6694/4-production/m4/1.4.18//summary.json |
@planetmarshall It looks like c3i does not build m4 with clang: https://c3i.jfrog.io/c3i/misc/summary.html?json=https://c3i.jfrog.io/c3i/misc/logs/pr/6694/4-production/m4/1.4.18//summary.json |
I think this is specific to the configuration used to build clang. It builds fine with the conan docker images that use the clang APT I haven't examined the particular configuration used to build the APT packages - but maybe they have the missing symbols built into clang whereas the compiler built from source on my system does not (and the cross compiler appears to have a similar issue). Either way, it does seem to be a toolchain issue and not something specific to the conan recipe. |
So the new conan docker images also build clang from source, and crucially include the following cmake flag - See https://github.com/conan-io/conan-docker-tools/blob/master/modern/clang/Dockerfile for details. |
#6694 failed to build with native clang (not only cross compilation) with default profile without --rtlib=compiler-rt |
So it depends on the toolchain. Which belongs in the profile/conf. |
Yep, it depends on toolchain. But after #6694 you cannot build m4 on armhf with default profile for clang. Look at spack spack/spack#10280, they force flag --rtlib=compiler-rt for clang (I don't understand why m4 can be build with gcc+libgcc but not with clang+libgcc) |
I'm sorry to report that following #6694 the m4 recipe doesn't work for me anymore either. Failing to build using clang on Ubuntu 20.04. My clang/llvm comes from the standard apt-get package clang-10 so not using a custom build. Like everyone else, the issue here is the removal of the --rtlib=compiler-rt flag, which causes the following link error trying to build m4:
As for why it works in gcc but not clang, my understanding is that the code generated by gcc has the required function built in, but clang includes the method only in the compiler-rt library. By removing that library, the offending instruction can no longer be resolved by the linker. |
I am also seeing the same
I know the suggestion is to use a profile but this way was less disruption for all involved. |
I"m open to add |
Sorry I can't help with a docker image, but as mentioned, in my case it's Ubuntu 20.04 with the standard distro clang package, ie apt-get install clang I feel that this combo should definitely be supported and made working. The suggestion by @Kaylx looks good to me, I have tried that change and it does allow the recipe to build correctly for me too. |
Current recipe with 1.4.19 can be build correctly (with profile from first post) without any hacks from profile |
Package and Environment Details (include every applicable attribute)
Conan profile (output of
conan profile show default
orconan profile show <profile>
if custom profile is in use)Steps to reproduce (Include if Applicable)
conan install m4/1.4.18@ --profile armhf --build
Logs (Include/Attach if Applicable)
Click to expand log
Looks like conan detects arm-linux-gnueabihf-ld but autotools uses /usr/bin/ld instead of arm-linux-gnueabihf-ld
The text was updated successfully, but these errors were encountered: