[m-rev.] for review: drop support for versions of macOS prior to 10.9

Julien Fischer jfischer at opturion.com
Sun Oct 25 22:44:47 AEDT 2020


For review by anyone.

---------------------

Drop support for versions of macOS prior to 10.9.

This means that the following are no longer supported:

     - the powerpc*apple*darwin* configuration.
     - versions of XCode prior to about 6 or so

NEWS:
     Announce the above.

README.MacOS:
     Delete text describing things that are no longer supported.

configure.ac:
     Do not check if gcc is really llvm-gcc.  llvm-gcc was replaced
     by clang years ago.

compiler/compile_target_code.m:
scripts/mgnuc.in:
     Delete a workaround for an issue on powerpc based Macs.

Julien.

diff --git a/NEWS b/NEWS
index a547f76..617226e 100644
--- a/NEWS
+++ b/NEWS
@@ -11,6 +11,11 @@ Changes that may break compatibility

  * We have removed the legacy support for the Alpha architecture.

+* We have dropped support for all versions of macOS prior to 10.9.
+
+  A consequence of this is that the `powerpc*apple*darwin*` configuration
+  is no longer supported.
+
  Changes to the Mercury standard library
  ---------------------------------------

diff --git a/README.MacOS b/README.MacOS
index a1afa8f..f577164 100644
--- a/README.MacOS
+++ b/README.MacOS
@@ -4,25 +4,21 @@ Mercury on macOS
  This file documents the port of Mercury to Mac OS X / OS X / macOS,
  i.e. the `*-apple-darwin*` configuration.

+Versions of Mac OS X prior to 10.9 are not supported.
+
  Contents
  --------

  * Mercury on Intel Macs
  * Note for users of Xcode 11
-* Note for users of Xcode 5
-* Note for users of Xcode 4
-* Mercury on Mac OS X 10.4 and 10.3
-* Mercury on older versions of Mac OS X
  * Deployment Target Settings
-* PowerPC Linking Problems
-* Known bugs and unsupported features
  * Deep profiling on Mac OS X

  Mercury on Intel Macs
  ----------------------

  Mercury should build and install "out-of-the-box" on Intel Macs using Mac OS X
-10.5 onwards.
+10.9 onwards.

  The `asm_fast*` and `reg*` grades are only available on 64-bit Intel systems
  and only when using GCC version 4.3 or later as the C compiler.
@@ -37,11 +33,10 @@ If the `asm_fast.gc` grade is not available, and unless otherwise directed,
  then the `hlc.gc` grade will be used as the default grade for compiling
  applications.

-On x86-64 machines running Mac OS X 10.6 or later, the default is to install
-64-bit versions of the executables and libraries in the Mercury system.
-On machines running versions of MacOS up to and including 10.14, users can
-choose to install 32-bit versions instead by invoking Mercury's `configure`
-script either with the option
+On x86-64 machines, the default is to install 64-bit versions of the
+executables and libraries in the Mercury system.  On machines running versions
+of MacOS up to and including 10.14, users can choose to install 32-bit versions
+instead by invoking Mercury's `configure` script either with the option

      --with-cc="clang -m32"

@@ -54,12 +49,6 @@ of the selected C compiler on Mercury-generated C files will specify
  the `-m32` option. The reason for the limitation to 10.14 is that
  32-bit executables are not supported at all from MacOS 10.15 onwards.

-By default, 32-bit versions of the executables and libraries are installed on
-x86-64 machines running Mac OS X 10.5.  To build and install 64-bit Mercury on
-such a system, you must pass the `-m64` option to the C compiler.
-
-Mercury cannot be compiled with `llvm-gcc` on Mac OS X.
-
  If, after installing Mercury, you encounter errors about missing `.mih` files,
  and you have fink installed, then try removing the fink components from your
  `PATH` (these usually start with `/sw`) and reinstalling.
@@ -77,82 +66,6 @@ The github post
  <https://github.com/Mercury-Language/mercury/issues/88#issuecomment-624329679>
  describes a way that has been found to fix the problem.

-Note for users of Xcode 5
--------------------------
-
-With Xcode 5.* the executable named `gcc` is actually just a synonym
-for `clang`. Mercury's `configure` script is aware of this, and it should not
-cause any problems.  If you wish to use actual GCC instead of `clang`,
-you will need to install GCC (see the following section for further
-information).
-
-Note for users of Xcode 4
--------------------------
-
-The default C compiler provided with Xcode 4.* is `llvm-gcc`.
-Mercury does NOT work with `llvm-gcc`.  Note that with Xcode 4.* the executable
-named `gcc` is actually a symbolic link for `llvm-gcc`.
-
-In order to build Mercury you will need to use a C compiler other than
-`llvm-gcc`, for example `clang` (See README.clang for further details)
-or actual GCC.  From version 4.2, Xcode no longer includes actual GCC,
-so if you wish to use that you will need to install it yourself.
-Mac OS X packages for GCC are provided by:
-
-   * The MacPorts project <http://www.macports.org/>
-   * Homebrew             <http://brew.sh>
-   * The Fink project     <http://www.finkproject.org>
-
-As `llvm-gcc` is no longer supported as of version 3.0 of LLVM, we have no
-intention of ever supporting Mercury with it.
-
-Mercury on Mac OS X 10.3 and 10.4
----------------------------------
-
-Mercury should work on Mac OS X 10.3 (PowerPC) and 10.4 (both PowerPC and
-Intel), although it has not been tested with either for a very long time.
-
-Apple GCC 2.95 does not work with Mercury because it cannot handle the length
-of some of the identifier names that the Mercury compiler generates.
-
-Apple GCC 3.3 works with Mercury and there are no known issues (other than the
-problem with gcc's powerpc backend described below).  We recommend that users
-of Mac OS X 10.3 and 10.4 use this version.
-
-Apple GCC 4.0 does not work with Mercury.  Users of Mac OS X 10.4 should note
-that this version of GCC is the default one on their systems.
-
-On Mac OS X 10.3 and 10.4, if you are using an Apple build of GCC, then
-you must use the `gcc_select` command to set the system's default `gcc`
-to that version of `gcc`. It is not sufficient to just point Mercury
-to a version of GCC using the `configure` script's `--with-cc` option.
-This restriction applies only to the builds of GCC supplied by Apple.
-
-Mainline GCC 3.3.X and 3.4.X are known to work with Mercury on Mac OS X 10.3.
-Mainline GCC 4.0.X does not.
-
-Mercury on older versions of Mac OS X
--------------------------------------
-
-There may be problems with building Mercury on versions of Mac OS X prior to
-10.3.  In particular, building shared libraries with Mercury on these systems
-is not supported.
-
-The version of `tar` in `/usr/bin/tar` on some older versions of Mac OS X (e.g.
-10.1) doesn't work properly -- it truncates long path names.  Make sure you
-use GNU tar, which is available in `/sw/bin/gtar`, when unpacking the Mercury
-source or binary distributions.  (Also, make sure to use GNU tar if/when
-*building* such distributions!) The version of `tar` that comes with Mac OS X
-10.3.3 does not have this problem.
-
-Also, Apple's version of GCC includes support for precompiled headers.
-Unfortunately this support seems to be somewhat buggy, causing it to sometimes
-crash with mysterious errors when building Mercury.  Furthermore, for the
-kinds of C code that the Mercury compiler generates, it results in a very big
-slow-down, rather than any speedup.  Fortunately this can be disabled by using
-the `--traditional-cpp` option.  The Mercury `configure` script should enable
-this option automatically if it is needed.
-
  Deployment Target Settings
  --------------------------

@@ -167,72 +80,11 @@ the `configure` script's `--with-macosx-deployment-target` option.
  (See the "SDK Compatibility Guide" in the Apple developer documentation
  for further information about the deployment target setting.)

-PowerPC Linking Problems
-------------------------
-
-On PowerPC machines, the linker may have problems linking large executables
-(particularly in debug grades; technically when the program requires a branch
-larger than +/- 32 MB). It complains about relocation displacements being too
-large. The only known workaround for this problem is to replace the
-system-provided versions of `crt1.o` (Darwin module `Csu`) and `crt2.o`
-(part of gcc) with versions that are compiled with the gcc options
-`-mlongcall` and (if using gcc < ~ 3.4) `-mlong-branch`. C code generated
-by the Mercury compiler will also need to be compiled with the above options.
-This can be achieved by adding:
-
-    EXTRA_CFLAGS=-mlongcall -mlong-branch
-
-to your `Mercury.options` or `Mmakefile`.
-
-Known bugs and unsupported features
------------------------------------
-
-The `asm_fast` grades will not work on `powerc-apple-darwin*` machines,
-primarily because of a (long-standing) bug in gcc (GCC bug #10901).
-By default, the `configure` script will choose either `reg` or `none`
-as the default base grade.  If you do not intend to use debugging
-(e.g. with production code), then you will probably get better performance
-by using the `hlc.gc` grade.
-
-Executables created by the Mercury compiler cannot be statically linked against
-the system libraries on Mac OS X.  Setting `MLFLAGS=-static` or invoking `mmc`
-with the `--linkage static` option will result in an error message
-from the linker such as the following:
- 
-    ld: can't locate file for: -lcrt0.o
- 
-The reason that this does not work is that static version of the system
-libraries are not installed on OS X systems by default.  (See Technical Q&A
-QA118 <http://developer.apple.com/qa/qa2001/qa1118.html> for further details.)
-
-This restriction only applies to system libraries.  Statically linking against
-Mercury libraries is fine.
-
  Deep profiling on Mac OS X
  --------------------------

-The Mercury deep profiler requires a local web server.
-Standard installations of versions of Mac OS X prior to 10.8 should
-include Apache as the default web server. The deep profiler requires
-the deep profiling CGI script, `mdprof_cgi`, to be installed in the
-directory `/Library/WebServer/CGI-Executables`.  Mercury's normal installation
-process should take care of this if deep profiling is enabled.
-
-To use the deep profiler, the web server must not only to be installed,
-it must also be running. To ensure the webserver is running:
-
-- Open the `Apple Menu` and open the `System Preferences` window.
-- In the `System Preferences` window, click on the icon labelled `Sharing`.
-- Make sure that `Personal Web Sharing` is enabled.  If it is, then
-  the web server should be running.
-
-The remaining instructions for using the deep profiler are the same as those
-found in the "Mercury User's Guide".  We recommend against using Safari 1.5
-as it has been found to be somewhat unstable with the deep profiler.
-Later versions of Safari are fine. 
-
-Versions of MacOS starting with 10.8 do not include the Apache web server
-by default. On such machines, you will need to
+The Mercury deep profiler requires a local web server.  To use the deep
+profiler:

  - select and install a web server, and
  - install and enable the `mdprof_cgi` script according to the rules of that
diff --git a/compiler/compile_target_code.m b/compiler/compile_target_code.m
index 793516f..eac1391 100644
--- a/compiler/compile_target_code.m
+++ b/compiler/compile_target_code.m
@@ -433,22 +433,6 @@ gather_c_compiler_flags(Globals, PIC, AllCFlags) :-
          WarningOpt = ""
      ),

-    % The -floop-optimize option is incompatible with the global
-    % register code we generate on Darwin PowerPC.
-    % See the hard_coded/ppc_bug test case for an example
-    % program which fails with this optimization.
-
-    globals.lookup_string_option(Globals, target_arch, TargetArch),
-    ( if
-        globals.lookup_bool_option(Globals, highlevel_code, no),
-        GCC_Regs = yes,
-        string.prefix(TargetArch, "powerpc-apple-darwin")
-    then
-        AppleGCCRegWorkaroundOpt = "-fno-loop-optimize "
-    else
-        AppleGCCRegWorkaroundOpt = ""
-    ),
-
      % Last resort workarounds for C compiler bugs.
      % Changes here need to be reflected in scripts/mgnuc.in.
      %
diff --git a/configure.ac b/configure.ac
index 8742648..6456d90 100644
--- a/configure.ac
+++ b/configure.ac
@@ -235,28 +235,6 @@ AC_SUBST(BUILD_C_PROGS_FOR_BUILD_SYSTEM)

  #-----------------------------------------------------------------------------#

-# Check that we are not using llvm-gcc on Mac OS X since it is too broken
-# to successfully compile Mercury.
-
-if test "$MERCURY_HAVE_GCC" = yes
-then
-    case "$host" in
-        *apple*darwin*)
-            if $CC -v 2>&1 | grep -q "gcc.*Apple.*LLVM"
-            then
-                AC_MSG_ERROR(
-[
-**** The executable `$CC' on this system appears to be llvm-gcc.
-**** It contains bugs that means it cannot be used to compile Mercury.
-**** See README.MacOS for further details.])
-            exit 1
-            fi
-            ;;
-    esac
-fi
-
-#-----------------------------------------------------------------------------#
-
  # Versions of Xcode 11 up until 11.4 ship with a broken version of clang.
  # NOTE: what we are checking for below is Apple version for clang, Xcode 11.4
  # has Apple clang version 11.0.3.
diff --git a/scripts/mgnuc.in b/scripts/mgnuc.in
index 02b857c..fb004e2 100755
--- a/scripts/mgnuc.in
+++ b/scripts/mgnuc.in
@@ -638,24 +638,6 @@ case "${FULLARCH}" in x86_64*)
      ;;
  esac

-# The -floop-optimize option is incompatible with the global register code
-# we generated on Darwin PowerPC. See the hard_coded/ppc_bug test case
-# for an example program which fails with this optimization.
-
-case ${FULLARCH} in
-    powerpc*apple*darwin*)
-        case ${highlevel_code} in
-            false)
-                case ${global_regs} in
-                    true)
-                        ARCH_OPTS="${ARCH_OPTS} -fno-loop-optimize"
-                        ;;
-                esac
-                ;;
-        esac
-        ;;
-esac
-
  # At -O2 compilation times on Mac OS X are extremely slow for
  # Apple GCC 4.{0,2}. We must force GCC to use -O0 here in order
  # to get acceptable compilation times.


More information about the reviews mailing list