If we have the client library for postgres configure will define HAVE_POSTGRES
the same way it already handled libsqlite3 an we start linking against it.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
/bin/sh: 1: ccan/ccan/cdump/tools/cdump-enumstr: Text file busy
make[1]: *** [common/Makefile:81: common/gen_htlc_state_names.h] Error 2
make[1]: *** Waiting for unfinished jobs....
The fix is to make sure all generated headers are made first, and
thus cdump-enumstr.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
installcheck calls $(MAKE) under the covers, which can race with the
current builds, and we can try installing something which is still
being built:
collect2: fatal error: ld terminated with signal 11 [Segmentation fault], core dumped
compilation terminated.
/usr/bin/ld: can not read symbols: File truncated
/usr/bin/ld: .eh_frame/.stab edit: File truncated
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.interp' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.note.ABI-tag' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.note.gnu.build-id' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.gnu.hash' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.dynsym' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.dynstr' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.gnu.version' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.gnu.version_r' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.rela.dyn' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.rela.plt' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.init' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.plt' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.plt.got' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.text' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.fini' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.rodata' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.eh_frame' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.init_array' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.fini_array' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.data.rel.ro' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.dynamic' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.got' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `.data' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `xautodata_json_command' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `xautodata_hooks' not in segment
/usr/bin/ld: lightningd/lightningd: warning: allocated section `xautodata_type_to_string' not in segment
Makefile:390: recipe for target 'lightningd/lightningd' failed
make[1]: *** [lightningd/lightningd] Error 1
make[1]: Leaving directory '/home/rusty/lightning'
Makefile:553: recipe for target 'installcheck' failed
make: *** [installcheck] Error 2
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Our reproducibile builds use the dirname to get version, but they have
a v in them (the tools/repro-build.sh script gets this right, so I
copied that).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This simplifies the dependencies:
1. Objs depend on headers, not other objs.
2. Programs depend on objs.
3. A .o file will generally implicitly depend on the .c file it's built from.
4. If a file has a build line, it's often better to list all deps there.
5. I spotted some missing 'make clean' files.
The particular problem in this case seems to be that make would use
tools/test/gen_test.c before it was ready. It's probably confused by
the use of recursive make via update-mocks, so explicitly split that
into two stages.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Dumb programs which have a --daemon option call fork() early. This is
terrible UX since startup errors get lost: the program exits with
"success" immediately then you discover via the logs that it didn't
start at all.
However, forking late introduced a heap of problems with changing
pids. Instead, fork early but keep stderr and the parent around: if
we fail early on, the parent fails with us. We release our parent
with an explicit action just before the main loop.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
My test machine started failing on dynamic plugin tests, unable to
find the lightning module:
ModuleNotFoundError: No module named 'lightning'
This is because plugins at startup are run from whatever directory
you're in, but on refresh are run from the lightning-dir.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We always rebuild headerversions to examine critical system headers,
however that stomps on parallel builds with:
make[1]: execvp: tools/headerversions: Text file busy
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This makes it build for me on FreeBSD 11:
1. $(MAKE) has to passed through into update-mocks.
2. FreeBSD sed doesn't turn \n into a newline on RHS.
3. Bash and mako dependencies were missing from INSTALL.md
Fixes: #2850
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Add a test for checking that the bolt-gens do the right thing
for a fairly exhaustive test case set (and that it compiles).
Note that this doesn't check that we've got the memory assignment
pieces worked out.
It's got a kind of exotic reliance on the update-mocks in that in
order to depend on as little of the wire/ code as possible (we
only import wire/wire.h), we include an AUTOGENERATE comment
in the test_cases CSV file, and then run update-mocks as part of
the build for that file.
updates the bolt version to 6639cef095a2ecc7b8f0c48c6e7f2f906fbfbc58.
this requires us to use the new bolt parser at generate-bolt.py
and updates to all of the type specifications (ie. from u8 -> byte)
These are generalized from our internal implementations.
The main difference is that 'struct json_escaped' is now 'struct
json_escape', so we replace that immediately.
The difference between lightningd's json-writing ringbuffer and the
more generic ccan/json_out is that the latter has a better API and
handles escaping transparently if something slips through (though
it does offer direct accessors so you can mess things up yourself!).
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I decided to try a faster implementation, only to find our crc32c was
not correct! Ouch.
I removed the crc32c functions from ccan/crc, and added a new crc32c
module which has the Mark Adler x86-64-optimized variants.
We bump gossip_store version again, since csums have changed.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Unfortuntely we get spurious uninitialized variable warnings with
anything but -O3 or no optimization, so set default CWARNFLAGS
appropriately.
MCP bench results without optimization:
store_load_msec:28509-31001(29206.6+/-9.4e+02)
vsz_kb:580004-580016(580006+/-4.8)
store_rewrite_sec:11.640000-12.730000(11.908+/-0.41)
listnodes_sec:1.790000-1.880000(1.83+/-0.032)
listchannels_sec:21.180000-21.950000(21.476+/-0.27)
routing_sec:2.210000-11.160000(7.126+/-3.1)
peer_write_all_sec:36.270000-41.200000(38.168+/-1.9)
MCP bench with -Og: 22% speedup vs no optimization
store_load_msec:21963-23645(22841+/-6.6e+02)
vsz_kb:579916
store_rewrite_sec:10.080000-10.960000(10.456+/-0.3)
listnodes_sec:1.280000-1.390000(1.338+/-0.047)
listchannels_sec:14.770000-16.080000(15.518+/-0.46)
routing_sec:0.990000-6.660000(3.958+/-2.2)
peer_write_all_sec:29.950000-32.950000(31.138+/-1)
MCP bench with -O2: 31% speedup vs no optimization
store_load_msec:20713-22088(21505.6+/-4.8e+02)
vsz_kb:579928
store_rewrite_sec:9.570000-11.200000(10.192+/-0.54)
listnodes_sec:0.960000-1.090000(1.028+/-0.045)
listchannels_sec:10.400000-11.770000(11.012+/-0.48)
routing_sec:0.300000-3.140000(1.978+/-1.1)
peer_write_all_sec:28.980000-30.310000(29.572+/-0.44)
MCP bench with -O3 -flto: 36% speedup vs no optimization
store_load_msec:19616-20191(19862.6+/-1.9e+02)
vsz_kb:578452
store_rewrite_sec:8.980000-9.960000(9.55+/-0.32)
listnodes_sec:0.920000-1.910000(1.18+/-0.38)
listchannels_sec:8.960000-9.450000(9.206+/-0.16)
routing_sec:0.730000-1.850000(1.438+/-0.42)
peer_write_all_sec:28.090000-29.410000(28.772+/-0.42)
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
In particular, `make unittest/bitcoin/test/run-secret_eq_consttime`
didn't set VALGRIND if it was set via config.vars, so runs for a *long*
time.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
These weren't checked by CI yet, and they are really short so I just added
them to the check-python target.
Signed-off-by: Christian Decker <decker.christian@gmail.com>
Christian Decker
Rusty Russell
Jacob Rapoport
darosior
ZmnSCPxj
lisa neigut
Nicola Squartini