I've just upgraded my build process to a version of lld-link
that knows how to read .res, and I think it's a slightly more
commonly found format, so less confusing to encounter.
I've been experimenting with using clang-cl with older versions of the
Visual Studio libraries and headers, and found that the older VS
libraries have a quirk which can cause link failure in a way that
doesn't happen with the newer one. I assume the corresponding old VS
linker must be doing some kind of special-case handling that lld isn't
mimicking.
The quirk arises because lld tries to pull in more than one of the
*crt0.obj startup objects which set things up before calling main or
WinMain (or whatever), and those objects define some of the same
symbols as each other. The fix is to explicitly ask for the right one
of those objects on the link command line, so that it's already been
loaded _before_ the linker starts searching libraries for unresolved
symbols; then the disputed symbols are never unresolved in the first
place during the library search phase.
But this means you have to pick your crt0 object differently depending
on which subsystem you're compiling for. Accordingly, here's an extra
feature in Makefile.clangcl to make that possible by means of the
right definitions on the make command line.
Thanks to Brian K. White for spotting this straight-up syntax error of
a missing ), in the regex handling the special case of &splitlines
when it findss a word in its input string too long to fit in the
specified output line width. Apparently in all my own uses of
&splitline I'd never exercised that special-case code path before.
I had accidentally included the experimental "XT" app class (the
GtkApplication-based packaging of Unix PuTTY/pterm for OS X) among the
things that should still be built even when GTK is absent. That's
definitely wrong.
This was very strange to write, because it's a bizarre combination of
the GNU-make-isms and rc commands of Makefile.mgw with the cl and link
commands of Makefile.vc (but also the latter thankfully doesn't need
those horrible response files).
I've added a big comment in mkfiles.pl about what the build
requirements for this makefile actually are, which _hopefully_ will be
usable by people other than me.
In commit be586d53b I made empty.h depend on $(allsources), which
unfortunately was defined so as to include empty.h. This was harmless,
because make just ignored the circular dependency, but annoying,
because it constantly mentioned that it was ignoring it.
By default the VS2015 linker produces binaries with the minimum
version fields in the PE header set to 06.00, which causes XP not to
recognise them as valid binaries at all. But there's no other reason
VS2015-built binaries _can't_ run on versions of Windows as old as XP;
so here I add the link option to set those fields to 05.01 which makes
XP like them again.
This only applies to the 32-bit build, because the VS2015 64-bit
linker refuses to lower the min version field to under 06.00.
Originally added in commit 0014ffb70, and promptly reverted in
6bea4b250 when we realised that VS2003 didn't actually understand
them. But now we're building with VS2015, which does understand them,
it's actually useful to put them back in again.
Looking more closely, it turns out that VS2003 didn't actually _fail
to build_ if you passed these flags on the linker command line - it
just printed a warning and ignored them. (So there was no actual need
to revert the original change, except that it would have caused
confusion.) But that means I can add them unconditionally now, without
breaking even the legacy VS2003 build.
I've reset the baseline to be the version of mingw-w64 that comes with
Ubuntu 14.04. Right now, that means no features need to be omitted; all
you need to do is set TOOLPATH to i686-w64-mingw32- .
I've removed -mno-cygwin without comment. Toolchains which don't support
this flag have been around since at least 2012, so we can probably
assume that no-one cares about older toolchains by now.
It's really only useful with MinGW rather than a Cygwin toolchain these
days, as recent versions of the latter insist against linking with the
Cygwin DLL.
(I think it may no longer be possible to build with Cygwin out of the
box at all these days, but I'm not going to say so without having
actually checked that's the case. Settle for listing MinGW first in
various comments and docs.)
Previously, if you tried to set the special cflags for an object file
to the empty string, mkfiles.pl would normalise that to the string
"1". I'm not entirely sure why - that line of code was added without
explanation in commit 64150a5ef which brought in that directive in the
first place - but I have to guess that it was left over from some
earlier design iteration in which I hadn't quite decided whether I was
going to need a string or a boolean to separate version.o from other
objects.
Of course, setting an object's cflags to "" is a bit of a weird thing
to want to do anyway - why not just leave them unset? But in fact I've
now thought of something useful for it to do: this commit arranges
that setting cflags="" has the effect (in the 'am' makefile type) of
separating the object out into its own little automake library but not
actually giving that library any separate cflags. And the point of
_that_, in turn, will be that then you can add cflags to it
_conditionally_ in a "!begin am" snippet, e.g. conditionalised on
something in configure.
With all due respect to Microsoft, a cross-platform program simply
cannot switch to using MS's assorted 'secure' versions of standard C
functions if it wants to continue compiling on platforms other than
Windows. So I might as well squash the warnings, so that any other
more interesting compiler warnings can avoid being swamped in the
mess.
This is to [X] what [UT] is to [U]: that is, it's a program linked
against the GTK libraries, but one which doesn't become part of the
'make install' set. I'll use this for the individual binaries that
will go in the OS X application bundles, and then have another
makefile rule pick those up in turn.
Now all the uses of the licence text or the short copyright notice get
it from a new header "licence.h", which in turn is built by a Perl
script licence.pl invoked by mkfiles.pl, using LICENCE itself as the
source.
Hence, I can completely remove a whole section from the list of
licence locations in CHECKLST.txt :-)
Occurred as a side effect of commit 198bca233, in which I wrote a Perl
loop of the form 'foreach $srcdir (@srcdirs)' inside which I modified
$srcdir - forgetting the Perl gotcha that if you do that, $srcdir
temporarily aliases the actual array element, so you end up modifying
the array you iterated over. Hence, a set of transformations intended
to convert the source directory list into a special form for the nmake
batch-mode inference rule syntax in particular ended up back in
@srcdirs to be reflected in unrelated makefiles output later in the
run.
Now you can run a command like "nmake /f Makefile.vc BUILDDIR=foo\",
which will cause all the generated files to appear in a subdirectory
of putty\windows. This is immediately useful for testing multiple
build configurations against each other by hand; later on I hope it
will also be a convenient way to run multiple build configurations in
the proper bob build.
This enables it to combine the compilation of multiple source files
into a single 'cl' command with multiple input file arguments, which
speeds up the build noticeably.
(I think nmake could be doing a lot more to improve this - for a
start, I haven't found any way to let it aggregate compilations of
source files in more than one directory, and also, it seems to me that
it really ought to be able to reduce down to just _one_ invocation of
cl by choosing the best topological sort of its build operations,
whereas in fact it looks as if it's sorting the operations _before_
doing the aggregation. But even so, it's a big improvement on the
previous build time.)
This is noticeably faster than a sequence of 'echo' commands, because
the file gets created all in one go. The most natural approach to this
job would also hide the file's contents, but doing it this way with a
'type' command lets me see the file on nmake's standard output, so
that the build log should still contain everything useful for
debugging build problems.
It's for regression testing and fuzzing, so there's no use for it if
you're not a developer working on the source.
Leaving it out of the 'make install' target in Makefile.gtk is no
trouble because that's already handled manually in Recipe by inserting
a giant hairy Makefile fragment to do the installation. But
Makefile.am was just setting bin_PROGRAMS to the full set of binaries
built, so for that one, I had to invent a new Recipe program category
[UT] which moves a particular binary into noinst_PROGRAMS.
While I was at it, I've retired the [M] program category, which has
been lying around unused since Ben's old Mac OS pre-X port.
mkfiles.pl was giving a couple of annoying perl warnings, because some
makefile_extra strings were never set by Recipe. We already have the
&def function to convert undefs into "" for this reason, but weren't
using it everywhere. Now I think we are.
I've shifted away from using the SVN revision number as a monotonic
version identifier (replacing it in the Windows version resource with
a count of days since an arbitrary epoch), and I've removed all uses
of SVN keyword expansion (replacing them with version information
written out by Buildscr).
While I'm at it, I've done a major rewrite of the affected code which
centralises all the computation of the assorted version numbers and
strings into Buildscr, so that they're all more or less alongside each
other rather than scattered across multiple source files.
I've also retired the MD5-based manifest file system. A long time ago,
it seemed like a good idea to arrange that binaries of PuTTY would
automatically cease to identify themselves as a particular upstream
version number if any changes were made to the source code, so that if
someone made a local tweak and distributed the result then I wouldn't
get blamed for the results. Since then I've decided the whole idea is
more trouble than it's worth, so now distribution tarballs will have
version information baked in and people can just cope with that.
[originally from svn r10262]
This rearranges the object files so that they each live alongside
their original source file, instead of all being in the same
directory. To my way of thinking this is a more or less neutral change
(perhaps marginally less tidy), but autotools is apparently beginning
to think it's the One True Way and 1.14 will give a warning if you
don't have it enabled.
[originally from svn r10142]
Previously, 'configure' and its assorted machinery lived in the 'unix'
subdir, because that seemed like a clean place to keep it given that
all the other per-platform Makefiles live in their platform
directories. However, this never sat all that happily with autotools,
and even less so now that it likes to have object file pathnames
parallel source file pathnames: if you have Makefile.am refer to
source files outside its subdir as "../terminal.c" and enable
subdir-objects then any out-of-tree build calls the corresponding
object file "../terminal.o" and so your build products mostly end up
at the directory above your build dir! And as of autotools 1.14 my
previous compensatory bodge of prefixing every source file path in
Makefile.am with "$(srcdir)" has stopped working too.
So I'm giving in to necessity, and changing policy by moving the
configure machinery up to the top level of the source tree where
autotools will be less confused by it. This should not be taken as any
indication of the primacy of the Unix port, only of the recalcitrance
of autotools.
Whereas before we had a trivial script called 'configure' at the top
level that invoked unix/configure to effectively do an 'out-of-tree
build' (for make purposes) at the top level of the source tree, we now
have a similar script in unix/configure. So this _should_ make very
little difference: people who were previously running configure from
the top level should still be able to, and likewise people who were
running it from the unix subdir.
[originally from svn r10141]
Thanks to Mike Edenfield for the initial version of this patch; I've
polished it up a bit (in particular inventing a more overengineered
GUID generation strategy) but most of it is his.
[originally from svn r10112]
handle. Revert that when we hackily call it from mkfiles.pl, so that
if I have a need to insert diagnostics in the latter they won't go
into the end of sbcsdat.c.
[originally from svn r10013]
and into AM_CPPFLAGS. This is more conceptually sensible according to
my reading of the automake manual, and also has the specific desirable
effect that they move to the front of the command line, ahead of any
'system' type -I options that autoconf might have felt a need for.
A user reported that autoconf had added -I/usr/local/include to their
command line for the sake of a required header file, but their
/usr/local/include also turned out to include a thing called 'proxy.h'
(from libproxy, nothing to do with us) which shadowed our own proxy.h
and caused a build failure. This should fix that.
[originally from svn r9736]
having just noticed that Makefile.gtk had it and this one doesn't. (Of
course, this being autoconf, we can easily enough make it conditional
on the compiler actually being gcc.)
[originally from svn r9583]
makefile) as a side effect of running mkfiles.pl.
The automake docs observe that the BUILT_SOURCES list is only
automatically built by plain 'make' or 'make all' or a couple of other
targets, so the sequence './configure && make plink' from a freshly
unpacked tar file would previously fail for lack of empty.h.
If empty.h had important _content_ that needed to be built at compile
time, of course, I wouldn't be able to fix it like this; but since the
only important thing is the timestamp, I can just make sure it already
exists at the time of first build.
[originally from svn r9288]
runs configure at the top level rather than the unix subdirectory. I'm
getting into the idea of even doing it that way myself, because then I
can do VPATH builds from the same source tree elsewhere.
(Autoconf seems to be fine with doing multiple VPATH builds from the
same source tree in different build directories, but gets upset if you
try to do a VPATH build when you've done a normal build in the real
configure directory. So this way I do what autoconf sees as _only_
VPATH builds.)
[originally from svn r9269]
'mkfiles.pl -u', it will do its normal processing, then run mkauto.sh
to regenerate configure and Makefile.in, then run configure in the
Unix subdirectory to regenerate unix/Makefile. So it's a handy
one-stop shop for going all the way from a modified Recipe to the
end-product Unix makefile, if you're adding source files during
development.
[originally from svn r9242]
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]
supplied extra link flags. This makes it reasonably convenient to
compile for Visual Studio debugging: just build using
nmake /f Makefile.vc XFLAGS="/Zi /Od" XLFLAGS="/debug"
then load the resulting executable into Visual Studio (using 'Open
Project' rather than 'Open File') and the debugger should be able to
access the source.
[originally from svn r9038]
reorganises the GSSAPI support so that it handles alternative
implementations of the GSS-API. In particular, this means PuTTY can
now talk to MIT Kerberos for Windows instead of being limited to
SSPI. I don't know for sure whether further tweaking will be needed
(to the UI, most likely, or to automatic selection of credentials),
but testing reports suggest it's now at least worth committing to
trunk to get it more widely tested.
[originally from svn r8952]
PuTTY makes explicit use of libX11 without including -lX11 on the
link line. (GNU ld appears to pull in libX11 automatically because
it's needed for the dependencies of GTK, but gold expects that
dependency to be satisfied at run time via DT_NEEDED and hence
doesn't bother.) Hence, add explicit -lX11 to both Makefile.gtk and
the autoconf world.
[originally from svn r8876]
trouble on Ubuntu, where the Gtk test programs don't check the return value
from system() and thus fall foul of the combination of our -Werror and
<https://wiki.ubuntu.com/CompilerFlags#-D_FORTIFY_SOURCE=2>.
[originally from svn r8638]
