File: bindist.README.Linux

package info (click to toggle)
mercury 0.9-1
  • links: PTS
  • area: main
  • in suites: potato
  • size: 18,488 kB
  • ctags: 9,800
  • sloc: objc: 146,680; ansic: 51,418; sh: 6,436; lisp: 1,567; cpp: 1,040; perl: 854; makefile: 450; asm: 232; awk: 203; exp: 32; fortran: 3; csh: 1
file content (37 lines) | stat: -rw-r--r-- 1,960 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
Mercury has only been ported to Linux/x86, not to Linux/Alpha
Linux/PowerPC, Linux/m68k, etc.  Those other ports should
not be difficult, but this file documents just the Linux/x86 port.

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 --cflags -DPIC_REG' and link with `ml --mercury-libs shared'
or add `MGNUCFLAGS=-DPIC_REG' and `MLFLAGS=--mercury-libs shared'
to your Mmake file.

Mercury code compiled with `-DPIC_REG' or `-fpic' 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 very 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 your code will *almost certainly crash*.
(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.)