__divmoddi4
code was modified from https://github.com/gcc-mirror/gcc/blob/master/libgcc/libgcc2.c . I manually find the older glibc version of log2f by objdump, use .symver
to specify the certain version.
__divmoddi4
code was modified from https://github.com/gcc-mirror/gcc/blob/master/libgcc/libgcc2.c . I manually find the older glibc version of log2f by objdump, use .symver
to specify the certain version.
Still have some probleams. Why doesn’t it be allowed to export these symbols.
0bitcoin-cli: export of symbol stdout not allowed
1bitcoin-cli: export of symbol stderr not allowed
2bitcoin-tx: export of symbol stdout not allowed
3bitcoin-tx: export of symbol stdin not allowed
4bitcoin-tx: export of symbol stderr not allowed
5qt/bitcoin-qt: export of symbol stdout not allowed
6qt/bitcoin-qt: export of symbol in6addr_any not allowed
7qt/bitcoin-qt: export of symbol stderr not allowed
Still have some probleams. Why doesn’t it be allowed to export these symbols.
Because it’s an executable - it’s unnecessary to export any symbols, so if that happens that usually points towards a problem during linking that can cause weird issues with shared libraries later on. (however, maybe there’s a good reason for these then they could be added to the exceptions)
I actually don’t know this too much, but I think thery all need to be exported.
00000000002537398 g D .bss 0000000000000000 Base _end
1000000000251ca40 g DO .bss 0000000000000008 GLIBC_2.2.5 stdout
2000000000251ca30 g D .data 0000000000000000 Base _edata
300000000024a7d00 w DO .data.rel.ro 0000000000000010 GLIBC_2.2.5 in6addr_any
4000000000251ca30 g D .bss 0000000000000000 Base __bss_start
5000000000251ca60 g DO .bss 0000000000000008 GLIBC_2.2.5 stderr
6000000000014a690 g DF .init 0000000000000000 Base _init
700000000016596b0 g DF .fini 0000000000000000 Base _fini
_end
_fini
and such are harmless to export. I don’t think they’re strictly necessary for execution, but they’re just part of the linking process, and delimit the various sections.
Not sure about the rest, though.
stdout
/stderr
/in6addr_any
sound like they should be exported from the C library, not our executable.
I’ll look into it as well when I get around to playing around with Ubuntu 18.04 (I guess that’s where you find this combination?).
FYI @theuni.
@laanwj Thanks.
Those are interesting. in6addr_any is weak-linked for some reason. If necessary we could just define a new constant. No clue about stdout/stderr, I’ll have to play with that as well. @ken2812221 Is it not sufficient to define the replacements with their own symbol names? Why use __wrap__?
This should take care of in6addr_any:
0--- a/src/net.cpp
1+++ b/src/net.cpp
2@@ -2254,7 +2254,7 @@ bool CConnman::InitBinds(const std::vector<CService>& binds, const std::vector<C
3 if (binds.empty() && whiteBinds.empty()) {
4 struct in_addr inaddr_any;
5 inaddr_any.s_addr = INADDR_ANY;
6- fBound |= Bind(CService(in6addr_any, GetListenPort()), BF_NONE);
7+ fBound |= Bind(CService((in6_addr)IN6ADDR_ANY_INIT, GetListenPort()), BF_NONE);
8 fBound |= Bind(CService(inaddr_any, GetListenPort()), !fBound ? BF_REPORT_ERROR : BF_NONE);
9 }
10 return fBound;
This should take care of in6addr_any:
Thanks. That does work.
Is it not sufficient to define the replacements with their own symbol names? Why use wrap?
I thought it would conflict with the library, so I didn’t try that before. But it works now. No. it doesn’t, this would cause a segfault on Travis.
Sorry for the late review…
I really dislike the use of wrap here. I suspect it will get in the way of things like sanitizers and lto, and it really shouldn’t be necessary since the other compat stubs manage to work without it.
I’ll follow up with another PR if I can come up with a working solution without wrapping.