From owner-cvs-all  Sun Jul  4 20:18: 2 1999
Delivered-To: cvs-all@freebsd.org
Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.26.10.9])
	by hub.freebsd.org (Postfix) with ESMTP
	id ED49815238; Sun,  4 Jul 1999 20:17:49 -0700 (PDT)
	(envelope-from bde@godzilla.zeta.org.au)
Received: (from bde@localhost)
	by godzilla.zeta.org.au (8.8.7/8.8.7) id NAA24201;
	Mon, 5 Jul 1999 13:17:43 +1000
Date: Mon, 5 Jul 1999 13:17:43 +1000
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199907050317.NAA24201@godzilla.zeta.org.au>
To: green@FreeBSD.org, peter@netplex.com.au
Subject: Re: cvs commit: src/gnu/usr.bin/ld warnings.c
Cc: bde@FreeBSD.org, cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org,
	phk@critter.freebsd.dk
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk

>> You can configure gcc to compile with 'long' as a 64 bit entity on the x86
>> and it's handled by the backend the same way as the quad stuff is.  However

-DLONG_TYPE_SIZE=64

>I would assume then I need correct defines/typedefs. I'd like to do this to

Most typedefs use int32_t for types that must be 32 bits, and int64_t
for types that must be 64 bit .  int32_t is normally int on all types of
i386's (I haven't tried -DINT_TYPE_SIZE=16 :-), so long is almost never
used in fully typedefed code.  The main exception (only one that I've
found) is time_t, which needs to be 32 bits due to historical brokenness,
but is long on normal i386's.

The defines for LONG_MAX and ULONG_MAX obviously need changing.  I haven't
found any others.

The libc and libkern quad support needs some changes.  The normal i386
objects are needed but the quad routines want quad variables to be twice
as large as longs.

aout headers and tools are fully untypedefed and don't work.  Elf headers
and tools just work.

Bugs in makeworld (where it runs target executables on the host) need to
be fixed or avoided.

I don't have any of this organised.

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message