[m-dev.] cvs diff: scripts/ml.in

[Fergus Henderson]

Tyson Richard DOWD, you wrote:
> 
> > +Help="\
> > +Name: ml - Mercury Linker
> > +Usage: ml [<ml options>] [<gcc options] files...
> 
> s/<gcc options/<gcc options>/

Oops, ta.

> (also see note below about `--' )

Yes, good idea.

I'll fix both of those.

> >  esac
> > +case $FULLARCH in
> > +	i?86-*-linux*)
> > +		# shared libraries are not the default on Linux
> > +		# -- see README.Linux
> 
> Are you going to commit README.Linux soon? When you do, make sure
> this is true (I thought shared libs were going to be the default, and
> static libs were for speed - or does this require other changes
> first - eg making -fpic default on Linux).

Yes, it turned out to be easier to leave non-pic as the default.
That way, the only change need is that one to ml to by default link
with the non-shared libraries on Linux.  Making `-fpic' the default
would require a bunch of other changes.

I'll commit README.Linux, as well as the new configure.in which enables
the building of shared libraries for Linux, as soon as I have tested
that it all works.

Here's the updated version of README.Linux which reflects that change
to ml.

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

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 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. Also, the current
Mercury implementation does not support calling Mercury PIC shared
libraries from non-PIC Mercury code, so you pay this cost throughout
your application, not just in the shared libraries.

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

Be careful that you do not mix PIC Mercury code or non-PIC Mercury code,
otherwise your code will almost certainly crash.  The static version of
the Mercury libraries uses non-PIC code, while the shared version uses
PIC code.

#endif

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

-- 
Fergus Henderson <fjh at cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3         |     -- the last words of T. S. Garp.