Bug 31955

Summary:	ULONG_MAX defined as hex on freebsd, ULONG_MAX defined as int on GNU, breaks autoconf
Product:	Base System	Reporter:	Sean Jensen-Grey <seanj>
Component:	misc	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	1.0-RELEASE
Hardware:	Any
OS:	Any

Description Sean Jensen-Grey 2001-11-13 20:30:01 UTC

I hit this when trying to compile the non-ports version of boa 0.94.11  on freebsd 4.3.

In the configure script is has a little piece of bc(1) code that determines how many bit to shift a ulong.

#include "confdefs.h"
#include <limits.h>

a = ULONG_MAX;
for (i=0;a;i++)
  a=a/2
for(j=0;i;j++)
  i=i/2
print j-1

on FreeBSD ULONG_MAX is defined as 0xfffffffful;

on GNU/Linux it is defined as 

[seanj@scale src]$ grep "ULONG_MAX" `locate limits.h`
/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/include/limits.h:#undef ULONG_MAX
/usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/include/limits.h:#define ULONG_MAX (LONG_MAX * 2UL + 1)
/usr/lib/bcc/include/asm/limits.h:#define ULONG_MAX     0xffffffff      /* maximum unsigned long value */
/usr/include/limits.h:#   define ULONG_MAX      18446744073709551615UL
/usr/include/limits.h:#    define ULONG_MAX     4294967295UL
/usr/include/limits.h:#    define ULONG_MAX     4294967295L

on freebsd 4.3 it is

bash-2.05$ grep "ULONG_MAX" `locate limits.h`
/usr/include/machine/limits.h:#define   ULONG_MAX       0xffffffffffffffffUL
/usr/include/machine/limits.h:#define   ULONG_MAX       0xffffffffUL    /* max value for an unsigned long */
/usr/src/contrib/gcc/glimits.h:#undef ULONG_MAX
/usr/src/contrib/gcc/glimits.h:#define ULONG_MAX (LONG_MAX * 2UL + 1)
/usr/src/sys/alpha/include/limits.h:#define     ULONG_MAX       0xffffffffffffffffUL    /* max for an unsigned long */
/usr/src/sys/alpha/include/limits.h:#define     SIZE_T_MAX      ULONG_MAX       /* max value for a size_t */
/usr/src/sys/alpha/include/limits.h:#define     UQUAD_MAX       (ULONG_MAX)     /* max value for a uquad_t */
/usr/src/sys/i386/include/limits.h:#define      ULONG_MAX       0xffffffffffffffffUL
/usr/src/sys/i386/include/limits.h:#define      ULONG_MAX       0xffffffffUL    /* max value for an unsigned long */

this code gets piped through the cpp, then tr to remove the UL and then passed to bc. But on freebsd bc barfs on the 0xffff; it actually barfs on any hex format. 

I kludged the configure script by replacing the ulong_max line with

a = 2^32;

and skipping the whole cpp, tr step

Now my question is. Is this actually a bug? Or is it something we can change to be more inline with everything else and make configure scripts run more reliably? Or is this just one of the differences between GNU and FreeBSD? I haven't tried changing the definition of ULONG_MAX and recompiling world. Do we just patch the configure script in the ports and call it a day?

Fix: 

patch the boa configure script and let differences be differences?

Comment 1 dwmalone 2001-11-13 20:49:05 UTC

On Tue, Nov 13, 2001 at 12:23:28PM -0800, Sean Jensen-Grey wrote:
> Now my question is. Is this actually a bug?

This is a bug in either boa configure script or autoconf, I guess.
It's reading a C header file, so it should be expected to understand
anything which C can.

I'll close the PR, unless you feel strongly otherwise?

	David.

Comment 2 dwmalone freebsd_committer

2001-11-13 20:58:13 UTC

State Changed
From-To: open->closed

Submitter is going to take it up with the boa guys.

Comment 3 Sean Jensen-Grey 2001-11-13 21:01:20 UTC

damn logic, you have a point.

I'll check with the boa guys and see if they manually added that check or
if it is an autoconf thing.

go ahead and close the PR.

Sean.

On Tue, 13 Nov 2001, David Malone wrote:

> On Tue, Nov 13, 2001 at 12:23:28PM -0800, Sean Jensen-Grey wrote:
> > Now my question is. Is this actually a bug?
>
> This is a bug in either boa configure script or autoconf, I guess.
> It's reading a C header file, so it should be expected to understand
> anything which C can.
>
> I'll close the PR, unless you feel strongly otherwise?
>
> 	David.
>