2005-04-25 15:55:06 +00:00
|
|
|
# To compile this into a configure script, you need:
|
2019-01-01 13:49:05 +00:00
|
|
|
# * Autoconf 2.59c or newer
|
2005-04-25 15:55:06 +00:00
|
|
|
# * Gtk (for $prefix/share/aclocal/gtk.m4)
|
|
|
|
# * Automake (for aclocal)
|
|
|
|
# If you've got them, running "autoreconf" should work.
|
|
|
|
|
Switch to using automake for the Unix autoconfigured build.
mkfiles.pl no longer generates a Makefile.in, but instead generates a
Makefile.am on which mkauto.sh runs automake. This means that the
autoconfigured makefile now does build-time dependency tracking (a
standard feature of automake-generated makefiles), and is generally
more like what Unix people will expect.
Some of the old-style make command-line settings (VER=-DRELEASE=foo,
XFLAGS=-DDEBUG) will still work; the COMPAT settings are better done
by autoconfiguration, and my habitual 'XFLAGS="-g -O0"' for an easily
debuggable build will actually not work any more because CFLAGS is
specified _after_ XFLAGS, so I should instead write 'make CFLAGS=-O0'
(-g is the default in automake, removed at 'make install' time).
The new makefile will automatically degrade into one that builds the
command-line tools only, in the case where GTK could not be found. In
principle, therefore, it should be an adequate replacement for _both_
the static Unix makefiles, Makefile.gtk and Makefile.ux. I haven't
actually retired those in this commit, but I'm pretty tempted.
[originally from svn r9239]
2011-07-23 11:33:29 +00:00
|
|
|
# Version number is substituted by Buildscr for releases, snapshots
|
|
|
|
# and custom builds out of svn; X.XX shows up in ad-hoc developer
|
|
|
|
# builds, which shouldn't matter
|
|
|
|
AC_INIT(putty, X.XX)
|
2005-04-25 15:55:06 +00:00
|
|
|
AC_CONFIG_FILES([Makefile])
|
|
|
|
AC_CONFIG_HEADERS([uxconfig.h:uxconfig.in])
|
Switch to using automake for the Unix autoconfigured build.
mkfiles.pl no longer generates a Makefile.in, but instead generates a
Makefile.am on which mkauto.sh runs automake. This means that the
autoconfigured makefile now does build-time dependency tracking (a
standard feature of automake-generated makefiles), and is generally
more like what Unix people will expect.
Some of the old-style make command-line settings (VER=-DRELEASE=foo,
XFLAGS=-DDEBUG) will still work; the COMPAT settings are better done
by autoconfiguration, and my habitual 'XFLAGS="-g -O0"' for an easily
debuggable build will actually not work any more because CFLAGS is
specified _after_ XFLAGS, so I should instead write 'make CFLAGS=-O0'
(-g is the default in automake, removed at 'make install' time).
The new makefile will automatically degrade into one that builds the
command-line tools only, in the case where GTK could not be found. In
principle, therefore, it should be an adequate replacement for _both_
the static Unix makefiles, Makefile.gtk and Makefile.ux. I haven't
actually retired those in this commit, but I'm pretty tempted.
[originally from svn r9239]
2011-07-23 11:33:29 +00:00
|
|
|
AM_INIT_AUTOMAKE([-Wall -Werror foreign])
|
2005-04-25 15:55:06 +00:00
|
|
|
|
|
|
|
AC_PROG_INSTALL
|
Switch to using automake for the Unix autoconfigured build.
mkfiles.pl no longer generates a Makefile.in, but instead generates a
Makefile.am on which mkauto.sh runs automake. This means that the
autoconfigured makefile now does build-time dependency tracking (a
standard feature of automake-generated makefiles), and is generally
more like what Unix people will expect.
Some of the old-style make command-line settings (VER=-DRELEASE=foo,
XFLAGS=-DDEBUG) will still work; the COMPAT settings are better done
by autoconfiguration, and my habitual 'XFLAGS="-g -O0"' for an easily
debuggable build will actually not work any more because CFLAGS is
specified _after_ XFLAGS, so I should instead write 'make CFLAGS=-O0'
(-g is the default in automake, removed at 'make install' time).
The new makefile will automatically degrade into one that builds the
command-line tools only, in the case where GTK could not be found. In
principle, therefore, it should be an adequate replacement for _both_
the static Unix makefiles, Makefile.gtk and Makefile.ux. I haven't
actually retired those in this commit, but I'm pretty tempted.
[originally from svn r9239]
2011-07-23 11:33:29 +00:00
|
|
|
AC_PROG_RANLIB
|
2013-11-18 19:07:11 +00:00
|
|
|
ifdef([AM_PROG_AR],[AM_PROG_AR])
|
2013-10-26 14:00:10 +00:00
|
|
|
AM_PROG_CC_C_O
|
Switch to using automake for the Unix autoconfigured build.
mkfiles.pl no longer generates a Makefile.in, but instead generates a
Makefile.am on which mkauto.sh runs automake. This means that the
autoconfigured makefile now does build-time dependency tracking (a
standard feature of automake-generated makefiles), and is generally
more like what Unix people will expect.
Some of the old-style make command-line settings (VER=-DRELEASE=foo,
XFLAGS=-DDEBUG) will still work; the COMPAT settings are better done
by autoconfiguration, and my habitual 'XFLAGS="-g -O0"' for an easily
debuggable build will actually not work any more because CFLAGS is
specified _after_ XFLAGS, so I should instead write 'make CFLAGS=-O0'
(-g is the default in automake, removed at 'make install' time).
The new makefile will automatically degrade into one that builds the
command-line tools only, in the case where GTK could not be found. In
principle, therefore, it should be an adequate replacement for _both_
the static Unix makefiles, Makefile.gtk and Makefile.ux. I haven't
actually retired those in this commit, but I'm pretty tempted.
[originally from svn r9239]
2011-07-23 11:33:29 +00:00
|
|
|
|
2019-01-01 13:49:05 +00:00
|
|
|
AC_PROG_CC_C99
|
|
|
|
|
Switch to using automake for the Unix autoconfigured build.
mkfiles.pl no longer generates a Makefile.in, but instead generates a
Makefile.am on which mkauto.sh runs automake. This means that the
autoconfigured makefile now does build-time dependency tracking (a
standard feature of automake-generated makefiles), and is generally
more like what Unix people will expect.
Some of the old-style make command-line settings (VER=-DRELEASE=foo,
XFLAGS=-DDEBUG) will still work; the COMPAT settings are better done
by autoconfiguration, and my habitual 'XFLAGS="-g -O0"' for an easily
debuggable build will actually not work any more because CFLAGS is
specified _after_ XFLAGS, so I should instead write 'make CFLAGS=-O0'
(-g is the default in automake, removed at 'make install' time).
The new makefile will automatically degrade into one that builds the
command-line tools only, in the case where GTK could not be found. In
principle, therefore, it should be an adequate replacement for _both_
the static Unix makefiles, Makefile.gtk and Makefile.ux. I haven't
actually retired those in this commit, but I'm pretty tempted.
[originally from svn r9239]
2011-07-23 11:33:29 +00:00
|
|
|
# Mild abuse of the '--enable' option format to allow manual
|
|
|
|
# specification of setuid or setgid setup in pterm.
|
|
|
|
setidtype=none
|
|
|
|
AC_ARG_ENABLE([setuid],
|
|
|
|
[AS_HELP_STRING([--enable-setuid=USER],
|
|
|
|
[make pterm setuid to a given user])],
|
|
|
|
[case "$enableval" in
|
|
|
|
no) setidtype=none;;
|
|
|
|
*) setidtype=setuid; setidval="$enableval";;
|
|
|
|
esac])
|
|
|
|
AC_ARG_ENABLE([setgid],
|
|
|
|
[AS_HELP_STRING([--enable-setgid=GROUP],
|
|
|
|
[make pterm setgid to a given group])],
|
|
|
|
[case "$enableval" in
|
|
|
|
no) setidtype=none;;
|
|
|
|
*) setidtype=setgid; setidval="$enableval";;
|
|
|
|
esac])
|
|
|
|
AM_CONDITIONAL(HAVE_SETID_CMD, [test "$setidtype" != "none"])
|
|
|
|
AS_IF([test "x$setidtype" = "xsetuid"],
|
|
|
|
[SETID_CMD="chown $setidval"; SETID_MODE="4755"])
|
|
|
|
AS_IF([test "x$setidtype" = "xsetgid"],
|
|
|
|
[SETID_CMD="chgrp $setidval"; SETID_MODE="2755"])
|
|
|
|
AC_SUBST(SETID_CMD)
|
|
|
|
AC_SUBST(SETID_MODE)
|
2005-04-25 15:55:06 +00:00
|
|
|
|
2017-01-21 14:57:31 +00:00
|
|
|
AC_ARG_ENABLE([git-commit],
|
|
|
|
[AS_HELP_STRING([--disable-git-commit],
|
|
|
|
[disable embedding current git HEAD in binaries])],
|
|
|
|
[],
|
|
|
|
[if test -d "$srcdir/.git"; then
|
|
|
|
enable_git_commit=yes; else enable_git_commit=no; fi])
|
|
|
|
|
|
|
|
if test "x$enable_git_commit" = "xyes" -a ! -d "$srcdir/.git"; then
|
|
|
|
AC_ERROR([Cannot --enable-git-commit when source tree is not a git checkout])
|
|
|
|
fi
|
|
|
|
AM_CONDITIONAL(AUTO_GIT_COMMIT, [test "x$enable_git_commit" = "xyes"])
|
|
|
|
|
2010-05-19 18:22:17 +00:00
|
|
|
AC_ARG_WITH([gssapi],
|
|
|
|
[AS_HELP_STRING([--without-gssapi],
|
|
|
|
[disable GSSAPI support])],
|
|
|
|
[],
|
|
|
|
[with_gssapi=yes])
|
|
|
|
|
2015-08-31 12:05:51 +00:00
|
|
|
AC_ARG_WITH([quartz],
|
|
|
|
[AS_HELP_STRING([--with-quartz],
|
|
|
|
[build for the MacOS Quartz GTK back end])],
|
2016-03-23 22:14:13 +00:00
|
|
|
[AC_DEFINE([OSX_GTK], [1], [Define if building with GTK for MacOS.])
|
|
|
|
with_quartz=yes],
|
|
|
|
[with_quartz=no])
|
|
|
|
|
|
|
|
AM_CONDITIONAL([HAVE_QUARTZ],[test "x$with_quartz" = "xyes"])
|
2015-08-31 12:05:51 +00:00
|
|
|
|
2010-05-19 18:22:17 +00:00
|
|
|
WITH_GSSAPI=
|
|
|
|
AS_IF([test "x$with_gssapi" != xno],
|
|
|
|
[AC_DEFINE([WITH_GSSAPI], [1], [Define if building with GSSAPI support.])])
|
2008-11-22 22:49:27 +00:00
|
|
|
|
2011-07-23 11:36:25 +00:00
|
|
|
AC_ARG_WITH([gtk],
|
|
|
|
[AS_HELP_STRING([--with-gtk=VER],
|
2015-08-16 13:53:15 +00:00
|
|
|
[specify GTK version to use (`1', `2' or `3')])
|
2011-07-23 11:36:25 +00:00
|
|
|
AS_HELP_STRING([--without-gtk],
|
|
|
|
[do not use GTK (build command-line tools only)])],
|
2011-07-17 22:17:40 +00:00
|
|
|
[gtk_version_desired="$withval"],
|
|
|
|
[gtk_version_desired="any"])
|
|
|
|
|
|
|
|
case "$gtk_version_desired" in
|
2015-08-16 13:53:15 +00:00
|
|
|
1 | 2 | 3 | any | no) ;;
|
2011-07-23 11:36:25 +00:00
|
|
|
yes) gtk_version_desired="any" ;;
|
2011-07-17 22:17:40 +00:00
|
|
|
*) AC_ERROR([Invalid GTK version specified])
|
|
|
|
esac
|
|
|
|
|
2019-02-07 18:21:06 +00:00
|
|
|
AC_CHECK_HEADERS([utmpx.h],,,[
|
2005-04-25 23:28:25 +00:00
|
|
|
#include <sys/types.h>
|
|
|
|
#include <utmp.h>])
|
2005-04-25 18:51:15 +00:00
|
|
|
|
2015-09-26 13:17:51 +00:00
|
|
|
# Look for GTK 3, GTK 2 and GTK 1, in descending order of preference.
|
2015-08-16 13:53:15 +00:00
|
|
|
# If we can't find any, have the makefile only build the CLI programs.
|
2011-07-17 22:17:40 +00:00
|
|
|
|
|
|
|
gtk=none
|
|
|
|
|
2015-08-16 13:53:15 +00:00
|
|
|
case "$gtk_version_desired:$gtk" in
|
|
|
|
3:none | any:none)
|
Counterbodge a bodgy warning from 'aclocal'.
For ages, when rebuilding the configure script, I've had the
mysterious warning "configure.ac:120: warning: macro 'AM_PATH_GTK' not
found in library". The reason it was mysterious was that that use of
AM_PATH_GTK was inside an ifdef that checked whether it was defined,
and it actually wasn't being run!
Turns out the warning comes from 'aclocal', which is a Perl script
that (among other things) does bodgy text-matching to detect
unsupported autoconf/automake macros in your configure script. The
warning comes from the function scan_configure_dep() in that file, as
of aclocal-1.15. And, indeed, it ignores the ifdef structure, so it
doesn't notice that I've carefully guarded the use of that possibly-
undefined macro! (Though a comment in aclocal does acknowledge the
possibility, which is why it's only a warning.)
Against that bodgy and unreliable check, I've deployed an equally
bodgy and unreliable countermeasure, by changing the line spacing so
that AM_PATH_GTK appears in a context (specifically, not immediately
following a newline or space) where the regex will be confident that
it's a macro invocation. So that should squelch the warning.
2019-03-26 20:59:31 +00:00
|
|
|
ifdef([AM_PATH_GTK_3_0],[AM_PATH_GTK_3_0([3.0.0], [gtk=3], [])],
|
|
|
|
[AC_WARNING([generating configure script without GTK 3 autodetection])])
|
2015-08-16 13:53:15 +00:00
|
|
|
;;
|
|
|
|
esac
|
|
|
|
|
2015-09-26 13:17:51 +00:00
|
|
|
case "$gtk_version_desired:$gtk" in
|
|
|
|
2:none | any:none)
|
Counterbodge a bodgy warning from 'aclocal'.
For ages, when rebuilding the configure script, I've had the
mysterious warning "configure.ac:120: warning: macro 'AM_PATH_GTK' not
found in library". The reason it was mysterious was that that use of
AM_PATH_GTK was inside an ifdef that checked whether it was defined,
and it actually wasn't being run!
Turns out the warning comes from 'aclocal', which is a Perl script
that (among other things) does bodgy text-matching to detect
unsupported autoconf/automake macros in your configure script. The
warning comes from the function scan_configure_dep() in that file, as
of aclocal-1.15. And, indeed, it ignores the ifdef structure, so it
doesn't notice that I've carefully guarded the use of that possibly-
undefined macro! (Though a comment in aclocal does acknowledge the
possibility, which is why it's only a warning.)
Against that bodgy and unreliable check, I've deployed an equally
bodgy and unreliable countermeasure, by changing the line spacing so
that AM_PATH_GTK appears in a context (specifically, not immediately
following a newline or space) where the regex will be confident that
it's a macro invocation. So that should squelch the warning.
2019-03-26 20:59:31 +00:00
|
|
|
ifdef([AM_PATH_GTK_2_0],[AM_PATH_GTK_2_0([2.0.0], [gtk=2], [])],
|
|
|
|
[AC_WARNING([generating configure script without GTK 2 autodetection])])
|
2015-09-26 13:17:51 +00:00
|
|
|
;;
|
|
|
|
esac
|
|
|
|
|
2011-08-20 08:18:56 +00:00
|
|
|
case "$gtk_version_desired:$gtk" in
|
|
|
|
1:none | any:none)
|
Counterbodge a bodgy warning from 'aclocal'.
For ages, when rebuilding the configure script, I've had the
mysterious warning "configure.ac:120: warning: macro 'AM_PATH_GTK' not
found in library". The reason it was mysterious was that that use of
AM_PATH_GTK was inside an ifdef that checked whether it was defined,
and it actually wasn't being run!
Turns out the warning comes from 'aclocal', which is a Perl script
that (among other things) does bodgy text-matching to detect
unsupported autoconf/automake macros in your configure script. The
warning comes from the function scan_configure_dep() in that file, as
of aclocal-1.15. And, indeed, it ignores the ifdef structure, so it
doesn't notice that I've carefully guarded the use of that possibly-
undefined macro! (Though a comment in aclocal does acknowledge the
possibility, which is why it's only a warning.)
Against that bodgy and unreliable check, I've deployed an equally
bodgy and unreliable countermeasure, by changing the line spacing so
that AM_PATH_GTK appears in a context (specifically, not immediately
following a newline or space) where the regex will be confident that
it's a macro invocation. So that should squelch the warning.
2019-03-26 20:59:31 +00:00
|
|
|
ifdef([AM_PATH_GTK],[AM_PATH_GTK([1.2.0], [gtk=1], [])],[
|
2013-06-15 19:58:10 +00:00
|
|
|
# manual check for gtk1
|
|
|
|
AC_PATH_PROG(GTK1_CONFIG, gtk-config, absent)
|
|
|
|
if test "$GTK1_CONFIG" != "absent"; then
|
2019-03-12 07:52:52 +00:00
|
|
|
GTK_CFLAGS="`"$GTK1_CONFIG" --cflags`"
|
2013-06-15 19:58:10 +00:00
|
|
|
GTK_LIBS=`"$GTK1_CONFIG" --libs`
|
2019-03-12 07:52:52 +00:00
|
|
|
AC_SUBST(GTK_CFLAGS)
|
|
|
|
AC_SUBST(GTK_LIBS)
|
2013-06-15 19:58:10 +00:00
|
|
|
gtk=1
|
|
|
|
fi
|
|
|
|
])
|
2011-08-20 08:18:56 +00:00
|
|
|
;;
|
|
|
|
esac
|
|
|
|
|
2019-03-12 07:52:52 +00:00
|
|
|
case "$gtk" in
|
|
|
|
1)
|
|
|
|
# Add some manual #defines to make the GTK 1 headers work when
|
|
|
|
# compiling in C99 mode. Left to themselves, they'll expect the
|
|
|
|
# old-style pre-C99 GNU semantics of 'inline' and 'extern inline',
|
|
|
|
# with the effect that they'll end up defining out-of-line
|
|
|
|
# versions of the inlined functions in more than one translation
|
|
|
|
# unit and cause a link failure. Override them to 'static inline',
|
|
|
|
# which is safe.
|
|
|
|
GTK_CFLAGS="$GTK_CFLAGS -DG_INLINE_FUNC='static inline' -DG_CAN_INLINE=1"
|
|
|
|
esac
|
|
|
|
|
Switch to using automake for the Unix autoconfigured build.
mkfiles.pl no longer generates a Makefile.in, but instead generates a
Makefile.am on which mkauto.sh runs automake. This means that the
autoconfigured makefile now does build-time dependency tracking (a
standard feature of automake-generated makefiles), and is generally
more like what Unix people will expect.
Some of the old-style make command-line settings (VER=-DRELEASE=foo,
XFLAGS=-DDEBUG) will still work; the COMPAT settings are better done
by autoconfiguration, and my habitual 'XFLAGS="-g -O0"' for an easily
debuggable build will actually not work any more because CFLAGS is
specified _after_ XFLAGS, so I should instead write 'make CFLAGS=-O0'
(-g is the default in automake, removed at 'make install' time).
The new makefile will automatically degrade into one that builds the
command-line tools only, in the case where GTK could not be found. In
principle, therefore, it should be an adequate replacement for _both_
the static Unix makefiles, Makefile.gtk and Makefile.ux. I haven't
actually retired those in this commit, but I'm pretty tempted.
[originally from svn r9239]
2011-07-23 11:33:29 +00:00
|
|
|
AM_CONDITIONAL(HAVE_GTK, [test "$gtk" != "none"])
|
2011-07-17 22:17:40 +00:00
|
|
|
|
2015-08-16 13:53:15 +00:00
|
|
|
if test "$gtk" = "2" -o "$gtk" = "3"; then
|
2008-04-02 17:32:17 +00:00
|
|
|
ac_save_CFLAGS="$CFLAGS"
|
|
|
|
ac_save_LIBS="$LIBS"
|
|
|
|
CFLAGS="$CFLAGS $GTK_CFLAGS"
|
|
|
|
LIBS="$GTK_LIBS $LIBS"
|
|
|
|
AC_CHECK_FUNCS([pango_font_family_is_monospace pango_font_map_list_families])
|
|
|
|
CFLAGS="$ac_save_CFLAGS"
|
|
|
|
LIBS="$ac_save_LIBS"
|
|
|
|
fi
|
2005-04-25 15:55:06 +00:00
|
|
|
|
|
|
|
AC_SEARCH_LIBS([socket], [xnet])
|
2010-05-19 18:22:17 +00:00
|
|
|
|
|
|
|
AS_IF([test "x$with_gssapi" != xno],
|
|
|
|
[AC_SEARCH_LIBS(
|
|
|
|
[dlopen],[dl],
|
|
|
|
[],
|
|
|
|
[AC_DEFINE([NO_LIBDL], [1], [Define if we could not find libdl.])
|
|
|
|
AC_CHECK_HEADERS([gssapi/gssapi.h])
|
|
|
|
AC_SEARCH_LIBS(
|
|
|
|
[gss_init_sec_context],[gssapi gssapi_krb5 gss],
|
|
|
|
[],
|
|
|
|
[AC_DEFINE([NO_GSSAPI_LIB], [1], [Define if we could not find a gssapi library])])])])
|
2005-04-25 15:55:06 +00:00
|
|
|
|
2011-07-20 17:50:02 +00:00
|
|
|
AC_CHECK_LIB(X11, XOpenDisplay,
|
|
|
|
[GTK_LIBS="-lX11 $GTK_LIBS"
|
|
|
|
AC_DEFINE([HAVE_LIBX11],[],[Define if libX11.a is available])])
|
2010-02-20 19:06:30 +00:00
|
|
|
|
2020-12-24 20:45:28 +00:00
|
|
|
AC_CHECK_FUNCS([getaddrinfo posix_openpt ptsname setresuid strsignal updwtmpx fstatat dirfd futimes setpwent endpwent getauxval elf_aux_info sysctlbyname])
|
2012-05-13 15:59:27 +00:00
|
|
|
AC_CHECK_DECLS([CLOCK_MONOTONIC], [], [], [[#include <time.h>]])
|
Hardware-accelerated SHA-512 on the Arm architecture.
The NEON support for SHA-512 acceleration looks very like SHA-256,
with a pair of chained instructions to generate a 128-bit vector
register full of message schedule, and another pair to update the hash
state based on those. But since SHA-512 is twice as big in all
dimensions, those four instructions between them only account for two
rounds of it, in place of four rounds of SHA-256.
Also, it's a tighter squeeze to fit all the data needed by those
instructions into their limited number of register operands. The NEON
SHA-256 implementation was able to keep its hash state and message
schedule stored as 128-bit vectors and then pass combinations of those
vectors directly to the instructions that did the work; for SHA-512,
in several places you have to make one of the input operands to the
main instruction by combining two halves of different vectors from
your existing state. But that operation is a quick single EXT
instruction, so no trouble.
The only other problem I've found is that clang - in particular the
version on M1 macOS, but as far as I can tell, even on current trunk -
doesn't seem to implement the NEON intrinsics for the SHA-512
extension. So I had to bodge my own versions with inline assembler in
order to get my implementation to compile under clang. Hopefully at
some point in the future the gap might be filled and I can relegate
that to a backwards-compatibility hack!
This commit adds the same kind of switching mechanism for SHA-512 that
we already had for SHA-256, SHA-1 and AES, and as with all of those,
plumbs it through to testcrypt so that you can explicitly ask for the
hardware or software version of SHA-512. So the test suite can run the
standard test vectors against both implementations in turn.
On M1 macOS, I'm testing at run time for the presence of SHA-512 by
checking a sysctl setting. You can perform the same test on the
command line by running "sysctl hw.optional.armv8_2_sha512".
As far as I can tell, on Windows there is not yet any flag to test for
this CPU feature, so for the moment, the new accelerated SHA-512 is
turned off unconditionally on Windows.
2020-12-24 11:40:15 +00:00
|
|
|
AC_CHECK_HEADERS([sys/auxv.h asm/hwcap.h sys/sysctl.h sys/types.h glob.h])
|
2012-05-13 15:59:27 +00:00
|
|
|
AC_SEARCH_LIBS([clock_gettime], [rt], [AC_DEFINE([HAVE_CLOCK_GETTIME],[],[Define if clock_gettime() is available])])
|
2005-04-25 15:55:06 +00:00
|
|
|
|
2015-05-18 12:57:45 +00:00
|
|
|
AC_CACHE_CHECK([for SO_PEERCRED and dependencies], [x_cv_linux_so_peercred], [
|
|
|
|
AC_COMPILE_IFELSE([
|
|
|
|
AC_LANG_PROGRAM([[
|
|
|
|
#define _GNU_SOURCE
|
|
|
|
#include <features.h>
|
|
|
|
#include <sys/socket.h>
|
|
|
|
]],[[
|
|
|
|
struct ucred cr;
|
|
|
|
socklen_t crlen = sizeof(cr);
|
|
|
|
return getsockopt(0, SOL_SOCKET, SO_PEERCRED, &cr, &crlen) +
|
|
|
|
cr.pid + cr.uid + cr.gid;
|
|
|
|
]]
|
|
|
|
)],
|
|
|
|
AS_VAR_SET(x_cv_linux_so_peercred, yes),
|
|
|
|
AS_VAR_SET(x_cv_linux_so_peercred, no)
|
|
|
|
)
|
|
|
|
])
|
|
|
|
AS_IF([test AS_VAR_GET(x_cv_linux_so_peercred) = yes],
|
|
|
|
[AC_DEFINE([HAVE_SO_PEERCRED], [1],
|
|
|
|
[Define if SO_PEERCRED works in the Linux fashion.])]
|
|
|
|
)
|
|
|
|
|
2012-07-19 04:42:34 +00:00
|
|
|
if test "x$GCC" = "xyes"; then
|
|
|
|
:
|
2019-01-02 19:03:13 +00:00
|
|
|
AC_SUBST(WARNINGOPTS, ['-Wall -Werror -Wpointer-arith -Wvla'])
|
2012-07-19 04:42:34 +00:00
|
|
|
else
|
|
|
|
:
|
|
|
|
AC_SUBST(WARNINGOPTS, [])
|
|
|
|
fi
|
|
|
|
|
2020-02-23 15:29:40 +00:00
|
|
|
AC_SEARCH_LIBS([pow], [m])
|
|
|
|
|
2005-04-25 15:55:06 +00:00
|
|
|
AC_OUTPUT
|
|
|
|
|
2011-07-23 11:36:25 +00:00
|
|
|
if test "$gtk_version_desired" = "no"; then cat <<EOF
|
|
|
|
|
|
|
|
'configure' was instructed not to build using GTK. Therefore, PuTTY
|
|
|
|
itself and the other GUI utilities will not be built by the generated
|
|
|
|
Makefile: only the command-line tools such as puttygen, plink and
|
|
|
|
psftp will be built.
|
|
|
|
|
|
|
|
EOF
|
|
|
|
elif test "$gtk" = "none"; then cat <<EOF
|
Switch to using automake for the Unix autoconfigured build.
mkfiles.pl no longer generates a Makefile.in, but instead generates a
Makefile.am on which mkauto.sh runs automake. This means that the
autoconfigured makefile now does build-time dependency tracking (a
standard feature of automake-generated makefiles), and is generally
more like what Unix people will expect.
Some of the old-style make command-line settings (VER=-DRELEASE=foo,
XFLAGS=-DDEBUG) will still work; the COMPAT settings are better done
by autoconfiguration, and my habitual 'XFLAGS="-g -O0"' for an easily
debuggable build will actually not work any more because CFLAGS is
specified _after_ XFLAGS, so I should instead write 'make CFLAGS=-O0'
(-g is the default in automake, removed at 'make install' time).
The new makefile will automatically degrade into one that builds the
command-line tools only, in the case where GTK could not be found. In
principle, therefore, it should be an adequate replacement for _both_
the static Unix makefiles, Makefile.gtk and Makefile.ux. I haven't
actually retired those in this commit, but I'm pretty tempted.
[originally from svn r9239]
2011-07-23 11:33:29 +00:00
|
|
|
|
2015-08-16 13:53:15 +00:00
|
|
|
'configure' was unable to find any version of the GTK libraries on
|
Switch to using automake for the Unix autoconfigured build.
mkfiles.pl no longer generates a Makefile.in, but instead generates a
Makefile.am on which mkauto.sh runs automake. This means that the
autoconfigured makefile now does build-time dependency tracking (a
standard feature of automake-generated makefiles), and is generally
more like what Unix people will expect.
Some of the old-style make command-line settings (VER=-DRELEASE=foo,
XFLAGS=-DDEBUG) will still work; the COMPAT settings are better done
by autoconfiguration, and my habitual 'XFLAGS="-g -O0"' for an easily
debuggable build will actually not work any more because CFLAGS is
specified _after_ XFLAGS, so I should instead write 'make CFLAGS=-O0'
(-g is the default in automake, removed at 'make install' time).
The new makefile will automatically degrade into one that builds the
command-line tools only, in the case where GTK could not be found. In
principle, therefore, it should be an adequate replacement for _both_
the static Unix makefiles, Makefile.gtk and Makefile.ux. I haven't
actually retired those in this commit, but I'm pretty tempted.
[originally from svn r9239]
2011-07-23 11:33:29 +00:00
|
|
|
your system. Therefore, PuTTY itself and the other GUI utilities will
|
|
|
|
not be built by the generated Makefile: only the command-line tools
|
|
|
|
such as puttygen, plink and psftp will be built.
|
|
|
|
|
|
|
|
EOF
|
|
|
|
fi
|
|
|
|
|
2005-04-25 15:55:06 +00:00
|
|
|
AH_BOTTOM([
|
|
|
|
/* Convert autoconf definitions to ones that PuTTY wants. */
|
|
|
|
|
|
|
|
#ifndef HAVE_GETADDRINFO
|
|
|
|
# define NO_IPV6
|
|
|
|
#endif
|
|
|
|
#ifndef HAVE_SETRESUID
|
|
|
|
# define HAVE_NO_SETRESUID
|
|
|
|
#endif
|
|
|
|
#ifndef HAVE_STRSIGNAL
|
|
|
|
# define HAVE_NO_STRSIGNAL
|
|
|
|
#endif
|
2005-09-14 11:00:34 +00:00
|
|
|
#if !defined(HAVE_UTMPX_H) || !defined(HAVE_UPDWTMPX)
|
2005-04-25 15:55:06 +00:00
|
|
|
# define OMIT_UTMP
|
|
|
|
#endif
|
|
|
|
#ifndef HAVE_PTSNAME
|
|
|
|
# define BSD_PTYS
|
|
|
|
#endif
|
2005-09-14 10:53:39 +00:00
|
|
|
#ifndef HAVE_SYS_SELECT_H
|
|
|
|
# define HAVE_NO_SYS_SELECT_H
|
|
|
|
#endif
|
2008-04-02 17:32:17 +00:00
|
|
|
#ifndef HAVE_PANGO_FONT_FAMILY_IS_MONOSPACE
|
|
|
|
# define PANGO_PRE_1POINT4
|
|
|
|
#endif
|
|
|
|
#ifndef HAVE_PANGO_FONT_MAP_LIST_FAMILIES
|
|
|
|
# define PANGO_PRE_1POINT6
|
|
|
|
#endif
|
2010-05-19 18:22:17 +00:00
|
|
|
#if !defined(WITH_GSSAPI)
|
2008-11-22 22:49:27 +00:00
|
|
|
# define NO_GSSAPI
|
|
|
|
#endif
|
2010-05-19 18:22:17 +00:00
|
|
|
#if !defined(NO_GSSAPI) && defined(NO_LIBDL)
|
|
|
|
# if !defined(HAVE_GSSAPI_GSSAPI_H) || defined(NO_GSSAPI_LIB)
|
|
|
|
# define NO_GSSAPI
|
|
|
|
# endif
|
|
|
|
#endif
|
2005-04-25 15:55:06 +00:00
|
|
|
])
|