If you do update-mocks in a dirty tree, the recursive make that it
uses will try to rebuild things! Suppress that.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Otherwise it can end up complaining that it can't find python2, which
we don't have listed as a dependency and is deprecated anyway.
Also reformatted a bit to make the options more readable and minimize
future conflicts.
And add secp_recovery to headers, while we're at it.
```
./wire/wire.h:7:10: fatal error: secp256k1_recovery.h: No such file or directory
#include <secp256k1_recovery.h>
^~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
Makefile:254: recipe for target 'connectd/test/run-initiator-success.o' failed
make: *** [connectd/test/run-initiator-success.o] Error 1
m
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
```
make: *** No rule to make target 'external/gheap/gheap.h', needed by 'bitcoin/chainparams.o'. Stop.
make: *** Waiting for unfinished jobs....
```
Just simplify the Makefile to make all the external headers we use
dependent on submodcheck.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Quote marks are not special to make: as it can't find
external/"x86_64-linux-gnu"/libwally-core-build/src/libwallycore.la
it always insists on rebuilding it (which rebuilds the world).
If we have spaces in TARGET_DIR, we're in trouble already.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Changelog-None
Without this gcc 4.8 defaults to an older standard and cannot compile
the code:
```
gcc-4.8 -DHAVE_CONFIG_H -I. -I../../libwally-core/src -I../../libwally-core -I../../libwally-core/src/ccan -DWALLY_CORE_BUILD=1 -Wall -Wextra -Wpedantic -Wcast-align -Wnested-externs -Wshadow -Wstrict-prototypes -Wformat -Wformat-security -Wformat-nonliteral -O0 -ggdb -DBUILD_ELEMENTS=1 -flax-vector-conversions -Wno-unused-function -Wno-long-long -Wno-overlength-strings -Wno-variadic-macros -fvisibility=hidden -g -O2 -MT libwallycore_la-elements.lo -MD -MP -MF .deps/libwallycore_la-elements.Tpo -c ../../libwally-core/src/elements.c -o libwallycore_la-elements.o
../../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
```
Changelog-None
We specify `PYTHON_VERSION=3` to prevent libwally's ./configure from searchin
for python2, which some distros have started removing, and we were requiring
it only for the configuration step anyway.
Changelog-Changed: dependencies: We no longer depend on python2 which has reached end-of-life
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>
