Skip Menu |
 

Download (untitled) / with headers
text/plain 3.4KiB
From ppomes@Qualcomm.com Tue Nov 26 00:56:45 1996
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id AAA12251 for <bugs@RT-11.MIT.EDU>; Tue, 26 Nov 1996 00:56:44 -0500
Received: from zelkova.qualcomm.com by MIT.EDU with SMTP
id AA18034; Tue, 26 Nov 96 00:56:43 EST
Received: from localhost (localhost [127.0.0.1]) by zelkova.qualcomm.com (8.7.6/8.7.3) with ESMTP id VAA11012; Mon, 25 Nov 1996 21:56:39 -0800 (PST)
Message-Id: <11010.848987799@zelkova.qualcomm.com>
Date: Mon, 25 Nov 1996 21:56:39 -0800
From: Paul Pomes <ppomes@Qualcomm.com>
Sender: ppomes@Qualcomm.com
To: krb5-bugs@MIT.EDU
Cc: bind-workers@vix.com
Subject: typedef/#define conflict in krb5-b7 between BIND and db-config.h

Show quoted text
>Number: 241
>Category: pending
>Synopsis: typedef/#define conflict in krb5-b7 between BIND and db-config.h
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: gnats-admin
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Tue Nov 26 00:57:01 EST 1996
>Last-Modified: Fri Mar 28 00:56:30 EST 1997
>Originator:
>Organization:
>Release:
>Environment:
>Description:
>How-To-Repeat:
>Fix:
>Audit-Trail:

State-Changed-From-To: open-analyzed
State-Changed-By: marc
State-Changed-When: Tue Nov 26 01:02:30 1996
State-Changed-Why:

State-Changed-From-To: analyzed-closed
State-Changed-By: tytso
State-Changed-When: Fri Mar 28 00:56:15 1997
State-Changed-Why: This is a duplicate of PR #315


Show quoted text
>Unformatted:
>> Since the inclusion of one or both of the bitypes.h or db-config.h file
>> can occur in any order, I suggest that the configure utility be modify
>> to emit the above wrapper automatically when db-config.h is built.

This is the wrong answer. The right answer is for BIND *and* DB to
stop stomping on namespace which is reserved for the user. We'll
probably rename our symbols to be something like db_intxx_t, which
will fix the problems, but Paul should do something similar. Ugly?
Yes, but sized types are pretty ugly to begin with.

Under Solaris 2.4, Bind 4.9.5-rel installs the file sys/bitypes.h . Typically
it's installed as /usr/local/include/bitypes.h . This file is usually
pulled in from /usr/local/include/netdb.h . The typedefs of interest are
at line 78:

typedef /*signed*/ char int8_t;
typedef unsigned char u_int8_t;
typedef short int16_t;
typedef unsigned short u_int16_t;
typedef int int32_t;
typedef unsigned int u_int32_t;

When the Kerberos configure script is told to look in /usr/local/include
via '--with-cppopts=-I/usr/local/include', compiles of several modules
(src/krb524/krb524d.c, src/appl/telnet/telnet/commands.c, etc) fail due
to the #define's in src/include/db-config.h replacing the right-hand side
of the typedefs above:

#define int8_t signed char
#define u_int8_t unsigned char
#define int16_t short
#define u_int16_t unsigned short
#define int32_t int
#define u_int32_t unsigned int

My fix for now is to edit the db-config.h file after configure is done
to wrap the #define's with the same wrapper used in bitypes.h:

#ifndef __BIT_TYPES_DEFINED__
#define __BIT_TYPES_DEFINED__
[...]
#endif /* __BIT_TYPES_DEFINED__ */

Since the inclusion of one or both of the bitypes.h or db-config.h file
can occur in any order, I suggest that the configure utility be modify
to emit the above wrapper automatically when db-config.h is built.

/pbp
Download (untitled) / with headers
text/plain 2.4KiB
From rsw@Glue.umd.edu Sat Dec 21 04:14:11 1996
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id EAA14805 for <bugs@RT-11.MIT.EDU>; Sat, 21 Dec 1996 04:14:11 -0500
Received: from po1.glue.umd.edu by MIT.EDU with SMTP
id AA03940; Sat, 21 Dec 96 04:14:10 EST
Received: from atlantis.csc.umd.edu (rsw@atlantis.csc.umd.edu [129.2.8.129]) by po1.glue.umd.edu (8.8.3/8.7.3) with SMTP id EAA28611; Sat, 21 Dec 1996 04:14:03 -0500 (EST)
Message-Id: <Pine.SOL.3.95.961221035826.2961A-100000@atlantis.csc.umd.edu>
Date: Sat, 21 Dec 1996 04:13:59 -0500 (EST)
From: "Randall S. Winchester" <rsw@Glue.umd.edu>
Sender: rsw@atlantis.csc.umd.edu
To: krb5-bugs@MIT.EDU
Cc: paul@vix.com
Subject: krb5-1.0 BIND-4.9.5 Solaris-2.5 cc (configure problems)

Show quoted text
>Number: 314
>Category: pending
>Synopsis: krb5-1.0 BIND-4.9.5 Solaris-2.5 cc (configure problems)
>Confidential: yes
>Severity: serious
>Priority: medium
>Responsible: gnats-admin
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Sat Dec 21 04:15:01 EST 1996
>Last-Modified: Fri Mar 28 00:50:10 EST 1997
>Originator:
>Organization:
>Release:
>Environment:
>Description:
>How-To-Repeat:
>Fix:
>Audit-Trail:

State-Changed-From-To: open-closed
State-Changed-By: tytso
State-Changed-When: Fri Mar 28 00:49:39 1997
State-Changed-Why: All of the relevent detail is in PR#315 as well,
which has most of the discussion.

Show quoted text
>Unformatted:
I compile all software that uses the network with curent releases of BIND.
It seems the autoconf code in util/db2 is not quite right.

configure is not seeing that I already have the int*_t and u_int*_t
definitions.

This breaks compilation in the krb524 and kdc directories at least.

From my logs:

running /bin/sh ../../../src/util/db2/configure
--with-prefix=/usr/local/krb5 --localstatedir=/var --with-krb4
--with-tcl=/usr/local/tcl '--with-ccopts=-g -DMAXHOSTNAMELEN=256
-I/usr/local/bind/include' --sysconfdir=/var
--cache-file=../.././config.cache --srcdir=../../../src/util/db2
loading cache ../.././config.cache
.........
checking for int8_t... no
checking for u_int8_t... no
checking for int16_t... no
checking for u_int16_t... no
checking for int32_t... no
checking for u_int32_t... no
.....

The only workarounds seem to be to add the following to the configure line:

--with-ccopts="-g -D__BIT_TYPES_DEFINED__ ......

Or to compile with gcc wich spits out similar errors, but does not exit.

Randall
Download (untitled) / with headers
text/plain 2.1KiB
From tlyu@MIT.EDU Tue Nov 12 15:57:09 1996
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id PAA28103 for <bugs@RT-11.MIT.EDU>; Tue, 12 Nov 1996 15:57:08 -0500
Received: from TESLA-COIL.MIT.EDU by MIT.EDU with SMTP
id AA20727; Tue, 12 Nov 96 15:57:07 EST
Received: by tesla-coil.MIT.EDU (5.x/4.7) id AA16829; Tue, 12 Nov 1996 15:57:06 -0500
Message-Id: <9611122057.AA16829@tesla-coil.MIT.EDU>
Date: Tue, 12 Nov 1996 15:57:06 -0500
From: tlyu@MIT.EDU
Reply-To: tlyu@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: conflict between util/db2 and BIND 4.9.4 Patch 1 re u_int_*
X-Send-Pr-Version: 3.99

Show quoted text
>Number: 178
>Category: krb5-libs
>Synopsis: conflict between util/db2 and BIND 4.9.4 Patch 1 re u_int_*
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: krb5-unassigned
>State: open
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Tue Nov 12 15:58:01 EST 1996
>Last-Modified:
>Originator: Paul Pomes <ppomes@Qualcomm.com>
>Organization:
mit
Show quoted text
>Release: 1.0-development
>Environment:

System: SunOS tesla-coil 5.4 Generic_101945-37 sun4m sparc


Show quoted text
>Description:
[2249] daemon@ATHENA.MIT.EDU (Paul Pomes) Kerberos-V5-bugs 09/20/96 13:30 (25 lines)
Subject: conflict between util/db2 and BIND 4.9.4 Patch 1 re u_int_*
Date: Fri, 20 Sep 1996 10:29:56 -0700 (PDT)
From: Paul Pomes <ppomes@Qualcomm.com>
To: krb5-bugs@MIT.EDU

BIND's .../sys/bitypes.h is included by netdb.h . It defines the following
typedefs

typedef /*signed*/ char int8_t;
typedef unsigned char u_int8_t;
typedef short int16_t;
typedef unsigned short u_int16_t;
typedef int int32_t;
typedef unsigned int u_int32_t;

Unfortunately this file isn't checked by configure, nor should it I think.
One way to avoid the problem is for configure to also emit a wrapper
similar to what sys/bitypes.h uses


#ifndef __BIT_TYPES_DEFINED__
#define __BIT_TYPES_DEFINED__

.....

#endif /* __BIT_TYPES_DEFINED__ */
--[2249]--

Show quoted text
>How-To-Repeat:

Show quoted text
>Fix:

Show quoted text
>Audit-Trail:
>Unformatted:
Download (untitled) / with headers
text/plain 7.9KiB
From paul@vix.com Sat Dec 21 22:44:58 1996
Received: from MIT.EDU (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.69.0.28]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id WAA19489 for <bugs@RT-11.MIT.EDU>; Sat, 21 Dec 1996 22:44:57 -0500
Received: from gw.home.vix.com by MIT.EDU with SMTP
id AA04043; Sat, 21 Dec 96 22:44:57 EST
Received: by gw.home.vix.com; id TAA02780; Sat, 21 Dec 1996 19:44:55 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by wisdom.home.vix.com (8.8.2/8.8.2) with SMTP id TAA08619; Sat, 21 Dec 1996 19:44:55 -0800 (PST)
Message-Id: <199612220344.TAA08619@wisdom.home.vix.com>
Date: Sat, 21 Dec 1996 19:44:54 -0800
From: Paul A Vixie <paul@vix.com>
To: "Randall S. Winchester" <rsw@glue.umd.edu>
Cc: krb5-bugs@MIT.EDU
In-Reply-To: Your message of "Sat, 21 Dec 1996 04:13:59 EST."
<Pine.SOL.3.95.961221035826.2961A-100000@atlantis.csc.umd.edu>
Subject: Re: krb5-1.0 BIND-4.9.5 Solaris-2.5 cc (configure problems)

Show quoted text
>Number: 315
>Category: krb5-build
>Synopsis: Re: krb5-1.0 BIND-4.9.5 Solaris-2.5 cc (configure problems)
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: tlyu
>State: analyzed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Sat Dec 21 22:45:01 EST 1996
>Last-Modified: Fri Sep 14 10:25:35 EDT 2001
>Originator: Paul A Vixie <paul@vix.com>
>Organization:
>Release:
>Environment:
>Description:
So the Kerberos V system is another adopter of BIND's "{u_,}int{8,16,32,64}_t"
type names that has not also adopted the __BIT_TYPES_DEFINED__ protection I
specified for it. This puts Kerberos V into the excellent company of BSD 4.4,
and SGI IRIX 6.x. Oh well.
Show quoted text
>How-To-Repeat:
>Fix:
>Audit-Trail:

From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
To: krb5-bugs@MIT.EDU, Paul A Vixie <paul@vix.com>
Cc: gnats-admin@RT-11.MIT.EDU, krb5-prs@RT-11.MIT.EDU
Subject: Re: pending/315: Re: krb5-1.0 BIND-4.9.5 Solaris-2.5 cc (configure problems)
Date: Sun, 22 Dec 1996 00:48:43 -0500

krb5 is only using BIND's "{u_,}int{8,16,32,64}_t" because we're trying
to use Margo's hash/db library with minimal modifications, and BSD code
was never one to worry about silly things like preserving namespace to
avoid conflicts. (The krb5 library internals use krb5_int32, etc.)

Ultimately I think we're going to have to go through Margo's code to
make it play nice. As you've pointed out, BSD 4.4 and SGI Irix try to
define these symbols, without the __BIT_TYPES_DEFINED__ protection.
Personally, I'd prefer to rename them all to be "db_{u}int{8,16,32}"...

From: Marc Horowitz <marc@cygnus.com>
To: Paul A Vixie <paul@vix.com>
Cc: "Randall S. Winchester" <rsw@glue.umd.edu>, krb5-bugs@MIT.EDU
Subject: Re: pending/315: Re: krb5-1.0 BIND-4.9.5 Solaris-2.5 cc (configure problems)
Date: 22 Dec 1996 19:48:03 -0500

Paul A Vixie <paul@vix.com> writes:

Show quoted text
>> So the Kerberos V system is another adopter of BIND's
>> "{u_,}int{8,16,32,64}_t" type names that has not also adopted the
>> __BIT_TYPES_DEFINED__ protection I specified for it. This puts
>> Kerberos V into the excellent company of BSD 4.4, and SGI IRIX 6.x.
>> Oh well.

I wasn't aware of the Vixie C library standard. Could you provide a
reference? As Ted said, we'll probably fix this in the next release
by renaming all those symbols to a namespace which isn't used by a
zillion other systems.

FWIW, I don't think that we would have used those types if they
weren't already in bsd-derived code.

Marc

From: Paul A Vixie <paul@vix.com>
To: Marc Horowitz <marc@cygnus.com>
Cc: "Randall S. Winchester" <rsw@glue.umd.edu>, krb5-bugs@MIT.EDU
Subject: Re: pending/315: Re: krb5-1.0 BIND-4.9.5 Solaris-2.5 cc (configure problems)
Date: Sun, 22 Dec 1996 17:38:58 -0800

Show quoted text
>I wasn't aware of the Vixie C library standard. Could you provide a
>reference?

BIND 4.9.2 was where these symbols were first published. All other uses
have been derived from that, but no other uses have included the #define
that allows the rest of the symbols to be protected. Sorry if I'm a bit
grumpy about it, it made BIND > 4.9.2 portability really hard when it
could have been really easy. It's hardly MIT's fault though.

Show quoted text
> As Ted said, we'll probably fix this in the next release
>y renaming all those symbols to a namespace which isn't used by a
>illion other systems.

that's probably what BIND will have to do, as well. sigh.

From: "Randall S. Winchester" <rsw@Glue.umd.edu>
To: Paul A Vixie <paul@vix.com>
Cc: Marc Horowitz <marc@cygnus.com>, krb5-bugs@MIT.EDU
Subject: Re: pending/315: Re: krb5-1.0 BIND-4.9.5 Solaris-2.5 cc (configure problems)
Date: Tue, 24 Dec 1996 11:15:34 -0500 (EST)

I have looked at this some more and the problem stems from the an improper
implementation of the Berkeley DB code. in the krb5-1.0 source tree. In the
typical installation the include file db.h is protected as so:
#ifndef __BIT_TYPES_DEFINED__
#define __BIT_TYPES_DEFINED__
typedef __signed char int8_t;
typedef unsigned char u_int8_t;
typedef short int16_t;
typedef unsigned short u_int16_t;
typedef int int32_t;
typedef unsigned int u_int32_t;
#ifdef WE_DONT_NEED_QUADS
typedef long long int64_t;
typedef unsigned long long u_int64_t;
#endif
#endif

Thus I think it reasonable to patch krb5-1.0/src/util/db2/obj/db-config.h.in
as follows:
diff -c -r1.1 db-config.h.in
*** 1.1 1996/12/23 20:56:34
--- db-config.h.in 1996/12/23 20:56:44
***************
*** 20,31 ****
--- 20,34 ----
#undef u_int
#undef u_long

+ #ifndef __BIT_TYPES_DEFINED__
+ #define __BIT_TYPES_DEFINED__
#undef int8_t
#undef u_int8_t
#undef int16_t
#undef u_int16_t
#undef int32_t
#undef u_int32_t
+ #endif

#undef ssize_t

***************
*** 34,45 ****
--- 37,51 ----
#undef u_int
#undef u_long

+ #ifndef __BIT_TYPES_DEFINED__
+ #define __BIT_TYPES_DEFINED__
#undef int8_t
#undef u_int8_t
#undef int16_t
#undef u_int16_t
#undef int32_t
#undef u_int32_t
+ #endif

/* The number of bytes in a int. */
#undef SIZEOF_INT

Note: putting -D__BIT_TYPES_DEFINED__ in --with-ccopts does not completely
work, as then telnet and telnetd fail to compile, as they do not reference
the db2 include file. The above patch does work though.

Also, for Solaris I had to also use --with-ccopts="-DMAXHOSTNAMELEN=256 ..."
because of Sun moving the MAXHOSTNAMELEN define to "their" netdb.h from
sys/param.h.

I would suggest putting:
#ifndef MAXHOSTNAMELEN
#define MAXHOSTNAMELEN 256
#endif

in krb5-1.0/src/include/k5-int.h where it is defined for Windows.
or
in krb5-1.0/src/include/port-sockets.h where there is this:
#include <sys/param.h> /* For MAXHOSTNAMELEN */


Happy Holidays!

Randall


On Sun, 22 Dec 1996, Paul A Vixie wrote:

: >I wasn't aware of the Vixie C library standard. Could you provide a
: >reference?
:
: BIND 4.9.2 was where these symbols were first published. All other uses
: have been derived from that, but no other uses have included the #define
: that allows the rest of the symbols to be protected. Sorry if I'm a bit
: grumpy about it, it made BIND > 4.9.2 portability really hard when it
: could have been really easy. It's hardly MIT's fault though.
:
: > As Ted said, we'll probably fix this in the next release
: >y renaming all those symbols to a namespace which isn't used by a
: >illion other systems.
:
: that's probably what BIND will have to do, as well. sigh.
:

State-Changed-From-To: open-analyzed
State-Changed-By: tytso
State-Changed-When: Fri Mar 28 00:53:04 1997
State-Changed-Why: This one has been analyzed to death :-)
See also PR# 314 and PR# 241 (which have been closed since they
are duplicates).

Responsible-Changed-From-To: gnats-admin->tlyu
Responsible-Changed-By: tytso
Responsible-Changed-When: Fri Mar 28 00:54:17 1997
Responsible-Changed-Why: Changed category to krb5-build


Show quoted text
>Unformatted:
We haven't seen this come up recently, and it's likely that modern OSes
don't have this sort of namespace conflict anymore.