so -lmingwthrd is definitely being passed here
luke-jr: looking at the mingw-w64 source, in regards to mingwthrd I'm seeing: As _CRT_MT is getting defined in libgcc when using shared version, or it is getting defined by startup code itself, this library is a dummy version for supporting the link library for gcc's option -mthreads. As we support TLS-cleanup even without specifying this library, this library is deprecated and just kept for compatibility.
The only code in mingwthrd_mt.c is: int _CRT_MT_OLD = 1;
mingwthrd_mt.c is the source for libmingwthrd.a
It seems that at least part of the other commits are intended to not require users to remove the fee_estimatoin.dat file, is that correct?
stevenroose: seems kinda rude to have to spend a week before you can get fee estimates again?
stevenroose: (if you just did that, users who upgrade would continue to not get estimates for below 1s/B until they deleted their fee_estimates.dat, they'd continue using the same buckets that were current when f_e.dat was generated)
aj: where does that week come from?
does that mean a week before getting any estimate? Or a week before getting reliable ones?
stevenroose: i'm not sure of the numbers, but there's a weekly cycle so i wouldn't really trust the numbers much without that much data
i think it would be nice to have #15600 in 0.20.0, as it prevents leaking private key data into core dumps; does anyone here know enough about linux internals and madvise() to review / test it?
wumpus: yes, but even if there is an issue on travis' side then at least Github should warn that one of the checks didn't run in my opinion. I had to send them an email. Seems like they can't think of a better way to track issues %)
luke-jr: jonatack: wumpus: Do you think that #15600 may create too crippled core files and thus impede debugging? In gdb, inspecting a core file and trying to read the value of a pointer that points to a removed page I get "Cannot access memory at address 0x803200000" which looks like a bogus/dangling pointer.