[m-dev.] Other things to do before the release.

Tyson Dowd trd at cs.mu.OZ.AU
Tue Oct 27 13:58:40 AEDT 1998


On 27-Oct-1998, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > 
> > 	- Generate libraries same as usual.
> > 	- Generate all code as PIC unless specified by user.
> > 	- --no-pic or something needs to be given as a MGNUCFLAG
> > 	  to turn this off.
> > 	- Use static linking if --static is defined, otherwise use
> > 	  shared linking.
> >
> > The picreg part of the grades would stop people accidently linking
> > non-PIC code with PIC libraries (at least for Mercury code).
> > 
> > Have I forgotten something?
> 
> I'm not sure what you mean by the first point ("generate libraries
> same as usual"); it seems to be contradicted by the ones that follow ;-)
> If you generate libraries "same as usual", but all code is PIC
> unless specified by the user, then the static libraries will be
> built as PIC too.  That would mean that there would be no way for the
> user to make use of the `--no-pic' option, since the installed copies
> of the libraries would all be PIC.
> 
> Maybe you meant that the *result* of generating the libraries
> should be the same as usual, rather than the *process*.
> But if so, you didn't explain how the process needs to be
> changed in order to achieve the same result.

When I say "usual" I mean "currently".

We generate the libraries the same as we currently do - PIC and
non-PIC versions.  This may involve some changes to make sure that
--no-pic is explicitly set for the static library, because we are
going to change the default behaviour to be PIC.

So for all code, we generate it as PIC by default.

If you want a statically linked program, you need to specify --static
and --no-pic (although it will not hurt anything but performance if you
forget the --no-pic option)

Is this clearer?

-- 
Those who would give up essential liberty to purchase a little temporary
safety deserve neither liberty nor safety.     - Benjamin Franklin

Tyson Dowd   <tyson at tyse.net>   http://tyse.net



More information about the developers mailing list