depends: Fix libX11 build on gcc 8 #12990

Commit taken from https://github.com/mirror/libX11/commit/a9dafdd57c71473fa3a2ec4887e973e4e9876d83

Checking out the commit below mine gives this error:

$ git checkout fa461f49c9147037fa63a141a5390f614ad2438e~ && gcc --version && make -j 2 libX11
gcc (GCC) 8.0.1 20180324 (Red Hat 8.0.1-0.20)

Building libX11...
make[4]: Entering directory 'bitcoin/depends/work/build/x86_64-pc-linux-gnu/libX11/1.6.2-bcf0487a3e3/modules/im/ximcp'
  CC       imLcIm.lo
In function '_XimWriteCachedDefaultTree',
    inlined from '_XimCreateDefaultTree' at imLcIm.c:635:2,
    inlined from '_XimLocalOpenIM' at imLcIm.c:722:5:
imLcIm.c:488:5: error: 'strcpy' forming offset 2 is out of the bounds [0, 1] [-Werror=array-bounds]
     strcpy (m->fname+strlen(name)+1, encoding);
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors

@MarcoFalke Is there anything else needed to recreated this? I've tested on Ubuntu 18.04 with GCC 8.0.1 20180414 (experimental) [trunk revision 259383] and don't see any errors when building libX11 inside depends.

Indeed... My gcc claims "20180324" and yours "20180414", not sure if that is the cause.

For reference: I reproduced this by running a fedora:28 docker container.

Concept ACK, if there is no released version of libX11 with this patch yet.

Further looking at this by using the gcc8 from the opensuse:tumbleweed docker gives a nice basis for bisecting gcc:

gcc8 [trunk revision 258445] --> fails
gcc8 [trunk revision 259308] --> succeeds

utACK fa461f49c9147037fa63a141a5390f614ad2438e. I didn't build but I did check out the upstream repository and confirm the patch is identical to the commit on the master branch.

I slightly tend toward closing this, since it might be a bug on gcc8, which is not yet released and only meant for beta testing.

I think I agree. Patching a dependency because it won't compile at some point between two experimental versions of a compiler doesn't seem entirely necessary.

I think I agree. Patching a dependency because it won't compile at some point between two experimental versions of a compiler doesn't seem entirely necessary.

Agree - I concept ACKed because this patch is upstream so we'd get it with a bump of libX11 too. If it is a temporary work-around for an intermediate broken experimental compiler I'd also tend toward closing this. We can't accommodate for every broken tool out there.