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