build: Allow export of environ symbols and work around rv64 toolchain issue #17569

This export was introduced in #17270 which added

//! Necessary on some platforms
extern char** environ;

This should (finally) make the gitian build pass again (fix issue #17525.).

Built on top of #17538 which should be merged first.

I also think it'd be OK to remove the exports check completely. It was introduced back in the day because of symbol collisions between dynamically-linked Qt and the built-in statically built OpenSSL which could have scary implications.

This hasn't been the case for ages—ever since Qt5 and before, we've statically linked Qt—and we don't even use OpenSSL anymore. I don't think a binary that exports symbols can usually cause problems (exporting excessive numbers of symbols would be an indication that something is going wrong in the link, but besides that).

The check is already being skipped for some architectures.

It looks like there is a third problem that needs to be fixed before gitian passes again, the RISC-V binaries fail on the NX (non-executable stack) check.

I'm really confused as to what could cause this. Will try to bisect. I suspect it's another unexpected by-effect of #17270, because it passes with 1baf7d1819317e4f4aeeaba2f9d72057e63b1fea.

Edit: no, it's not #17270, I don't have the issue with 0bb37e437e9cb4a29476edc9fa42f3e03c8bd797

Edit: bisected it to b49b6b0f7090cc15860d815fb0ef306ddfc718ba . Seems that linking to OpenSSL was the only thing that made it set noexecstack, on RISC-V. I'm not sure why yet, although we do explicitly pass -Wa,--noexecstack" CFLAGS there. (removed "needs gitian build" for now as i'm sure it will fail, will add it back after fixing this)

Added a workaround to force noexecstack on RISC-V (I can't find any reason why this is different from other platforms, so blaming it on the immaturity of the toolchain, FWIW: gcc 9.2.1 on native Fedora RISC-V does get this right):

    # Workaround for Ubuntu's g++ compiler for RV64, which
    # doesn't add .note.GNU-stack sections automatically unlike other platforms,
    # resulting in a NX failure of the binary in security-check.py
    # TODO: remove this when no longer needed
    if [ "${i}" = "riscv64-linux-gnu" ]; then
      HOST_LDFLAGS="${HOST_LDFLAGS_BASE} -Wl,-z,noexecstack"
    else
      HOST_LDFLAGS="${HOST_LDFLAGS_BASE}"
    fi

This is necessary now that the flag is no longer "inherited" through OpenSSL's build settings.

I think this should be it.

<!--a722867cd34abeea1fadc8d60700f111-->

Gitian builds

Issue (hopefully correctly) reported upstream: https://bugs.launchpad.net/ubuntu/+source/gcc-8-cross-ports/+bug/1853740 (updated commit message and comment for upstream issue)

<!--a722867cd34abeea1fadc8d60700f111-->

Gitian builds

I'm going to untag this as needing backport to 0.19, as per my comments here:

Is backporting either of these really required?

The changes that necessitated https://github.com/bitcoin/bitcoin/commit/f6e42256fe8900ed90f9644906b77f97e1600952 (https://github.com/bitcoin/bitcoin/pull/18175/commits/102547606f512f791ded0a610afe9f41b3ef2666 here) are not in the 0.19 branch.

As for https://github.com/bitcoin/bitcoin/pull/17569/commits/eafd2593674b6890418a50eadf69425071b824e4, the 0.19.1rc2 RISCV binaries still have GNU_STACK marked as RW, because we're still receiving it from OpenSSL: