There were too many problems found so drop this functionality on
the stable branch. It will be revisited for the next release.
This reverts commit 4561f7e9c6.
This reverts commit 6abf3f4c87.
This reverts commit 820c0ceb2e.
This reverts commit 698371a650.
This reverts commit 6ae42df651.
This reverts commit f1665ac7fb.
This reverts commit 14263e17e4.
This reverts commit 07cd2298dc.
This reverts commit 8e101704c3.
It's much more difficult to test for this on Windows since the
headers have version guards. Just play it safe and assume it is
missing. We can remove this check when we raise the base requirements
to Vista (or newer).
GnuTLS can have different crypto backends, and it is rarely gcrypt
these days. So we should not be including that unconditionally,
and should not be pointing people at it either. Also remove the
section about Win32 binaries as those are out of date and probably
insecure. Lastly remove the section about static builds as it is
a general issue and in no way complete with just the GnuTLS portions.
We don't want to lose the checks performed by assert() in release builds
so make sure we remove NDEBUG. Based on work by Tim Waugh for Red Hat.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@5168 3789f03b-4d11-0410-bbf8-ca57d06f2519
Fixes problems with cmake detection of GnuTLS. The current CMakeLists.txt uses check_function_exists to identify legacy versions of GnuTLS but cmake performs this test by linking a small test program. If libgnutls, libgcrypt, or libgpg-error are outside the default library search path, linking the test program fails even though gnutls and it's dependencies are installed. This patch makes it possible to specify the location of each of the three libraries independently and only as needed.
Fl::screen_work_area() was added after FLTK 1.3.0, so we need to have
checks that it is actually present on the current system.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@5008 3789f03b-4d11-0410-bbf8-ca57d06f2519
Remove the in-tree versin of FLTK. Maintaining such a copy is way too
much work, and it's constantly out of sync. Let's document what the
main developers (ie Cendio) are using instead.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4951 3789f03b-4d11-0410-bbf8-ca57d06f2519
Implement client side multi-head support. Requires a FLTK patched to support
fullscreen over multiple monitors. Will properly report screen configuration
to the server, provided the server supports it.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4935 3789f03b-4d11-0410-bbf8-ca57d06f2519
GnuTLS 3.x has removed gnutls_transport_set_global_errno() in favour of
gnutls_transport_set_errno(). Make sure we call the right errno function
depending on which GnuTLS we're using.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4922 3789f03b-4d11-0410-bbf8-ca57d06f2519
Failure to find FLTK dependencies is only fatal for our version of FLTK.
When using the system version we have to assume it's built the way the
user wants.
git-svn-id: svn://svn.code.sf.net/p/tigervnc/code/trunk@4838 3789f03b-4d11-0410-bbf8-ca57d06f2519
Our FLTK patches modified FLTK's autotools-based build system so that HAVE_XFIXES and HAVE_XCURSOR were defined in FLTK's config.h, but those changes never made it into the CMake-based build system used by the in-tree version of FLTK. Further, our build system was allowing silent failures whenever Xft, Xinerama, Xcursor, or Xfixes were not present on the build system. Now, the lack of these libraries is treated as a fatal error, since these libraries are critical for TigerVNC functionality.
Some platforms (I'm looking at you, MinGW64) have gettext but not iconv, so the build fails because iconv.h is missing. Thus, disable NLS if either gettext or iconv is not found.
This is subtle, but add_definitions() also adds definitions to the windres command line when building with MinGW, and this causes subsequent barfage because windres doesn't grok the -static-libgcc flag.
Clarify when in-tree version of Zlib is being used, and remove redundant "not found" message for the system version (find_package() already takes care of that.)
Only try to run the libjpeg-turbo test program if we aren't cross-compiling. In a cross-compile environment, we'll settle for just making sure it compiles and links. Even though that can theoretically produce situations in which the wrong libjpeg is linked, such situations would be exceedingly rare in a cross-compile environment, since there is no "system libjpeg" to accidentally link with.