Make should only run configure if config.var already exists:
$ make
./configure --reconfigure
./configure: 65: .: config.vars: not found
./configure --reconfigure
./configure: 65: .: config.vars: not found
Makefile:179: recipe for target 'ccan/config.h' failed
make: *** [ccan/config.h] Error 2
They are quite chatty and fail very rarely, so let's not have them spam our
logs. Failures should print to stderr anyway.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Previously, by uncommenting NO_VALGRIND in Makefile, the variable
was not propagated and the pytest children processes would still
try to use Valgrind.
Setting these options could fail the `pytest` target if `pytest-test-groups` is
not installed.
Fixes#1508
Signed-off-by: Christian Decker <decker.christian@gmail.com>
This is the first example of the py.test style fixtures which should allow us to
write much cleaner and nicer tests.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Since we include the tail of the version in the default aliasname with
DEVELOPER, we want to see more of it.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We had quite a few users running into issues because the `--dev-xyz` options and
`dev-xyz` RPC calls were available. Before a release we should make sure that
the default compilation flags are safe.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Retrying gives spurious failures, since we see transactions from previous
runs. That makes it near impossible to diagnose the actual problem.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In particular, this gets some MacOS fixes from #1327.
It also includes a major intmap update which fixes corner cases in traversals,
and requires ccan/bitops.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This lets us clearly mark transition features, in a way that they can
be removed after 0.6 is released.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
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.
This should solve what @icota wanted in https://github.com/ElementsProject/lightning/pull/1035 in a much cleaner way.
In particular, this allows you to say what configurator should use, independent
of what other compilation should use, and reverts the '-static' which broke
MacOS.
Fixes: #1059
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
As of version 5.0 Android requires all dynamically linked executables to support PIE. This allows programs to be loaded at a different addresses, making it harder for attackers to target.
Enable with PIE=1
When cross compiling it's important that the resulting config.h reflects the platform we are building for and not the one we are building on.
Otherwise we end up with a config.h that defines headers that are not there on the target platform, wrong endnianness and so on.
The -static flag is there to be able to easily run the configurator test executables on the build machine with qemu-*.
E.g. Without the -static flag the resulting dynamically linked ARM executables complain about the lack of linker (/lib/ld-linux-armhf.so or /system/bin/linker for Android), since these files are not usually available on the build machine building statically avoids this problem and results in a proper config.h for cross compiling.
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>
Christian Decker
Rusty Russell
Jan Sarenik
practicalswift
Zhen Zhang
arowser
Igor Cota
Carl Dong
ZmnSCPxj