mirror of
https://github.com/Mercury-Language/mercury.git
synced 2025-12-12 20:34:19 +00:00
cc3dab98d9
Estimated hours taken: 0.75 Fix various problems, mostly minor, with the README* files. The most significant of these was that the ftp sites listed in the README file in the binary distribution were out-of-date. README.Linux: Fix a typo. .README.in: Mention some new README.* files. Update the version number and copyright dates for the Boehm GC. bindist/bindist.README: Update the version number and copyright dates for the Boehm GC. Update the ftp sites. Update the copyright date. Update the file names for the Mercury standard library and runtime library. bindist/Mmakefile: Include the files README.OSF1, README.Linux-Alpha, README.Linux-PPC, and README.Solaris in the binary distribution. bindist/bindist.README.Linux: Update to match the changes to README.Linux in the source distribution. profiler/mercury_profile.m: Update the copyright date printed by `mprof --help'.
44 lines
2.3 KiB
Plaintext
44 lines
2.3 KiB
Plaintext
This file documents just the Linux/x86 port.
|
|
For the Linux/PowerPC port, see README.Linux-PPC.
|
|
For the Linux/Alpha port, see README.Linux-Alpha.
|
|
(Ports to Linux on other architectures have not yet
|
|
been attempted, but should not be difficult.)
|
|
|
|
On Linux with a.out, shared libraries are not supported.
|
|
If you still have an old a.out system, the auto-configuration might
|
|
wrongly assume your Linux system uses ELF; if that happens, you will you
|
|
have to manually edit the EXT_FOR_SHARED_LIB variable in Mmake.common.
|
|
|
|
On Linux with ELF, shared libraries are supported. However, ELF shared
|
|
libraries require position-independent code, and (partly due to
|
|
limitations in our current compilation technology, but partly due to
|
|
limitations in the x86 architecture) this is quite costly for Mercury --
|
|
probably considerably more costly than it is for C.
|
|
|
|
Nevertheless, since shared libraries reduces disk usage, improve link
|
|
times, and allow run-time sharing of the Mercury libraries between
|
|
different applications, using them is a good idea.
|
|
|
|
Currently the default is that programs do *not* use the Mercury shared
|
|
libraries. (Probably it ought to be the other way around, but that
|
|
happened to be a little bit harder to implement. We may change this in
|
|
a future release.)
|
|
|
|
To use the shared libraries, you must compile your program with
|
|
`mmc --pic-reg' and link with `ml --shared' or add
|
|
`MGNUCFLAGS=--pic-reg' and `MLFLAGS=--shared' to your Mmake file.
|
|
|
|
Mercury code compiled with `--pic-reg' or with gcc's `-fpic' option has
|
|
what we shall call "PIC linkage", whereas Mercury code compiled without
|
|
these options has "non-PIC linkage". The static version of the Mercury
|
|
libraries has non-PIC linkage, while the shared version has PIC linkage.
|
|
Be careful that you do not try to link Mercury code with PIC linkage and
|
|
Mercury code with non-PIC linkage into the same executable, otherwise you
|
|
will probably get an obscure link error about `MR_grade_...' undefined
|
|
or `MR_runtime_grade' multiply defined.
|
|
(The reason for this is that standard non-PIC Mercury code uses the
|
|
`ebx' register in ways that are incompatible with its uses as the global
|
|
offset table pointer register in PIC code. If only the Intel
|
|
architecture wasn't so register-starved, we wouldn't need to use `ebx',
|
|
and then PIC and non-PIC code could be mixed without any problems.)
|