[m-rev.] for review: drop support for versions of macOS prior to 10.9
Julien Fischer
jfischer at opturion.com
Sun Oct 25 22:52:09 AEDT 2020
Sorry, actual diff for this one is below -- the original one was
an earlier version.
Julien.
On Sun, 25 Oct 2020, Julien Fischer wrote:
>
> 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.
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..8f94c30 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.
%
@@ -508,7 +492,6 @@ gather_c_compiler_flags(Globals, PIC, AllCFlags) :-
TypeLayoutOpt,
InlineAllocOpt,
AnsiOpt, " ",
- AppleGCCRegWorkaroundOpt,
C_FnAlignOpt,
WarningOpt, " ",
CFLAGS, " ",
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