crossdirect: issue compiling 'zeitgeist' for armhf

Forgot to mention, this'll likely complain about the package not being available to armhf, so use the branch feature/unity8_arches, it's not much more than changing the arch field for many packages.

By Luca Weiss on 2019-03-26T21:23:48

@z3ntu I'm so sorry about this!

Based on that stack overflow answer, I guess you can try (re?)installing g++ in the native chroot manually.

I might not get to testing this myself for a while: Do you happen to have the full log? And does this happen on aarch64?

By Zhuowei Zhang on 2019-03-27T01:45:58

Thanks for reporting!

The displayed error message actually seems to be a bug, so after applying the patch from https://src.fedoraproject.org/rpms/libtool/blob/c9ab88f8c2d82e1c64933aafe72b3fe7b3b223b1/f/libtool-2.4.6-fatal-handler.patch, the error message is libtool: error: unsupported hardcode properties See the libtool documentation for more information. Fatal configuration error.

Great that you figured that out, where did you apply that patch?

Full log - without the libtool patch - is here: 223-zeitgeist-crossdirect-without-patched-libtool-error.txt

From the stackoverflow thread, it seems to be a good idea to look at the configure output. What I'm noticing is this:

checking for armv6-alpine-linux-muslgnueabihf-objdump... no
checking for objdump... objdump
...
checking for armv6-alpine-linux-muslgnueabihf-ar... no
checking for ar... ar
...
checking for armv6-alpine-linux-muslgnueabihf-strip... no
checking for strip... strip
checking for armv6-alpine-linux-muslgnueabihf-ranlib... no
checking for ranlib... ranlib

We do have cross compiling binutils in binutils-armhf, but do not make them available with crossdirect yet, maybe this would resolve the issue. But this is just a guess, I would have assumed that the binutils running with qemu should also work (even if slower).

By Oliver Smith on 2019-03-27T07:24:02

I actually just meant applying the patch linked to the libtool file in the zeitgeist source directory, which makes the ../../libtool: line 2639: func__fatal_error: not found error go away and make it display the real error message (libtool: error: unsupported hardcode properties See the libtool documentation for more information. Fatal configuration error.)

By Luca Weiss on 2019-03-27T16:33:21

reading the libtool source... around here is where the error message comes from (last line of the selected area):

https://github.com/Distrotech/libtool/blob/a5c6466528c060cc4660ad0319c00740db0e42ba/build-aux/ltmain.in#L6355-L6423

Any ideas? :p

By Oliver Smith on 2019-03-31T02:14:37

mentioned in merge request pmbootstrap!1773 (merged)

By Oliver Smith on 2019-04-01T20:05:11

I have added debug prints to the libtool script, and figured out what happened. A patch is in pmbootstrap!1773 (merged)

So this is where the error message comes from:

if test yes != "$lib_linked"; then
    func_fatal_configuration "unsupported hardcode properties"
fi

Further up, it starts with lib_linked=yes, and then it gets set to no here, because hardcode_action is an empty string:

lib_linked=yes
case $hardcode_action in
...
    *) lib_linked=no ;;
esac

So what's going on with hardcode_action?

The first mention in the libtool script is here: hardcode_action=immediate

Further down it says:

# ### BEGIN LIBTOOL TAG CONFIG: CXX

# The linker used to build libraries.
LD=""
...
# How to hardcode a shared library path into an executable.
hardcode_action=

This is weird, right? And there's a stackoverflow post with similar symptoms (mind the awesome unicorn on april fools day): https://stackoverflow.com/q/16942530

The solution from the SO post does not help, but it got me looking at configure's output again.

Without the patch, it says:

checking for armv6-alpine-linux-muslgnueabihf-g++... no
checking for armv6-alpine-linux-muslgnueabihf-c++... no
checking for armv6-alpine-linux-muslgnueabihf-gpp... no
checking for armv6-alpine-linux-muslgnueabihf-aCC... no
checking for armv6-alpine-linux-muslgnueabihf-CC... no
checking for armv6-alpine-linux-muslgnueabihf-cxx... no
checking for armv6-alpine-linux-muslgnueabihf-cc++... no
checking for armv6-alpine-linux-muslgnueabihf-cl.exe... no
checking for armv6-alpine-linux-muslgnueabihf-FCC... no
checking for armv6-alpine-linux-muslgnueabihf-KCC... no
checking for armv6-alpine-linux-muslgnueabihf-RCC... no
checking for armv6-alpine-linux-muslgnueabihf-xlC_r... no
checking for armv6-alpine-linux-muslgnueabihf-xlC... no
checking for g++... g++

So for some reason, it can't find armv6-alpine-linux-muslgnueabihf-g++ in the foreign arch chroot. It is in /native/usr/bin though, but we don't add that to the PATH, because then it wouldn't go through ccache. The symlink is provided by our ccache-cross-symlinks package though, and after installing that in the foreign chroot, configure doesn't fall back to g++ anymore. And also libtool doesn't have hardcode_action=, and doesn't run into the error anymore

With that being said, /usr/bin/autopoint seems to be hanging every other time I try to build zeitgeist (qemu related issue I guess), and right now I can't it to do a full build. But it definitively got past the error mentioned by @z3ntu once (which I was also able to reproduce). Would be great if you could try the patch!

By Oliver Smith on 2019-04-01T21:01:27

This is weird, right? And there's a stackoverflow post with similar symptoms

That's also how far I have gotten; awesome that you found the issue!

By Luca Weiss on 2019-04-01T20:32:38

closed via merge request pmbootstrap!1773 (merged)

By Oliver Smith on 2019-04-03T20:22:50

added category::crossdirect type::bug labels

crossdirect: issue compiling 'zeitgeist' for armhf

Child items 0

Activity