GCC-7 and glibc-2.27 back compat code #13177

ken2812221 commented at 4:08 PM on May 6, 2018: contributor

The __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.

ken2812221 renamed this:
~~GCC-7 and glibc-2.27 compat code~~
WIP[]GCC-7 and glibc-2.27 compat code
on May 6, 2018

ken2812221 renamed this:
~~WIP[]GCC-7 and glibc-2.27 compat code~~
[WIP]GCC-7 and glibc-2.27 compat code
on May 6, 2018

ken2812221 force-pushed on May 6, 2018

ken2812221 commented at 11:50 PM on May 6, 2018: contributor

Still have some probleams. Why doesn't it be allowed to export these symbols.

bitcoin-cli: export of symbol stdout not allowed
bitcoin-cli: export of symbol stderr not allowed
bitcoin-tx: export of symbol stdout not allowed
bitcoin-tx: export of symbol stdin not allowed
bitcoin-tx: export of symbol stderr not allowed
qt/bitcoin-qt: export of symbol stdout not allowed
qt/bitcoin-qt: export of symbol in6addr_any not allowed
qt/bitcoin-qt: export of symbol stderr not allowed

ken2812221 renamed this:
~~[WIP]GCC-7 and glibc-2.27 compat code~~
[WIP]GCC-7 and glibc-2.27 back compat code
on May 7, 2018

ken2812221 force-pushed on May 7, 2018

meshcollider added the label Build system on May 7, 2018

laanwj commented at 9:29 AM on May 7, 2018: member

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)

ken2812221 commented at 10:31 AM on May 7, 2018: contributor

I actually don't know this too much, but I think thery all need to be exported.

0000000002537398 g    D  .bss   0000000000000000  Base        _end
000000000251ca40 g    DO .bss   0000000000000008  GLIBC_2.2.5 stdout
000000000251ca30 g    D  .data  0000000000000000  Base        _edata
00000000024a7d00  w   DO .data.rel.ro   0000000000000010  GLIBC_2.2.5 in6addr_any
000000000251ca30 g    D  .bss   0000000000000000  Base        __bss_start
000000000251ca60 g    DO .bss   0000000000000008  GLIBC_2.2.5 stderr
000000000014a690 g    DF .init  0000000000000000  Base        _init
00000000016596b0 g    DF .fini  0000000000000000  Base        _fini

laanwj commented at 10:42 AM on May 7, 2018: member

_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.

theuni commented at 1:36 PM on May 8, 2018: member

@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__?

theuni commented at 2:35 PM on May 8, 2018: member

This should take care of in6addr_any:

--- a/src/net.cpp
+++ b/src/net.cpp
@@ -2254,7 +2254,7 @@ bool CConnman::InitBinds(const std::vector<CService>& binds, const std::vector<C
     if (binds.empty() && whiteBinds.empty()) {
         struct in_addr inaddr_any;
         inaddr_any.s_addr = INADDR_ANY;
-        fBound |= Bind(CService(in6addr_any, GetListenPort()), BF_NONE);
+        fBound |= Bind(CService((in6_addr)IN6ADDR_ANY_INIT, GetListenPort()), BF_NONE);
         fBound |= Bind(CService(inaddr_any, GetListenPort()), !fBound ? BF_REPORT_ERROR : BF_NONE);
     }
     return fBound;

ken2812221 force-pushed on May 8, 2018

ken2812221 commented at 5:12 PM on May 8, 2018: contributor

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.

ken2812221 force-pushed on May 8, 2018

ken2812221 force-pushed on May 10, 2018

ken2812221 force-pushed on May 14, 2018

MarcoFalke added this to the milestone 0.17.0 on May 31, 2018

ken2812221 force-pushed on Jun 2, 2018

ken2812221 commented at 6:01 PM on June 2, 2018: contributor

I couldn't find any way not to export stdin, stdout, stderr. Also, it is harmless to export them since glibc is versioned, so I just ignore them in symbol-check.py.

ken2812221 renamed this:
~~[WIP]GCC-7 and glibc-2.27 back compat code~~
GCC-7 and glibc-2.27 back compat code
on Jun 2, 2018

GCC-7 and glibc-2.27 compat code 908c1d7745

Use IN6ADDR_ANY_INIT instead of in6addr_any fc6a9f2ab1

ken2812221 force-pushed on Jun 2, 2018

Add stdin, stdout, stderr to ignored export list 253f592909

ken2812221 force-pushed on Jun 2, 2018

MarcoFalke assigned theuni on Jul 11, 2018

Sjors commented at 10:59 AM on July 12, 2018: member

This improves #13604 such that it produces ARM binaries that work on Xenial when cross-compiling on Bionic.

laanwj commented at 2:26 PM on July 12, 2018: member

utACK 253f5929097548fb10ef995002dedbb8dadb6a0d

laanwj merged this on Jul 12, 2018

laanwj closed this on Jul 12, 2018

laanwj referenced this in commit dcb154e5aa on Jul 12, 2018

ken2812221 deleted the branch on Jul 12, 2018

theuni commented at 5:50 PM on July 12, 2018: member

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.

ken2812221 commented at 5:55 PM on July 12, 2018: contributor

It caused a segfault on travis for qt 4. But qt 4 has gone now. I am not sure if we should get rid of wrap.

fanquake referenced this in commit 19d8ca5cc1 on Jul 16, 2018

underdarkskies referenced this in commit a17756f4bb on Jul 26, 2018

underdarkskies referenced this in commit 777e12c4cd on Jul 26, 2018

cfox referenced this in commit 74079801de on Jul 26, 2018

codablock referenced this in commit f411823c9a on Aug 13, 2018

codablock referenced this in commit 5c5bea3d72 on Aug 13, 2018

UdjinM6 referenced this in commit c09f57bd78 on Aug 13, 2018

alejandromgk referenced this in commit eae1493884 on Feb 20, 2019

alejandromgk referenced this in commit 7aea08a255 on Apr 3, 2019

CryptoCentric referenced this in commit b1e5fac728 on Apr 25, 2019

CryptAxe referenced this in commit 240b580985 on Jun 10, 2019

MarcoFalke locked this on Sep 8, 2021