travis: Actually build for arm

[NickeZ]

Fixes #3466

Changelog-None

[cdecker]

Wow, that's what I call a fast turnaround from reporting to fixing this, great work @NickeZ 👍

ACK df76dde

[NickeZ]

@cdecker do you prefer that I force push or create --fixups?

[cdecker]

@cdecker do you prefer that I force push or create --fixups?

Both work fine, we track changes to PRs here when force pushing. I personally use fixups on larger PRs to make it easier on reviewers :-)

[rustyrussell]

Seems like there's more work to do on building the libraries?
Nevermind, I just saw #3469

/usr/lib/gcc-cross/aarch64-linux-gnu/7/../../../../aarch64-linux-gnu/bin/ld: skipping incompatible external/libwallycore.a when searching for -lwallycore

/usr/lib/gcc-cross/aarch64-linux-gnu/7/../../../../aarch64-linux-gnu/bin/ld: cannot find -lwallycore

/usr/lib/gcc-cross/aarch64-linux-gnu/7/../../../../aarch64-linux-gnu/bin/ld: skipping incompatible external/libsecp256k1.a when searching for -lsecp256k1

/usr/lib/gcc-cross/aarch64-linux-gnu/7/../../../../aarch64-linux-gnu/bin/ld: cannot find -lsecp256k1

/usr/lib/gcc-cross/aarch64-linux-gnu/7/../../../../aarch64-linux-gnu/bin/ld: skipping incompatible external/libbacktrace.a when searching for -lbacktrace

/usr/lib/gcc-cross/aarch64-linux-gnu/7/../../../../aarch64-linux-gnu/bin/ld: skipping incompatible external/libsodium.a when searching for -lsodium

/usr/lib/gcc-cross/aarch64-linux-gnu/7/../../../../aarch64-linux-gnu/bin/ld: cannot find -lsodium

[NickeZ]

This will have to be rebased again when #3464 is merged.

[rustyrussell]

Rebased on master...

[rustyrussell]

Sigh. Still doesn't build :(

[NickeZ]

I'll take a look at it. I'm a bit surprised though since it built locally for me.

[NickeZ]

It seems like we were over-caching a bit when the whole directory external was cached. That directory actually contains source code as well which definitely shouldn't be cached.

I had to start building x86_64 things in its own directory so that I could cache those files.

Now it seems like I dug up a bunch of issues since CI probably has used old versions of external dependencies for a while.

[NickeZ]

At least armhf and aarch64 builds now 🎉. However there are some failures which I don't know how to deal with:

Could this be that libwally doesn't support gcc-4.8 or have we introduced this breaking change some other time? Pretty sure this PR doesn't introduce this regression.

../../../libwally-core/src/elements.c: In function ‘wally_asset_pak_whitelistproof’:
../../../libwally-core/src/elements.c:629:5: error: ‘for’ loop initial declarations are only allowed in C99 mode
     for (size_t i = 0; i < num_keys; ++i) {
     ^
../../../libwally-core/src/elements.c:629:5: note: use option -std=c99 or -std=gnu99 to compile your code

I have no idea:

==================================== ERRORS ====================================
_________________ ERROR at teardown of test_onchain_middleman __________________
[gw0] linux -- Python 3.7.5 /opt/python/3.7.5/bin/python3.7
request = <SubRequest 'teardown_checks' for <Function test_onchain_middleman>>
    @pytest.fixture
    def teardown_checks(request):
        """A simple fixture to collect errors during teardown.
    
        We need to collect the errors and raise them as the very last step in the
        fixture tree, otherwise some fixtures may not be cleaned up
        correctly. Require this fixture in all other fixtures that need to either
        cleanup before reporting an error or want to add an error that is to be
        reported.
    
        """
        errors = TeardownErrors()
        yield errors
    
        if errors.has_errors():
            # Format a nice list of everything that went wrong and raise an exception
            request.node.has_errors = True
>           raise ValueError(str(errors))
E           ValueError: 
E           Node errors:
E            - lightningd-3: Node exited with return code 1
E           Global errors:

[rustyrussell]

gcc 4.8 is ancient. Still, let me see if we can wrangle it using more configure hacks...

Ah, libwally. I've filed a bug ElementsProject/libwally-core#176

[NickeZ]

It seems a fix has been merged in in libwally upstream. Will wait until new release is out and then bump the dependency.

[cdecker]

Since we updated libwally (#3559) I rebased this on top of master, let's see if it build.

[NickeZ]

Looks better, but still some test that fails...

[rustyrussell]

I hacked it to not assume gcc, too. Let's see how this goes...

[NickeZ]

I think it should be possible to reproduce the CI failure locally since now it's part of the tests that fail and not just compilation problems. I don't have much knowledge about lightning-c so it would take too much time for me to dig into it.

[rustyrussell]

Trivial rebase

[rustyrussell]

This is a complete mess, I'm assigning to @cdecker. Perhaps it's something to do with caching, since there are complaints that "lightningd/lightningd" DNE.

[cdecker]

After rebasing it appears that the build passes correctly. @NickeZ can you confirm that this is what you'd expect? If it is working I'm happy to merge it asap :-)

[NickeZ]

Yeah sure, I think this PR still is valid.

[cdecker]

ACK 2a83825