From rsw@Glue.umd.edu Fri Dec 20 01:06:46 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 BAA07851 for <bugs@RT-11.MIT.EDU>; Fri, 20 Dec 1996 01:06:45 -0500
Received: from po1.glue.umd.edu by MIT.EDU with SMTP
id AA29753; Fri, 20 Dec 96 01:06:44 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 BAA01239 for <krb5-bugs@mit.edu>; Fri, 20 Dec 1996 01:06:43 -0500 (EST)
Message-Id: <Pine.SOL.3.95.961220005814.21753H-100000@atlantis.csc.umd.edu>
Date: Fri, 20 Dec 1996 01:06:41 -0500 (EST)
From: "Randall S. Winchester" <rsw@Glue.umd.edu>
Sender: rsw@atlantis.csc.umd.edu
To: krb5-bugs@MIT.EDU
Subject: Solaris 2.5+BIND-4.9* missing MAXHOSTNAMELEN
This is because solaris went and put MAXHOSTNAMELEN in on of the BIND
include files where it really does not belong.
Some global include file should have something like:
#ifndef MAXHOSTNAMELEN
#define MAXHOSTNAMELEN 256
#endif
As a workaround I can just:
configure --with-ccopts="-DMAXHOSTNAMELEN=256 -I/usr/local/bind/include"
but it is not all that elegant.
Randall
Responsible-Changed-From-To: gnats-admin->tlyu
Responsible-Changed-By: tlyu
Responsible-Changed-When: Thu Mar 20 12:33:11 1997
Responsible-Changed-Why:
Refiled
State-Changed-From-To: open-analyzed
State-Changed-By: tlyu
State-Changed-When: Thu Mar 20 12:33:28 1997
State-Changed-Why:
From: Tom Yu <tlyu@MIT.EDU>
To: rsw@Glue.umd.edu
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-build/312: Solaris 2.5+BIND-4.9* missing MAXHOSTNAMELEN
Date: Thu, 20 Mar 1997 12:37:13 -0500
We apologize for not getting back to you sooner, but we have in fact
received your bug report.
We have not yet come up with a solution, but some additional
information may be helpful. For instance, do any of these errors
indicating missing MAXHOSTNAMELEN turn up in system header files, or
are they all within the kerberos code proper?
---Tom
From: "Randall S. Winchester" <rsw@Glue.umd.edu>
To: Tom Yu <tlyu@MIT.EDU>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-build/312: Solaris 2.5+BIND-4.9* missing MAXHOSTNAMELEN
Date: Fri, 28 Mar 1997 12:30:51 -0500 (EST)
Well I have not don the compile in a while, but this problem is very typical
of programs compiled on Solaris that use BIND-4.9* headers and libraries.
MAXHOSTNAMELEN is usually defined in <sys/param.h>, but on solaris this
was moved (arbitrarily ?) to one of the "BSD" headers in the great SVR4
change. The looser was <netdb.h>, which is on of the BIND header files.
MAXHOSTNAMELEN is not part of BIND, but rather a system dependant number (64
or 256 typically). Because it is not part of BIND. it is not defined in any
of the BIND-4.9* header files, and thusly any references to MAXHOSTNAMELEN
fail.
My simple hack has been to put the following in a final header file.
#ifndef MAXHOSTNAMELEN
#define MAXHOSTNAMELEN 256 /* Solaris woes */
#endif
The "autoconf" way would be to have configure check for MAXHOSTNAMELEN.
However you may need to change your current setup to also look in all the
--with-...="-I/optional/include" locations. People often forget to add this
to their autoconf setup, meaning only the default include paths get
searched. Not doing this not only leaves the possibility of not including
things, but as in the MAXHOSTNAMELEN case, of also excluding things.
I hope this makes sence and helps!
Randall
On Thu, 20 Mar 1997, Tom Yu wrote:
: We apologize for not getting back to you sooner, but we have in fact
: received your bug report.
:
: We have not yet come up with a solution, but some additional
: information may be helpful. For instance, do any of these errors
: indicating missing MAXHOSTNAMELEN turn up in system header files, or
: are they all within the kerberos code proper?
:
: ---Tom
:
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 BAA07851 for <bugs@RT-11.MIT.EDU>; Fri, 20 Dec 1996 01:06:45 -0500
Received: from po1.glue.umd.edu by MIT.EDU with SMTP
id AA29753; Fri, 20 Dec 96 01:06:44 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 BAA01239 for <krb5-bugs@mit.edu>; Fri, 20 Dec 1996 01:06:43 -0500 (EST)
Message-Id: <Pine.SOL.3.95.961220005814.21753H-100000@atlantis.csc.umd.edu>
Date: Fri, 20 Dec 1996 01:06:41 -0500 (EST)
From: "Randall S. Winchester" <rsw@Glue.umd.edu>
Sender: rsw@atlantis.csc.umd.edu
To: krb5-bugs@MIT.EDU
Subject: Solaris 2.5+BIND-4.9* missing MAXHOSTNAMELEN
Show quoted text
>Number: 312
>Category: krb5-build
>Synopsis: Solaris 2.5+BIND-4.9* missing MAXHOSTNAMELEN
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: tlyu
>State: analyzed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Fri Dec 20 01:07:00 EST 1996
>Last-Modified: Fri Sep 14 10:24:57 EDT 2001
>Originator: Randall S. Winchester
>Organization:
>Release: krb5-1.0
>Environment:
>Description:
MAXHOSTNAMELEN is not defined when you build with BIND-4.9.5-P1 and such.>Category: krb5-build
>Synopsis: Solaris 2.5+BIND-4.9* missing MAXHOSTNAMELEN
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: tlyu
>State: analyzed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Fri Dec 20 01:07:00 EST 1996
>Last-Modified: Fri Sep 14 10:24:57 EDT 2001
>Originator: Randall S. Winchester
>Organization:
>Release: krb5-1.0
>Environment:
>Description:
This is because solaris went and put MAXHOSTNAMELEN in on of the BIND
include files where it really does not belong.
Some global include file should have something like:
#ifndef MAXHOSTNAMELEN
#define MAXHOSTNAMELEN 256
#endif
As a workaround I can just:
configure --with-ccopts="-DMAXHOSTNAMELEN=256 -I/usr/local/bind/include"
but it is not all that elegant.
Randall
Show quoted text
>How-To-Repeat:
>Fix:
>Audit-Trail:
>Fix:
>Audit-Trail:
Responsible-Changed-From-To: gnats-admin->tlyu
Responsible-Changed-By: tlyu
Responsible-Changed-When: Thu Mar 20 12:33:11 1997
Responsible-Changed-Why:
Refiled
State-Changed-From-To: open-analyzed
State-Changed-By: tlyu
State-Changed-When: Thu Mar 20 12:33:28 1997
State-Changed-Why:
From: Tom Yu <tlyu@MIT.EDU>
To: rsw@Glue.umd.edu
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-build/312: Solaris 2.5+BIND-4.9* missing MAXHOSTNAMELEN
Date: Thu, 20 Mar 1997 12:37:13 -0500
We apologize for not getting back to you sooner, but we have in fact
received your bug report.
We have not yet come up with a solution, but some additional
information may be helpful. For instance, do any of these errors
indicating missing MAXHOSTNAMELEN turn up in system header files, or
are they all within the kerberos code proper?
---Tom
From: "Randall S. Winchester" <rsw@Glue.umd.edu>
To: Tom Yu <tlyu@MIT.EDU>
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-build/312: Solaris 2.5+BIND-4.9* missing MAXHOSTNAMELEN
Date: Fri, 28 Mar 1997 12:30:51 -0500 (EST)
Well I have not don the compile in a while, but this problem is very typical
of programs compiled on Solaris that use BIND-4.9* headers and libraries.
MAXHOSTNAMELEN is usually defined in <sys/param.h>, but on solaris this
was moved (arbitrarily ?) to one of the "BSD" headers in the great SVR4
change. The looser was <netdb.h>, which is on of the BIND header files.
MAXHOSTNAMELEN is not part of BIND, but rather a system dependant number (64
or 256 typically). Because it is not part of BIND. it is not defined in any
of the BIND-4.9* header files, and thusly any references to MAXHOSTNAMELEN
fail.
My simple hack has been to put the following in a final header file.
#ifndef MAXHOSTNAMELEN
#define MAXHOSTNAMELEN 256 /* Solaris woes */
#endif
The "autoconf" way would be to have configure check for MAXHOSTNAMELEN.
However you may need to change your current setup to also look in all the
--with-...="-I/optional/include" locations. People often forget to add this
to their autoconf setup, meaning only the default include paths get
searched. Not doing this not only leaves the possibility of not including
things, but as in the MAXHOSTNAMELEN case, of also excluding things.
I hope this makes sence and helps!
Randall
On Thu, 20 Mar 1997, Tom Yu wrote:
: We apologize for not getting back to you sooner, but we have in fact
: received your bug report.
:
: We have not yet come up with a solution, but some additional
: information may be helpful. For instance, do any of these errors
: indicating missing MAXHOSTNAMELEN turn up in system header files, or
: are they all within the kerberos code proper?
:
: ---Tom
:
Show quoted text
>Unformatted: