README.MacOS:
Mention the bug in Xcode 11 prior to Xcode 11.4, and provide pointers
to both the problem and its solution.
configure.ac:
When run on MacOS, print a warning and point to README.MacOS.
browser/interactive_query.m:
Use '.dylib' as the extension for the shared library we generate for
interactive queries when on OS X. (While '.so' would work in principle,
its use is unusual on OS X and the Mercury compiler will always use
'.dylib' anyway.)
Replace some sequences of I/O operations with single calls to io.format
so that message components are not spread over multiple lines.
Add an XXX comment about object file extensions.
Update comments that refer to 'libquery' rather than 'libmdb_query'.
README.MacOS:
Delete interactive queries from the list of unsupported features.
tests/debugger/interactive.exp:
Update this expected output. The changes are due to earlier
changes to the formatting and presentation of error messages.
README.Linux:
README.MacOS:
README.MinGW-cross:
compiler/options.m:
Remove or comment out references to the `--cross-compiling'
option which has no effect now.
configure.ac:
Do not set the LLDS base grade to 'none' if we are on 64-bit OS X and
we are using GCC 4.3 onwards. (Older versions of GCC are either
broken or do not work on this platform anyway.)
README.MacOS:
Mention that the asm_fast* and reg* grades do work on x86_64
systems.
NEWS:
Announce that the asm_fast* and reg* grades are now supported
on x86_64 OS X machines.
Update README.MacOS to cover version 10.9 (Xcode 5).
README.MacOS:
Add a contents section to the top of this file.
Merge the sections covering Mac OS X 10.5 - 10.8 into one section that
also covers 10.9.
The source distribution will no longer be built in the none.gc grade.
Add separate sections discussing Xcode 4 and Xcode 5 specific issues.
Mention that Homebrew and Fink are also a source of GCC packages for
Mac OS X (in addition to MacPorts).
Mac OS 10.3 was only supported on PowerPC machines, not as we seem
to suggest here also Intel machines.
Due to matching against hardcoded versions of Darwin in the configure script
the deployment target for recent versions (10.7 and later) of Mac OS X was being
incorrectly set to 10.3. This diff makes several changes to the handling of the
deployment target setting on Mac OS X:
- The default deployment target is now set to the same version as the host
system. (This is more consistent with the default XCode behaviour.)
- Matching against hardcoded versions of Darwin in the configure script
for this purpose has been removed.
- There is a new option for the configure script,
`--with-macosx-deployment-target', that allows the user to control
what the deployment target for use with Mercury is.
configure.ac:
Don't determine the deployment target by matching against hardcoded
versions of Darwin -- we had failed to update this for several
versions.
By default set the deployment target to be the same version as
the host system.
Add a new option for overriding the default setting of the
deployment target.
s/doesn't/does not/ in a spot in order to prevent syntax
highlighting in vim from going stupid.
README.MacOS:
Add a paragraph describing how the deployment target is set
for Mercury and pointing the user towards Apple's documentation
if they require further information.
NEWS:
Announce the change to the default value of the deployment
target setting.
.README.in:
The contents of java/runtime come under the LGPL as well.
Minor rewording.
README.MS-Windows:
We don't need to list every version of Windows we no longer
actively support. (If the version is not on the list of those
we *do* support, then we don't support it.)
README.MacOS:
We will never support compiling Mercury with llvm-gcc on
Mac OS X 10.5 and 10.6.
Branche: main, 11.07
Update some documentation
README.Erlang:
Mention the minimum required version of Erlang/OTP.
README.MacOS:
Mention that with XCode 4 gcc is actually a symlink for llvm-gcc.
Branches: main, 11.07
Documentation updates.
NEWS:
Announce that we are compatible with Java 1.7.
README.MacOS:
llvm-gcc is no longer supported in LLVM.
Branches: main, 11.07
Fix an XXX related to clang and shared libraries on Mac OS X.
configure.in:
Use clang not gcc on Mac OS X for building shared libraries when using
clang as a C compiler.
Delete support for using flat namespaces with dylibs. This was
only necessary for creating dylibs that would work on Mac OS X 10.2
and before; now it's no longer worth maintaining the code in the
configure script that allowed it.
README.MacOS:
Conform to the above change.
Branches: main, 11.07
Support using clang as a C compiler with Mercury -- currently only
tested on Mac OS X.
Clean up the handling of C compilers in the configure script.
configure.in:
Improve this script's ability to distinguish between different
types of C compiler. In particular, ensure that a clear
distinction is maintained between clang and gcc.
Fix an old XXX: don't rely on pattern matching on the value
of $CC to determine the C compiler type. This is particularly
error prone now since one compiler is named "clang" and another
"cl".
Set optimization and warning flags for clang.
(XXX this is currently very conservative; we need to go through
them and work out what good defaults might be.)
Don't link against libgcc if we are using clang.
(XXX I don't think this is really necessary for gcc either in
the great majority of cases.)
Mark spots that still need updating with "XXX CLANG"; I will
look into these separately.
aclocal.m4:
Add a new macro that determines the C compiler type based
on what builtin macros are defined -- unlike AC_PROG_CC
this macro correctly distinguishes between gcc and clang.
Add two new macros that determine version information for
clang and for Visual C.
scripts/mgnuc.in:
scripts/ml.in:
Handle clang
README.MacOS:
Mention that clang can be used with Mercury on Mac OS X.
Branches: main, 11.01
README.MacOS:
Reword the section on which grades are available on Mac OS
10.5 and 10.6.
Mention that hlc.gc will be used as the default grade for
building applications.
README.MacOS:
Suggest removing fink from the PATH if, after installing Mercury, the
user gets errors about missing .mih files.
I had this problem and removing fink from my PATH fixed it (though I
don't know why).
Branches: main, 10.04
README.MacOS:
Add a note about a problem that can arise when bootstrapping a 64-bit
Mercury compiler using a 32-bit one and vice versa.
Branches: 10.04, main
Update README.MacOS.
README.MacOS:
Split the documentation for the OS X port into three sections,
one for 10.5 and 10.6, one for 10.3 and 10.4, and a final one
for anything older than that.
Describe how to build a 32-bit Mercury installation on 10.6.
(And a 64-bit one on 10.5)
Mention that the Java and Erlang grades work on 10.{5,6}.
Mention that llvm-gcc and clang currently don't work with Mercury.
(IIRC, one can't compile the Boehm GC and the other trips up with
something involving static data -- similar problems seem to occur
on Linux with those compilers as well.)
According to the GCC bug database, bug #10901 also affects gcc on i686.
(This bug was the reason asm_fast did not work powerpc-*-darwin*.)
Update our description of this problem.
Mention that the --linkage static option doesn't work on Mac OS X,
in addition to mentioning that MLFLAGS=-static doesn't work.
Mention that versions of Safari greater than 1.5 are fine with
the deep profiler, rather than Safari 2 specifically.
Mmake.common.in:
Add ENABLE_BOEHM_XOPEN_SOURCE.
README.MacOS:
Document that Mercury works on Mac OS X 10.5 and 10.6.
Also document that it hasn't been tested on 10.3 for
some time.
configure.in:
Pass -m32 to gcc on Darwin 9 and 10, because our current version of boehm
doesn't work on 64 bit Darwin.
Define _XOPEN_SOURCE on Darwin 10 when compiling boehm to
avoid errors about the functions in ucontext.h being deprecated.
Don't pass -s to the linker on Darwin 9 and 10.
boehm_gc/Makefile:
Include BOEHM_CFLAGS (generated by the Mercury configure script)
in SPECIALCFLAGS which is used when compiling mach_dep.c so that
_XOPEN_SOURCE is defined in mach_dep.c.
trace/mercury_event_scanner.l:
Remove declaration of mercury_event_get_leng, because flex generates a
different return value type depending on the platform (on Mac OS X 10.6 it
returns yy_size_t while on Linux it returns int).
Estimated hours taken: 2 + many (20ish) looking at GCC, Darwin, PPC, etc.
Branches: main
README.MacOS:
Added documentation of a workaround for problems linking large
executables on PPC Darwin; read it for more info.
Estimated hours taken: 1
Branches: main, release
README.MacOS:
Update this file as we now have a lot more experience using Mercury
on this platform.
Mention which versions of gcc are known to be comptabile with Mercury
(and also some that aren't).
Mention the problem with Apple's linker and linking large executables,
like the compiler in debug grades.
Explain why statically linking against system libraries won't work.
Add section on the Mac OS X specific parts necessary for setting up
the deep profiler. Also mention that Safari 1.5 is particularly stable
with the deep profiler.
Estimated hours taken: 20
Branches: main
Changes to get shared libraries to work on Mac OS X (Darwin).
This is phase 2 of 2. Phase 1 added the compiler options described below.
Phase 2 uses these compiler options in the configuration scripts.
Darwin shared libraries have the extension `dylib' instead of `so'. Also
objects that link to a shared library on Darwin don't need to be told the
runtime path in which they should look for the libraries, instead the
shared libraries themselves remember where they will be eventually installed
(called the install-name) and any object which links in the shared library will
get the install-name from the shared library at link time. When a shared
library is built it has to be told where it will be installed which is what
the libtool -install_name option is used for on Darwin.
This diff only enables shared libraries on Darwin, not "bundles" which are
shared objects that can be loaded dynamically at runtime using something like
dlopen. Therefore the interactive query tool in the debugger still doesn't
work on Mac OS X.
Added three new compiler options :
--shlib-linker-use-install-name :
A boolean flag to tell the compiler to use the -install_name option
when building shared libraries. When this flag is set the following
options have no effect: --linker-rpath-flag, --linker-rpath-separator,
--shlib-linker-rpath-flag, --shlib-linker-rpath-separator.
--shlib-linker-install-name-flag :
The flag name to use ("-install_name" for Darwin).
--shlib-linker-install-name-path :
The path where the shared library will eventually end up, excluding the
file name. The file name is appended to the end before the option
is passed on to the linker.
Mmake.common.in
Added variables used for install-name on/off switch and flag name.
NEWS
Mentioned shared libs working now on Mac OS X.
README.MacOS
Removed bit about shared libs not working in Mac OS X.
configure.in
Make shared libs the default when on Darwin and the compiler is gcc.
boehm_gc/Makefile
boehm_gc/Makefile.direct
Added rule to make libgc.dylib and set the install-name correctly.
boehm_gc/Mmakefile
Set variable used in boehm_gc/Makefile to get the final install path
of the gc shared lib.
browser/Mercury.options
Added mer_mdbcomp library for target libmer_browser.dylib.
browser/Mmakefile
Added --shlib-linker-install-name-path option to MC options.
doc/user_guide.texi
Documented the --shlib-linker-install-name-path option. The other
options will be automatically set by the configure script and
should never need to be set by the user, so they're not documented in
the user guide.
runtime/Mmakefile
Added rule to make the Darwin shared library.
scripts/Mercury.config.bootstrap.in
Added default values for --shlib-linker-use-install-name and
--shlib-linker-install-name-flag.
scripts/Mercury.config.in
Added default values for --shlib-linker-use-install-name and
--shlib-linker-install-name-flag.
trace/Mmakefile
Added rule to make the Darwin shared library.
Estimated hours taken: 0:10
Notes on compiling Mercury on MacOS 10.3
README.MacOS:
New version of tar seems to work fine.
Mercury compiles using gcc 3.4.
Estimated hours taken: 1
Branches: main
Some more changes for MacOS.
aclocal.m4:
Define a macro MERCURY_CHECK_CC_NEEDS_CPP_PRECOMP,
to check whether we need to append `-traditional-cpp' to $CC.
configure.in:
bindist/bindist.configure.in:
Use the new macro.
README.MacOS:
Update the documentation: users don't need to configure using
`--with-cc="cc --traditional-cpp"' any more.
