macos-setup: build snappy as a shared library.

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.

tools/macos-setup.sh

@@ -1360,7 +1360,14 @@ install_snappy() {
         cd snappy-$SNAPPY_VERSION
         mkdir build_dir
         cd build_dir
-        MACOSX_DEPLOYMENT_TARGET=$min_osx_target SDKROOT="$SDKPATH" cmake ../ || exit 1
+        #
+        # Build a shared library, because we'll be linking libwireshark,
+        # which is a C library, with libsnappy, and libsnappy is a C++
+        # library and requires the C++ run time; the shared library
+        # will carry that dependency with it, so linking with it should
+        # Just Work.
+        #
+        MACOSX_DEPLOYMENT_TARGET=$min_osx_target SDKROOT="$SDKPATH" cmake -DBUILD_SHARED_LIBS=YES ../ || exit 1
         make $MAKE_BUILD_OPTS || exit 1
         $DO_MAKE_INSTALL || exit 1
         cd ../..