macos-setup.sh:
- Fix filename of libtiff in existence test from "libtiff" to "tiff"
- Added fallback URL for libtiff when the downloaded file is not a valid gzip
archive. The host rotates older versions of libtiff into an "old"
subdirectory, so curl downloads a 404 Web page and exits without error. Then
the call to gzcat fails with an invalid gzip archive error. Maybe libtiff
version should be updated instead?
At least on Monterey, with Xcode 13.1, the linker whines that we weren't
granted the Sacred and Holy Right to link with the Python 2.7 framework.
As far as I know, we have no need to use that framework, so configure it
out.
We add them when configuring with autotools, so that we build GLib
appropriately for the OS versions we're targeting; do the same when
configuring with Meson.
If this version of macOS comes with a version of libffi, generate a .pc
file for it and install it in /usr/local/lib/pkgconfig, so that
pkg-config finds that version of libffi, and the GLib configuration
process - whether it's done with autotools or Meson - doesn't decide
that there is no libffi and fail or install its own libffi or whatever.
If we're running an external Python 3 package, pip3 will install scripts
in some directory under /Library; set MESON to point to the location
where Meson will be installed, and use that.
Have a meson-done file to indicate that Meson's been installed by us,
and uninstall it only if that's present.
We want to check whether *Apple* provides Python 3, not whether there's
a Python 3 installed; if there is no Apple-provided Python 3, but
there's somebody else's Python 3 installed, leave it alone, don't
uninstall it.
Newer versions of GLib require Meson (they don't support autotools) and
Ninja (they use Ninja rather than Make). Install Meson and, based on
the GLib version, use autotools+make or Meson+Ninja to build GLib.
Move up the installation of Python 3 so that it's available when we
install Meson, as Meson requires Python 3 and is installed with pip3.
Only install an external Python 3 if /usr/bin/python3 doesn't work; on
at least some versions of macOS, /usr/bin/python3 is a wrapper to run
Python 3 from Xcode, and at least some versions of Xcode provide Python
3.
1.10.2 is the latest version, and is the first version to ship as a fat
x86-64/ARM64 binary, so that we have native binaries for both platforms
supported by macOS.
Update CMake (3.19.7), Qt (5.2.10), and Python (3.9.3) to later bugfix
versions of the current packages. CMake and Python have made tweaks in
the names of the binary packages that support different macOS versions.
Fixes downloading Python 3.9.2+ on macOS 11 after the package suffix
changed from -macos11.0.pkg to -macos11.pkg
Warn about the lack of Qt offline installers for version 5.15 and
greater.
The minimum required version of Qt is now 5.6, and thus the minimum
required version of macOS is 10.8. Reflect that in macos-setup, and
remove version checks and older packages installed to support
Snow Leopard and Lion.
Allow QT version 5.14.x to be installed (if specified as a variable
on the command line.) Remove the ability to install 5.2.x, as QT 5.3
has been the minimum required version since the Wireshark 3.4 branch.
Note that QT no longer providers offline installers for the free releases
of 5.15 and later, so we'll have to come up with a different method.
(See http://download.qt.io/archive/qt/5.15/5.15.0/OFFLINE_README.txt
and https://www.qt.io/blog/qt-offering-changes-2020 )
Python 3.9.1 is the first version of Python to support Big Sur and
Apple Silicon (https://www.python.org/downloads/release/python-391/),
and Python 3.7.6 is the last version with a 64-bit/32-bit binary installer
for macOS X 10.6 (Snow Leopard) to 10.8 (Mountain Lion) provided.
Apple Silicon requires CMake 3.19.2, but the binaries provided
for 3.19.2 only run on MacOS 10.10 and later, so we have more
bifurcation of the CMake we try to install. Get rid of some of
the old 2.x paths to compensate.
It's minizip-$installed_minizip_version-done, not
zlib-$installed_minizip_version-done; the tarball is
zlib-$installed_minizip_version.tar.gz, because it's a contributed file
in the zlib package, but we don't use zlib in the name of the -done
file.
[skip ci]
It has no configure script, so there's no need for "make distclean", and
the Makefile supplied with it has no "make distclean" rule; just do
"make clean".
[skip ci]
In uninstall_autoconf, when running uninstall subfunctions, pass the
arguments to the subfunctions.
When uninstalling Ninja, remove the "we've finished installing this"
indicator file.
Get rid of a debugging "set +x".
Fix/update/expand some comments.
Do uninstalls for dependencies using CMake more similarly.
For LZ4, as it comes with a Makefile rather than any
autotools/CMake/etc. configuration, "make distclean" might not be
necessary, so, as it's not supported, just do "make clean".
For libssh, do all removes in the uninstall in a single command, and use
$DO_RM, so that it uses sudo iff /usr/local isn't writable by us. In
addition, remove the build directory as the equivalent of "make
distclean".
As with libssh, so with brotli.
For a CMake build done in a subdirectory of the source directory, the
equivalent of "make distclean" is "rm -rf {that subdirectory}". Make it
so.
When uninstalling the stuff snappy installs with "rm -rf", use $DO_RM,
so it's done with sudo iff /usr/local isn't writable by us, just as
"make uninstall" is done with $DO_MAKE_UNINSTALL so it's done with sudo
iff /usr/local isn't writable by us.
Fix up the list of what to remove, now that we're building snappy as a
shared library, so that it removes shared libraries rather than the
non-existent static library.
Update a comment while we're at it, as Lua isn't the only dependency
that doesn't support "make uninstall".
The older versions of snappy apparently used autotools and build a
shared library by default; for example, Wireshark 3.2.6 for macOS is
built with snappy, and includes a snappy dynamic library in the app
bundle.
The current version uses CMake and does *not* build a shared library by
default. Instead, it builds a static library, which, when you try to
link it to a C-only shared library...
...does not work.
The linker sees that you're statically linking in a bunch of C++ .o
files and gets upset because it can't find C++ standard library routines
used by that code.
If it's a dynamic library, the library was itself already linked with
the C++ standard library, so the external references to that library
from the snappy library are already marked as having been resolved to
the extent that they're expected to be in the C++ standard library at
run time - and, when the dynamic snappy library is built, it's marked as
depending on the C++ standard library, so the run time linker will, when
it loads the snappy dynamic library, see that the C++ standard library
is required and will load it if it hasn't already been loaded.
ardnew