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)

SAFE_FREE has set defaultUnixPath_ to NULL already

==7689== 50 bytes in 5 blocks are definitely lost in loss record 1 of 2
==7689==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7689==    by 0x54074D9: strndup (strndup.c:43)
==7689==    by 0x4E7D803: ChannelEndPoint::getTCPHostAndPort(char**, long*) const (ChannelEndPoint.cpp:309)
==7689==    by 0x4EC9D93: ConnectToRemote(ChannelEndPoint&) [clone .constprop.144] (Loop.cpp:6660)
==7689==    by 0x4ECB94E: SetupProxyConnection() (Loop.cpp:3204)
==7689==    by 0x4ECE824: handleNegotiationInLoop(int&, fd_set&, fd_set&, timeval&) [clone .isra.129] (Loop.cpp:14312)
==7689==    by 0x4ED0F8A: NXTransPrepare (Loop.cpp:2575)
==7689==    by 0x4ED1C35: NXTransContinue (Loop.cpp:1609)
==7689==    by 0x4ED1D7B: WaitCleanup() (Loop.cpp:4440)
==7689==    by 0x4ED2343: NXTransProxy (Loop.cpp:1234)
==7689==    by 0x400B2A: main (Main.c:111)

Same as in WriteBuffer.cpp

Valgrind will complain about uninitialized data, but we are only
writing to the memory here.

(partially) fixes ArcticaProject/nx-libs#612

(partially) fixes ArcticaProject/nx-libs#612

Fix another memleak

(partially) fixes ArcticaProject/nx-libs#612

was missing in the non-abstract code path

(partially) fixes ArcticaProject/nx-libs#612

fixes a memory leak

(partially) fixes ArcticaProject/nx-libs#612

Fixes: ArcticaProject/nx-libs#572

Fixes ArcticaProject/nx-libs#572

as reported by valgrind

Should avoid copy-constructing objects again.

nxcomp/src/Log.cpp: don't confuse users with useless warning messages in case that a log line append operation was requested, but the message level has lower precedence than the current log filter.

Especially don't flush data out mid-append.
Doing so will lead to the next append operation failing.

Should fix messages queuing up indefinitely (until they are discarded at
program termination, at least) and missing messages in general.

Fixes: ArcticaProject/nx-libs#577
Fixes: ArcticaProject/nx-libs#611

Also handle errors due to missing buffers gracefully.

This error is surprisingly easy to trigger, so we should make sure that
the program does not crash.