Ultrix patches version 2 for bind 8.2.2-P3

Simon Burge simonb at telstra.com.au
Wed Nov 17 06:49:15 UTC 1999


Paul A Vixie wrote:

> > Here's a second version of my patches for ultrix support.  This
> > introduces a new funtion called _bind_sprintf() to noop.c that
> > returns the length of the string printed to regardless of whether
> > the library is linked with -YPOSIX or not.
> 
> 1. noop.c is there so that "ar" will not complain about having no files to
> add, and "ld" won't complain that there are no files in the library.  it's
> a shill, a nothing, a discard.  as soon as a port has even one actual file
> that has actual code in it, then noop.c can be removed (by me, usually,
> since there are CVS things to do at that same time.)

I was using the "prior art" of port/irix/noop.c, and silently wondered
why a noop.c file had something in it :)

> 2. _bind_sprintf() is probably the wrong name for it, and the port/ultrix/
> directory is probably the wrong place for it.  this is portable code, and
> it can be in lib/isc/sprintf.c, and can be extern'd and #define'd in some
> new file like include/isc/sprintf.h.  then any .c file who depends on sprintf
> returning int should call this instead of the native (nonportable) sprintf.

I'm not 100% sure what you're aiming for here.  I don't think we can
unconditionally just prototype

	int sprintf(...);

because it'll conflict with <stdio.h> on some systems.  Do you mean
change all sprintf()'s in the bind code to isc_sprintf()?  Even with
Mark's sprintf() implemenentation, we'll need to keep VSPRINTF_CHAR for
lib/isc/logging.c, as well as the new isc_printf().

Or have an __isc_sprintf() that only gets used when NEED_INT_SPRINTF is
defined?  In the Ultrix case, we actually have the right prototype, just
the wrong return value is some circumstances!

> > diff -ur ../src-DIST/INSTALL ./INSTALL
> > --- ../src-DIST/INSTALL	Tue Nov  9 09:59:15 1999
> > +++ ./INSTALL	Wed Nov 10 00:03:16 1999
> > @@ -186,6 +186,12 @@
> >  		the problem.  Either run make with "SH=bash" on the command
> >  		line, or edit src/Makefile and change "SH=sh" to "SH=bash".
> >  
> > +	Ultrix
> > +
> > +		The ultrix /bin/sh is brain-dead.  Either run make with
> > +		"SH=sh5" on the command linke, or edit src/Makefile and
> > +		change "SH=sh" to "SH=sh5".
> > +
> >  FD_SETSIZE
> >  
> >  	The highest numbered file descriptor that the server and the resolver
> 
> 3. did you try setting SH=/bin/sh5 in port/ultrix/Makefile.set?  that may
> be enough, depending on whether the sh-vs-sh5 problems are being encountered
> in the top level Makefile or in the ones lower down.

I looked into this further - the problem is actually in port/systype.
Here's the 'cd' line from port/systype on /bin/sh and /bin/sh5:

	balrog:bind8/bind-8.2.2-P5/ultrix-src 152> sh
	$ cd `dirname port/systype` > /dev/null
	illegal io
	$ exit
	balrog:bind8/bind-8.2.2-P5/ultrix-src 153> sh5
	$ cd `dirname port/systype` > /dev/null
	$ exit

The problem seems to be with the "cd" builtin:

	balrog:bind8/bind-8.2.2-P5/ultrix-src 154> sh
	$ cd $HOME > /dev/null
	illegal io

Does the "> /dev/null" need to be there?  It looks like the port
directory should always be there.  If I remove the redirection on
port/systype, Ultrix gets by without needed SH=sh5.

> > diff -ur ../src-DIST/bin/named/ns_glue.c ./bin/named/ns_glue.c
> > --- ../src-DIST/bin/named/ns_glue.c	Tue Oct 19 12:06:26 1999
> > +++ ./bin/named/ns_glue.c	Wed Nov 10 15:54:36 1999
> > @@ -448,3 +448,14 @@
> >  	return (rename(oldname, newname));
> >  }
> >  #endif
> > +
> > +#ifdef ICKY_YUCKY_ULTRIX_STUFF
> > +#undef res_send
> > +int res_send(const u_char *buf, int buflen, u_char *ans, int anssiz) {
> > +	return __res_send(buf, buflen, ans, anssiz);
> > +}
> > +#undef _res_close
> > +void _res_close(void) {
> > +	__res_close();
> > +}
> > +#endif
> 
> 4. is there some reason why "#ifdef ultrix" isn't enough here?

Just that I wanted to make it really clear that this is an "icky yucky"
hack.  I'll change it to "#ifdef ultrix".

> that's all fine.
> 
> > --- ../src-DIST/port/ultrix/Makefile.set	Fri Mar 20 06:50:35 1998
> > +++ ./port/ultrix/Makefile.set	Wed Nov 10 11:22:56 1999
> > @@ -1,4 +1,4 @@
> > -'CC=cc -YPOSIX -Dconst='
> > +'CC=cc -std1'
> >  'CDEBUG=-g2 -O1 -Olimit 2000'
> >  'DESTBIN=/usr/bin'
> >  'DESTSBIN=/usr/etc'
> 
> 5. so now, if a program wants to link against libbind.a, it must NOT use
> -YPOSIX when it is compiled?  that hardly seems right.  please leave this
> as it was unless something is broken by -YPOSIX that isn't fixed by
> isc_sprintf().

I'm trying with just "-YPOSIX" now (no "-Dconst=") and seems ok so
far...  I really can't recall the original reason I decided -YPOSIX was
bad - maybe it was while I was looking at all the sprintf() goop.

Simon.


More information about the bind-workers mailing list