On CI it is nice to cache the external dependencies. However if we
always compile them in the same folder we cannot cache for multiple
different architectures. After this commit native compile targets will
still live in `external` but cross compiled versions will live in
`external/<arch>`.
Requesting them is done by setting BUILD=<target_arch>
Otherwise autotools (used by external dependencies like
libsodium) is not happy with setting cross-compilation
variables and may possibly lead to unexpected results.
* remove libbase58, use base58 from libwally
This removes libbase58 and uses libwally instead.
It allocates and then frees some memory, we may want to
add a function in wally that doesn't or override
wally_operations to use tal.
Signed-off-by: Lawrence Nahum lawrence@greenaddress.it
Also one less headache for reproducible builds. But unlike
libsodium, this only seems common in Ubuntu.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If we change an upstream URL, all submodules break. Users would need
to run 'git submodule sync'. Note that the libbacktrace fix was merged
upstream so this is no longer necessary, but it's good for future changes.
Also, stress-testing reveals that git submodule fails locking
'.git/config' when run in paralell. It also segfaults and other
problems.
This is my final attempt to fix submodules; I've wasted far too many
days on obscure problems it creates: I've already lost one copy of my
repo to apparently unfixable submodule preoblems. The next "fix" will
be to simply import the source code so it works properly.
Reported-by: @jsarenik
Fixes: #1543
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Proposed fix for issue #1231 - FreeBSD (tcsh) build problem due
to HOST environment variable.
The variable is used for cross-compilation. The process may be
improved even further in the future. So far this hot fix.
This is how the error before the fix looked like on Arch Linux with
GNU libtool 2.4.6.40-6ca5-dirty:
$ make installcheck
...
make[4]: Entering directory '/home/jasan/lightning/external/libwally-core/src/secp256k1'
/usr/bin/mkdir -p 'testinstall/home/jasan/lightning/external/libwally-core/..'
/bin/sh ./libtool --mode=install /usr/bin/install -c libsecp256k1.la 'testinstall/home/jasan/lightning/external/libwally-core/..'
Usage: /home/jasan/lightning/external/libwally-core/src/secp256k1/libtool [OPTION]... [MODE-ARG]...
Try 'libtool --help' for more information.
libtool: error: 'testinstall/home/jasan/lightning/external/libwally-core/..' must be an absolute directory name
make[4]: *** [Makefile:910: install-libLTLIBRARIES] Error 1
make[4]: Leaving directory '/home/jasan/lightning/external/libwally-core/src/secp256k1'
make[3]: *** [Makefile:1253: install-exec-recursive] Error 1
make[3]: Leaving directory '/home/jasan/lightning/external/libwally-core/src'
make[2]: *** [Makefile:429: install-exec-recursive] Error 1
make[2]: Leaving directory '/home/jasan/lightning/external/libwally-core'
make[1]: *** [external/Makefile:41: external/libwallycore.a] Error 2
rm external/libwally-core/src/secp256k1/libsecp256k1.la
make[1]: Leaving directory '/home/jasan/lightning'
make: *** [Makefile:430: installcheck] Error 2
Then there was linking error which needed to be fixed by correcting
the idea of installing external libraries to a particular directory.
We can't rely on the existence or not of a header, as Carl's
delete-and-make-submodule change showed.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This doesn't cover external libs in general (which *could* be effected by
CFLAGS), but at least all our own objects are rebuilt.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
You will want to 'make distclean' after this.
I also removed libsecp; we use the one in in libwally anyway.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
