even if we issue a FatalError afterwards

I am not sure about the maximum font name length in X but just in
case use snprintf instead of memcpy to be sure nothing dangerous can
happen here.

This is a partial copy from XlibInt.c's _XPrintDefaultError, which had
some minor changes since being copied. Update to reflect these
changes. Also comment some more lines as their result was unused an
cluttered the output.

and insert one single space

Also comment the code and convert error messages to warnings.

Fix write past the end of singlePath if PATH contains dirs longer than PATH_MAX.

Attributes GH PR #614: https://github.com/ArcticaProject/nx-libs/pull/614

Fixes: ArcticaProject/nx-libs#610

Will only be useful at build time, since installation strips any
RPATH/RUNPATH again.

Using libtool, the nxproxy binary will be replaced by a shell script
wrapper that correctly pulls in required libraries (like libXcomp), thus
making it possible to start the binary directly in the build directory.

This wrapper is dropped during installation time.

This is a C program, so enabling or disabling C++11 support will not do
anything useful.

At most it'll lead to errors when using libtool, which is the next
change to come...

We need this to be able to execute the resulting nxagent binary from
within the build directory.

nx-X11: build programs with a temporary RPATH/RUNPATH value and a relinked version with the system location.

While the install target explicitly installs the relinked
system-location version of a program, we do not actually use this.

Currently, we copy nxagent directly out of the build root.

Same method as used in the previous commit, but easier done thanks to
autotools and libtool.

Fixes: ArcticaProject/nx-libs#610

As discussed in ArcticaProject/nx-libs#610, we need a way to load
libNX_X11 as a fake version of libX11 into nxagent's address space.

For doing so, we have to link against libX11 at build-time and specify
a(n) RPATH/RUNPATH to our libX11 -> libNX_X11 compat symlinks.

This commit is essentially doing a cross between options 3 and 4
discussed in the provided GH issue.

We link libX11 early (before specifying -Lcompat_symlinks_dir), so that
the linker finds the "real" libX11 version with the libX11 SONAME. This
leads to our binary depending upon both libX11 and libNX_X11 SONAMEs. We
already always added RPATH/RUNPATH, but these values are not passed down
to dependent libraries.

What happens at run-time is that the loader searches for a libX11
SONAME, takes RPATH/RUNPATH into account and loads our libNX_X11 library
instead via the compat symlinks. This satisfies the libX11 SONAME and
dependent libraries will *not* load the system libX11 version again.

Debian's dpkg-shlibdeps isn't quite happy about this mismatching SONAME
situation, so instruct to look the other way while we're minding our
business.

Fixes: ArcticaProject/nx-libs#610

Attributes GH PR #615: https://github.com/ArcticaProject/nx-libs/pull/615

Fixes: ArcticaProject/nx-libs#612
Fixes: ArcticaProject/nx-libs#572

Fixes ArcticaProject/nx-libs#572

with very few exceptions which require careful thinking ;-)

==28424== 6 bytes in 1 blocks are definitely lost in loss record 1 of 7
==28424==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==28424==    by 0x541D4D9: strndup (strndup.c:43)
==28424==    by 0x4E8AD4B: ChannelEndPoint::getTCPHostAndPort(char**, long*) const (ChannelEndPoint.cpp:311)
==28424==    by 0x4EBE9CC: ConnectToRemote(ChannelEndPoint&) (Loop.cpp:6656)
==28424==    by 0x4EB0A4C: SetupProxyConnection() (Loop.cpp:3205)
==28424==    by 0x4EDC81A: handleNegotiationInLoop(int&, fd_set&, fd_set&, timeval&) (Loop.cpp:14308)
==28424==    by 0x4EAE40F: NXTransPrepare (Loop.cpp:2576)
==28424==    by 0x4EAA801: NXTransContinue (Loop.cpp:1610)
==28424==    by 0x4EB50C9: WaitCleanup() (Loop.cpp:4436)
==28424==    by 0x4EA9507: NXTransProxy (Loop.cpp:1235)
==28424==    by 0x400B2A: main (Main.c:111)