[mercury-users] Compiling mercury on a glibc2.1 linux computer

[Warwick Harvey]

Tyson wrote:
> On 10-Aug-1999, Warwick Harvey <wharvey at cs.monash.edu.au> wrote:
> > If you want any help diagnosing Red Hat 6.0 and/or glib 2.1, I'm currently 
> > running Mercury under both 5.2/2.0 with egcs-1.1b-2 and 6.0/2.1 with 
> > egcs-1.1.2-12.  I remember when getting it up and running under 6.0 the 
> > rotds went with asm_jump.gc, but I've been happily using asm_fast.gc for 
> > some time now.  I can't remember what (if anything) I did to "fix" it (it 
> > may have something to do with the `HAVE_INTTYPES_H=0' line in my 
> > `configure.in'), but could find out for sure if you want to know.
> 
> Ok, the problem is that inttypes.h has some function definitions in it.
> These come before the register definitions, so everything gets screwed
> up.
> 
> 1. Do we really need inttypes.h?
> 
> 2. Do we really need inttypes.h in mercury_types.h?

Below is Fergus's response to my mail to mercury-devel on June 7 pointing 
out this problem.  The discussion never went any further (I found my 
`HAVE_INTTYPES_H=0' hack and went to work on other things).

> On 07-Jun-1999, Warwick Harvey <wharvey at cs.monash.edu.au> wrote:
> > 
> > I appear to have discovered a more fundamental flaw in the inttypes, 
> > sys/types, stdint changes, which means one cannot (currently) compile the 
> > asm_fast, etc. grades on Red Hat 6.0 Linux systems (it uses asm_jump 
> > instead).
> > 
> > This problem may affect any systems on which Mercury uses a system-supplied 
> > header file to defined types.
> > 
> > On Red Hat 6.0 systems, the inttypes.h header file contains inline 
> > functions, which means any subsequent declaration of global registers will 
> > fail.  This is why mercury_imp.h starts with a big warning saying that it 
> > must be the first header file included, and in particular before any system 
> > header files.  Unfortunately, mercury_regs.h, which (indirectly) declares 
> > the global registers first includes mercury_types.h to define the 
> > appropriate types.  But if inttypes.h or similar exist, mercury_types.h 
> > includes it, breaking the requirement that no system header files be 
> > included first.
> 
> Ah.  That is an unfortunate problem.
> 
> One possible remedy for this problem is to use the gcc option
> `-fixed-<REG>' to reserve the appropriate registers.
> This would avoid the need for the requirement that the global
> register declarations precede any #includes of system header
> files.
> 
> > May I ask what the rationale for using these files was?  The compiler has to 
> > cope with them not existing (i.e. it defines its own types if it can't use 
> > ones defined by the system), and there have been a number of problems with 
> > the use of them on a number of systems already, so I'm just wondering what 
> > they gain us
> > (the simplest solution to the above problems seems to be to abandon the use 
> > of the inttypes.h file).
> 
> Well, the idea was to use the standard names, if available, and to
> emulate them, if not.  There are some advantages in using the standard
> names, in that people reading our source code will know immediately
> what those names mean.  If we abandon the use of the standard headers,
> then we would need to also abandon the use of the standard names for
> these types, and instead use names with `MR_' prefixes.
> 
> Unfortunately using the standard headers has turned out to be more difficult
> than we first thought.  And if we just insert `MR_' prefixes, but otherwise
> keep the names the same as in the standard header files, then the additional
> learning/readability burden is not very high.  So that may be the best
> solution.
> 
> -- 
> 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.


--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------