Return-Path: dmorriso@us.oracle.com
Received: by gw.home.vix.com id AB00523; Mon, 7 Feb 94 05:29:06 -0800
Received: by uucp-gw-2.pa.dec.com; id AA01501; Mon, 7 Feb 94 02:12:03 -0800
Received:  from teal.us.oracle.com by gatekeeper.us.oracle.com with SMTP (8.6.4/37.7)
	id CAA10936; Mon, 7 Feb 1994 02:09:56 -0800
Received:  by teal.us.oracle.com (5.59.11/37.7)
	id AA02542; Mon, 7 Feb 94 02:09:53 PST
Message-Id: <9402071009.AA02542@teal.us.oracle.com>
To: paul@vix.com
Cc: Piete Brooks <Piete.Brooks@cl.cam.ac.uk>
From: Dave Morrison <drmorris@us.oracle.com>
Subject: sunos shared libs, my final patch
Date: Mon, 07 Feb 94 02:09:51 PST
Sender: dmorriso@us.oracle.com


Patch to bind-4.9.2b5+patch1.  I'm done with the shared library mods
(one way or the other).

The important changes from the previous version are the additional
documentation on the related issues, and the changes to reflect those
issues (object file moved - bug fix, global variable collision, gcc,
shared archive).

Comments from a few mini-alpha-test people was that the additional
information was most informative, however the building wasn't "as
smooth" as resolv+'s (resolv+ builds straight to libc.so in one step,
instead of making the resolv objects in one make then building libc in
another).  No technical problems, although the documentation wasn't
quite clear what to do with /usr/5lib files (fixed).

Piete, I would be happy to see a better build process (especially on the
end of building the complete shared library from one make), but I
currently am not available to get involved in doing it.  Please cc me
when you get a patch.  Your gcc inconsistent state problem was that you
re-ld'ed some of the objects.

Enjoy!

Dave Morrison

----------------------------------------------------------------------
diff -c -r bind-4.9.2b5/contrib/sunlibc/Info.sunsharedlib bind-4.9.2b5.patch/contrib/sunlibc/Info.sunsharedlib
*** bind-4.9.2b5/contrib/sunlibc/Info.sunsharedlib	Fri Nov  5 02:44:30 1993
--- bind-4.9.2b5.patch/contrib/sunlibc/Info.sunsharedlib	Mon Feb  7 01:51:36 1994
***************
*** 1,4 ****
! Updated by Dave Morrison for 4.9.2 release of bind.		11/4/93
  
  -------
  Message-Id: <9302101649.AA29641@irving.nas.nasa.gov>
--- 1,5 ----
! Updated by Dave Morrison <drmorris@mit.edu> for 4.9.2 release of bind.
! 11/4/93, 12/23/93, 1/25/94
  
  -------
  Message-Id: <9302101649.AA29641@irving.nas.nasa.gov>
***************
*** 26,39 ****
  to the (older) resolver library that comes with SunOS.
  
  
  
  
  A.  Get a 4.9.2 copy of bind, one which has the contrib/sunlibc
! directory.  Configure conf/options.h to taste as you would a standard
! bind installation.  Unless you are also compiling the name server you
! don't need to worry about the server specific options.  Options of
! consequence are DEBUG, RESOLVSORT, SUNSECURITY, ALLOW_T_UNSPEC,
! and ALLOW_UPDATES.
  
  Go to the contrib/sunlibc directory.  Run the make there.  Check the
  Makefile to get BUILDDIR right.  Make sure that it is the file that is
--- 27,44 ----
  to the (older) resolver library that comes with SunOS.
  
  
+ WARNING:
  
+ There are also dangers to modifying this process in various ways.  See
+ ISSUES.
  
+ 
  A.  Get a 4.9.2 copy of bind, one which has the contrib/sunlibc
! directory.  Do a "make links" to create a build tree, if you desire.
! Configure conf/options.h to taste as you would a standard bind
! installation.  Unless you are also compiling the name server you don't
! need to worry about the server specific options.  Options of consequence
! are DEBUG, RESOLVSORT, SUNSECURITY, ALLOW_T_UNSPEC, and ALLOW_UPDATES.
  
  Go to the contrib/sunlibc directory.  Run the make there.  Check the
  Makefile to get BUILDDIR right.  Make sure that it is the file that is
***************
*** 41,48 ****
  options!
  
  This rebuilds the resolv library with the cflags required for shared
! libraries (-pic).  It also copies the object files to place in libc into
! the current directory.
  
  		cd .../bind-4.9.2/contrib/sunlibc
  		make BUILDDIR=../../sun4.b
--- 46,54 ----
  options!
  
  This rebuilds the resolv library with the cflags required for shared
! libraries (-fpic (gcc) or -pic (sun cc)).  Use gcc if at all possible.
! The make copies the object files to place in libc into the current
! directory.
  
  		cd .../bind-4.9.2/contrib/sunlibc
  		make BUILDDIR=../../sun4.b
***************
*** 50,62 ****
  B.  Follow the steps below to make a new shared library on your Sun
  which includes the new resolver library routines in it.
  
! 	(If you feel confident you know what to do, you can copy the
! 	provided script make_lib.sh into /usr/lib/shlib.etc and run it.
! 	It does steps 1-8, although is not very safety checking.  It is,
! 	however, convenient for admins who are tired of typing or
! 	copying all these commands!)
  
      1.  Move into the shared-lib area and make a temporary directory:
  		cd /usr/lib/shlib.etc
  		mkdir tmp
  
--- 56,93 ----
  B.  Follow the steps below to make a new shared library on your Sun
  which includes the new resolver library routines in it.
  
! 	This shared library area is an optionally installed item from
! 	the SunOS distribution.  An update to all 4.1.x versions of
! 	the shared library is available from Sun as a patch (4.1.3's
! 	patch id is 100890-08).  This patch is recommended as it fixes
! 	a few infamous Sun bugs.
! 
! 	Part of the patch in the given script (for the Makefile) as well
! 	as the second part of of step 7 instructions (add -ldl) are not
! 	required for the patched version of the shared libraries.
! 
! 	The provided script make_lib.sh will do steps 1-8 for you, and
! 	copy the shared archives.  It's not a very safety checking
! 	script, but does the job for me.  I like it because I'm tired of
! 	typing all these commands!  Copy make_lib.sh into
! 	/usr/lib/shlib.etc (or wherever your shared library directory
! 	is), edit the top to set the $resolvobjdir variable, and then
! 	run it.
! 
! 	Be aware that there also is a sysV libc (/usr/5lib/libc.so.x.y.z).   
! 	To build a replacement for that, repeat this entire procedure
! 	but use libcs5_pic.a in step 2.  NOTE:  The make_lib.sh
! 	script builds both the ucb and sysV libcs.  The libc.so.2.8
! 	files are for /usr/5lib.
! 
! 	These directions do nothing with the static libc
! 	(/usr/{,5}lib/libc.a).  Be aware that users who compile with
! 	-Bstatic (-static for gcc) will see none of these changes.  You
! 	may want to change the static libc, so that users aren't greatly
! 	confused as to why -Bstatic changes functionality so.
  
      1.  Move into the shared-lib area and make a temporary directory:
+ 
  		cd /usr/lib/shlib.etc
  		mkdir tmp
  
***************
*** 73,83 ****
  
      3.  Copy the object files created in part A to this libc build
  	directory.  This will replace Sun's inet_addr.o, which is
! 	ok, this one is better.  Make sure that Sun's mktemp.o and
! 	strpbrk.o don't get stomped, you need to use Sun's.
  
- 		cp -i .../bind-4.9.2/contrib/sunlibc/*.o .
- 
      4.  Make sure the old host resolver is not still lying around:
  		rm gethostent.o
  	(ignore error "rm: gethostent.o nonexistent" if you see it.)
--- 104,118 ----
  
      3.  Copy the object files created in part A to this libc build
  	directory.  This will replace Sun's inet_addr.o, which is
! 	ok, this one is better.  It will also replace Sun's getnetent.o,
! 	which is ok, as long as you have DNS entries for your networks.
! 	Make sure that Sun's mktemp.o and strpbrk.o don't get stomped,
! 	you need to use Sun's. 
! 
! 		cp -i $BUILDDIR/shres/*.o .
! 		cp -i $BUILDDIR/shcompat/lib/inet_addr.o .
! 		cp -i $BUILDDIR/shcompat/lib/strerror.o .
  
      4.  Make sure the old host resolver is not still lying around:
  		rm gethostent.o
  	(ignore error "rm: gethostent.o nonexistent" if you see it.)
***************
*** 91,96 ****
--- 126,132 ----
  	if they haven't already been done before to this file:
  		remove: gethostent.o
  		add:	gethnamaddr.o
+ 			herror.o
  			sethostent.o
  			res_query.o
  			res_mkquery.o
***************
*** 98,128 ****
  			res_debug.o
  			res_comp.o
  			res_init.o
! 			herror.o
! 			strerr.o
! 	(the last two are new, which Sun's resolver doesn't use)
! 	After deleting gethostent.o, you can use the following
! 	patch, or make the changes by hand (in this order):
! 
! 		***************
! 		*** 149,154 ****
! 		--- 149,164 ----
! 		  listen.o
! 		  getwd.o
! 		  getnetgrent.o
! 		+ gethnamaddr.o
! 		+ herror.o
! 		+ sethostent.o
! 		+ res_query.o
! 		+ res_mkquery.o
! 		+ res_send.o
! 		+ res_debug.o
! 		+ res_comp.o
! 		+ res_init.o
! 		+ strerror.o
! 		  ypxdr.o
! 		  ttyname.o
! 		  setbuffer.o
  
      7.  The Makefile in shlib.etc for building shared libraries
  	has one problem when you run it as the super user.  So
--- 134,149 ----
  			res_debug.o
  			res_comp.o
  			res_init.o
! 			getnetnamadr.o
! 			getnetbyname.o
! 			getnetbyaddr.o
! 			strerror.o
! 
! 	If you don't want the getnet* routines (some sites want to use
! 	yp for getting networks), delete the getnet* lines.  It isn't
! 	really legitimate to hack the lorder-sparc file like this, but
! 	it isn't deadly either.  Other orderings may have different
! 	performance effects (could be better, could be worse...).
  
      7.  The Makefile in shlib.etc for building shared libraries
  	has one problem when you run it as the super user.  So
***************
*** 130,137 ****
  
  		OBJSORT=./objsort
  
! 	If you are using SunOS 4.1.2, change the lines (there are two)
! 	in the Makefile	which read
  
  		ld -assert pure-text `${OBJSORT} lorder-sparc tmp`
  
--- 151,158 ----
  
  		OBJSORT=./objsort
  
! 	If you are using the SunOS 4.1.x unpatched shlib.etc, change the
! 	lines (there are two) n the Makefile which read
  
  		ld -assert pure-text `${OBJSORT} lorder-sparc tmp`
  
***************
*** 139,144 ****
--- 160,167 ----
  
  		ld -assert pure-text `${OBJSORT} lorder-sparc tmp` -ldl
  
+ 	The patched shlib.etc already has this fixed.
+ 
      8.  Now we can finally build the shared library.  Type:
  		make libc.so
  
***************
*** 177,182 ****
--- 200,227 ----
  		chmod 755 /usr/lib/lib.so.x.y.z
  		ldconfig
  
+ 	Next you need to install the shared archive, which contains
+ 	initialized global data.  If you skip this step, executables
+ 	compiled on your machine since the new library was installed
+ 	will not contain that data.  They still will be able to run
+ 	(which is probably why this step has been missing from both the
+ 	Internet and *Sun* instructions for years), as the data is
+ 	replicated in the shared object.  A few	preliminary tests
+ 	indicate missing this step can marginally slow down processes,
+ 	although it necessarily a depends on the program and the machine
+ 	in question.
+ 
+ 	If you have a Sun libc patch (such as 100890-08 for 4.1.3 -
+ 	highly recommended), use the shared archive from that
+ 	distribution, rather than the one from the /usr/lib that came
+ 	with the machine.  The numbers x, y, and z must match the
+ 	numbers in the shared object above.
+ 
+ 
+ 		cd /usr/lib
+ 		cp libc.sa.x.y libc.sa.x.y.z
+ 		ranlib libc.sa.x.y.z
+ 
     11.  You can prove that you're using the new library now,
  	by watching the output of something like:
  		trace date
***************
*** 186,189 ****
  	tools such as named, nslookup, etc.  You do not need to
  	specify the "-lresolv" library when compiling these tools.
  
! 
--- 231,236 ----
  	tools such as named, nslookup, etc.  You do not need to
  	specify the "-lresolv" library when compiling these tools.
  
!    12.	Once you are fully confident of your new library, reboot your
! 	machine.  Until you do, running process will continue to use the
! 	old shared library.
diff -c -r bind-4.9.2b5/contrib/sunlibc/Makefile bind-4.9.2b5.patch/contrib/sunlibc/Makefile
*** bind-4.9.2b5/contrib/sunlibc/Makefile	Fri Nov  5 02:39:31 1993
--- bind-4.9.2b5.patch/contrib/sunlibc/Makefile	Thu Feb  3 23:48:16 1994
***************
*** 1,26 ****
! # Simple, but effective way of recompling the 
  
  MAKE=make
  SHELL=/bin/sh
  
! # These are important to be the way they are.  Make sure you know what
! # you are doing if you change them.
! LDS=:
! CC=cc -DBSD -pic
  
! BUILDDIR=../../native.b
  
! NETOBJ=getnetbyaddr.o getnetbyname.o getnetent.o getnetnamadr.o
! RESOBJ=gethnamaddr.o herror.o inet_addr.o res_comp.o res_debug.o \
! res_init.o res_mkquery.o res_query.o res_send.o sethostent.o $(NETOBJ)
! COMPATOBJ=strerror.o
  
! MFLAGS= "LDS=${LDS}" "SUBDIRS=res compat" "CC=$(CC)"
  
! all: force objects copy
  
! force: FRC
! 	(cd $(BUILDDIR); $(MAKE) $(MFLAGS) clean)
  
  objects: FRC
  	(cd $(BUILDDIR); pwd; $(MAKE) $(MFLAGS) all)
--- 1,53 ----
! # Simple, but effective way of recompling the libraries for shared use
  
  MAKE=make
  SHELL=/bin/sh
  
! # Use gcc if at all possible.  Sun's regular 4.1.3 cc places read-only
! # data in the read-write section of the shared library.  Since the
! # read-write segment must be replicated for all processes, this makes
! # the library less efficient. 
! #  Some people have reported problems using gcc, however I have not been
! #  able to reproduce them.
! # Define _res to be _res_shlib to avoid a global variable collision on
! # _res between the shared libraries and the static resolv library.
! 
! COMP=gcc -fpic
! #COMP=cc -pic
  
! CC=$(COMP) -DBSD -D_res=_res_shlib
  
! # Take your pick of -g, -O, -g -O.
! CDEBUG=-O
  
! # Define LDS to be no command.  This stops ld from mucking with with the
! # -pic objects after they are built.
! LDS=:
  
! BUILDDIR=../../native.b
  
! NETOBJ=getnetbyaddr.o getnetbyname.o getnetent.o getnetnamadr.o
! RESOBJ=gethnamaddr.o herror.o res_comp.o res_debug.o res_init.o \
! res_mkquery.o res_query.o res_send.o sethostent.o $(NETOBJ)
! COMPATOBJ=inet_addr.o strerror.o
! 
! MFLAGS= "LDS=$(LDS)" "SUBDIRS=shres shcompat" "CC=$(CC)" "CDEBUG=$(CDEBUG)"
! 
! all: sundir objects copy
! 
! sundir: FRC
! 	if [ ! -d $(BUILDDIR)/shres ]; then \
! 		mkdir $(BUILDDIR)/shres; \
! 		cd $(BUILDDIR)/shres; \
! 		ln -s ../res/*.c ../res/Makefile .; \
! 	fi
! 	if [ ! -d $(BUILDDIR)/shcompat ]; then \
! 		mkdir $(BUILDDIR)/shcompat $(BUILDDIR)/shcompat/lib; \
! 		cd $(BUILDDIR)/shcompat; \
! 		ln -s ../compat/Makefile ../compat/include .; \
! 		cd lib; \
! 		ln -s ../../compat/lib/*.c ../../compat/lib/Makefile .; \
! 	fi
  
  objects: FRC
  	(cd $(BUILDDIR); pwd; $(MAKE) $(MFLAGS) all)
***************
*** 27,39 ****
  
  copy: FRC
  	for f in $(RESOBJ); do \
! 		cp $(BUILDDIR)/res/$$f .; \
  	done
  	for f in $(COMPATOBJ); do \
! 		cp $(BUILDDIR)/compat/lib/$$f .; \
  	done
  
  clean: FRC
  	$(RM) *.o
  
  FRC:
--- 54,69 ----
  
  copy: FRC
  	for f in $(RESOBJ); do \
! 		cp $(BUILDDIR)/shres/$$f .; \
  	done
  	for f in $(COMPATOBJ); do \
! 		cp $(BUILDDIR)/shcompat/lib/$$f .; \
  	done
  
  clean: FRC
  	$(RM) *.o
+ 
+ veryclean: clean FRC
+ 	$(RM) -rf $(BUILDDIR)/shres $(BUILDDIR)/shcompat
  
  FRC:
diff -c -r bind-4.9.2b5/contrib/sunlibc/make_lib.sh bind-4.9.2b5.patch/contrib/sunlibc/make_lib.sh
*** bind-4.9.2b5/contrib/sunlibc/make_lib.sh	Fri Nov  5 02:50:55 1993
--- bind-4.9.2b5.patch/contrib/sunlibc/make_lib.sh	Thu Feb  3 23:33:06 1994
***************
*** 1,5 ****
--- 1,8 ----
  #!/bin/sh
  
+ # This build process should really be in a Makefile, but I'd prefer to
+ # leave Sun's distributed Makefile alone
+ 
  # Set this variable to be the .../bind/contrib/sunlibc directory to where the
  #  special libc .o files were copied.
  #resolvobjdir=/usr/local/src/bind-4.9.2/contrib/sunlibc
***************
*** 7,18 ****
  
  if [ "${resolvobjdir}x" = "x" ]; then
  	echo 'Edit the make_lib script to set $resolvobjdir to the proper'
! 	echo '.../bind/contrib/sunlibc directory.'
  	exit 1
  fi
  
! mkdir tmp
! cd tmp
  ar x ../libc_pic.a
  rm __.SYMDEF
  for f in *.; do
--- 10,26 ----
  
  if [ "${resolvobjdir}x" = "x" ]; then
  	echo 'Edit the make_lib script to set $resolvobjdir to the proper'
! 	echo 'bind directory (.../bind/contrib/sunlibc).'
  	exit 1
  fi
  
! # Extract and setup the ucb libc
! if [ ! -d tmp.ucb ]; then
! 	rm -f tmp.ucb
! 	mkdir tmp.ucb
! fi
! cd tmp.ucb
! rm -rf *
  ar x ../libc_pic.a
  rm __.SYMDEF
  for f in *.; do
***************
*** 20,36 ****
  done
  rm gethostent.o
  
  cp $resolvobjdir/*.o .
  
  cd ..
  if [ ! -f lorder-sparc.orig ]
  then
          patch < $resolvobjdir/sun-lorder-sparc.patches
  fi
  if [ ! -f Makefile.orig ]
  then
          patch < $resolvobjdir/sun-Makefile.patches
  fi
  
  time make libc.so
! ls -l
--- 28,92 ----
  done
  rm gethostent.o
  
+ # Sun's inet_addr.o and possible getnetent.o are clobbered in this copy
+ cp $resolvobjdir/*.o .
+ 
+ cd ..
+ # Extract and setup the sysv libc
+ if [ ! -d tmp.s5 ]; then
+ 	rm -f tmp.s5
+ 	mkdir tmp.s5
+ fi
+ cd tmp.s5
+ rm -rf *
+ ar x ../libcs5_pic.a
+ rm __.SYMDEF
+ for f in *.; do
+ 	mv $f ${f}o
+ done
+ rm gethostent.o
+ 
+ # Sun's inet_addr.o and possible getnetent.o are clobbered in this copy
  cp $resolvobjdir/*.o .
  
+ # Back to the make directory
  cd ..
+ 
+ # Add the res data objects the lorder sparc listing (uncool hack)
  if [ ! -f lorder-sparc.orig ]
  then
          patch < $resolvobjdir/sun-lorder-sparc.patches
  fi
+ # Fix broken Makefile
+ # only half needed for version with patch 100890-08+
  if [ ! -f Makefile.orig ]
  then
          patch < $resolvobjdir/sun-Makefile.patches
  fi
  
+ # Make the sys5 shared libc
+ rm -f tmp
+ ln -s tmp.s5 tmp
+ time make libcs5.so
+ 
+ # Make the ucb shared libc
+ rm -f tmp
+ ln -s tmp.ucb tmp
  time make libc.so
! 
! # Setup the shared archives
! #  Use the latest so as the rev, because the so and sa versions need to
! #  match.  Normally they would be the same in /usr/lib, but Sun's patch
! #  instructions don't make new ones.
! /bin/ls /usr/lib/libc.so.* > TMP_FILE
! ucb_sa=libc.sa.`cat TMP_FILE | awk -f awkfile`
! /bin/ls /usr/5lib/libc.so.* > TMP_FILE
! s5_sa=libc.sa.`cat TMP_FILE | awk -f awkfile`
! 
! # copy latest shared arcives to local directory
! cp `ls /usr/lib/libc.sa.* | sort -t. +4n | tail -1` $ucb_sa
! cp `ls /usr/5lib/libc.sa.* | sort -t. +4n | tail -1` $s5_sa
! 
! # ranlib them
! ranlib $ucb_sa
! ranlib $s5_sa
diff -c -r bind-4.9.2b5/contrib/sunlibc/sun-lorder-sparc.patches bind-4.9.2b5.patch/contrib/sunlibc/sun-lorder-sparc.patches
*** bind-4.9.2b5/contrib/sunlibc/sun-lorder-sparc.patches	Fri Nov  5 01:32:36 1993
--- bind-4.9.2b5.patch/contrib/sunlibc/sun-lorder-sparc.patches	Tue Jan 25 18:04:15 1994
***************
*** 1,5 ****
! *** lorder-sparc-dist	Mon Aug 31 20:24:07 1992
! --- lorder-sparc	Thu Nov  4 23:20:33 1993
  ***************
  *** 149,155 ****
    listen.o
--- 1,5 ----
! *** lorder-sparc-dist	Mon Sep 20 14:36:23 1993
! --- lorder-sparc	Tue Jan 25 17:17:20 1994
  ***************
  *** 149,155 ****
    listen.o
***************
*** 9,15 ****
    ypxdr.o
    ttyname.o
    setbuffer.o
! --- 149,164 ----
    listen.o
    getwd.o
    getnetgrent.o
--- 9,15 ----
    ypxdr.o
    ttyname.o
    setbuffer.o
! --- 149,167 ----
    listen.o
    getwd.o
    getnetgrent.o
***************
*** 22,27 ****
--- 22,30 ----
  ! res_debug.o
  ! res_comp.o
  ! res_init.o
+ ! getnetnamadr.o
+ ! getnetbyname.o
+ ! getnetbyaddr.o
  ! strerror.o
    ypxdr.o
    ttyname.o
*** /dev/null	Sun Feb  6 03:38:42 1994
--- bind-4.9.2b5.patch/contrib/sunlibc/ISSUES	Mon Feb  7 01:51:29 1994
***************
*** 0 ****
--- 1,158 ----
+ - Dave Morrison <drmorris@mit.edu> - 2/3/95 -
+ 
+ Changes to the shared library setup have lots of little pitfalls and mines.
+ This is an attempt to map the minefield, for those who feel they've
+ noticed something that they think should be done another way.
+ 
+ 
+ * What's shared, what's static
+ 
+ The purpose of these modifications to Sun's libc.so is to provide DNS
+ lookup for gethostby* and if you desire, getnetby*.  This involves
+ replacing the following SunOS libc routines.
+ 
+ 	gethostbyname			getnetbyname
+ 	gethostbyaddr			getnetbyaddr
+ 	gethostent			getnetent
+ 	sethostent			setnetent
+ 	endhostent			endnetent
+ 
+ The routines use the res_* routines from the resolv library to get their
+ information from DNS.  Because it is most convenient, all these objects
+ are linked into the shared library, meaning they are linkable without
+ using -lresolv.  Full details are given below, and unless you want to
+ get into the nitty gritty, obey the following rule.
+ 
+ Anything which uses -lresolv rountines other than the stock OS routines
+ above should link using -lresolv.
+ 
+ The symptom of not obeying this rule is finding that _res is unresolved
+ at link time.
+ 
+ 
+ * global variable collision
+ 
+ The global variable _res is particularly troublesome.  Any executables
+ which was compiled with -lresolv before the shared library was installed
+ has in it _res staticly compiled in as a global data structure.
+ Unfortunately, the resolv library in 4.9.2 BIND has a global variable
+ _res, and it is defined slightly differently.  At run time, when the
+ shared libraries are loaded up, some linking is done at runtine.  The
+ runtime linker, notices that _res is staticly defined and does not link
+ in the dynamic version.  This means that if the shared libc calls ever
+ call called from this executable, they would overwrite the static
+ version.  Since the static version is a smaller data structure, this
+ could overwrite bits of memory.  Not good.  It turns out the worst case
+ is not a likely scenario, but I'd rather be safe then sorry.
+ 
+ This is why the Makefile for contrib/sunlibc does -D_res=_res_shlib.
+ The collision is removed.  This means that _res is not accessable as a
+ global variable in the shared libc library.  To compile a program which
+ accesses _res directly, libresolv must linked in staticly.
+ 
+ This would not be a problem if you could recompile any code which used
+ libresolv.  This would mean recompiling some of SunOS and perhaps other
+ vendor code if you've obtained additional software.  Since people don't
+ generally have the source to everything on the machine, this isn't a
+ viable option except for Sun and miscellaneous wizards.
+ 
+ 
+ * Having named and tools linked with a shared libc.
+ 
+ It is very tempting and almost doable to compiled the entire bind
+ distribution with a resolv in a shared libc.  There are dangers
+ associated with doing this.  First, there's the global variable
+ collision problem mentioned above.  Second, there's a problem of
+ maintaining the the shared library version control.
+ 
+ People have a tendency to copy tools like dig or the named server from
+ machine to machine.  If the new shared library (the one with *this*
+ distributions resolv) is not present on the machines to which these
+ goodies are copied TO, the user will be getting SUN'S copy of resolv.
+ This could cause you to lose most heinously, and you will spend DAYS if
+ not WEEKS trying to figure out what the problem is.  It's debatable if
+ there's even a performance improvement by doing the sharing.  Compare
+ that to the debugging and frustration time you are going to spend.
+ 
+ You also will need to replace libc everywhere when a new release when
+ new releases come out.  This isn't as big an issue for a production
+ release of bind, but for the alpha test team, it means a few less things
+ to worry about, when there is already plenty to worry about.
+ 
+ Again, if you could recompile the machine, there wouldn't be a problem.
+ Vendors should release the tools and server shared, as they already have
+ the assurance that there is a standard libc, and users may want to
+ handle some problem routines by relinking the shared library.
+ 
+ 
+ * shared archives
+ 
+ In addition to a shared object (the libc.so files) which contain the
+ executable libc code, there is also a shared archive (the libc.sa
+ files).   The shared archive contains global initialized data.  When a
+ program is linked, if it accesses any of this global initialized data,
+ that data is included from the shared archive in the final executable.
+ Some examples include errno (intialzed to zero), the ctype.h tables,
+ sys_errlist, and _iob for stdio.
+ 
+ If this data is not accessable from a shared archive, but is accessable
+ from the shared object (e.g. no libc.sa.x.y.z exists for libc.so.x.y.z),
+ the shared object copy will be used, but not linked into the executable.
+ This results in a performance hit for executables which used that data.
+ Sun's documentation claims this to be possibly degrading to the system
+ as a whole on a heavily used library.  I have yet to observe anything
+ besides a slight (max 10%) performance hit.
+ 
+ This is why it is important to copy+ranlib the old libc.sa.a.b.c, when
+ creating a new libc.so.x.y.z.  Sun's instructions in building a new
+ shared libc (shlib.etc package or patch) neglect to mention this.
+ 
+ There are 5 instances of global initialized data in -lresolv.  They are
+ _res (renamed to _res_shlib), _res_resultcodes, _res_opcodes, h_errlist,
+ and h_nerr.  In principle, they should be added to libc.sa.x.y.z.
+ However, long as they are never referenced, it does not matter that they
+ are not there.  Programs which use these variables should link with
+ -lresolv to get the static version, and the problem is solved.
+ 
+ The reason for not including them in the shared archive, is that there
+ is a potential problem in that if this global data ever changed, as it
+ might in a future bind release, the MAJOR version of the library should
+ change.  By using the static versions with -lresolv, you allow yourself
+ the option to upgrade the -lresolv code without major fuss.
+ 
+ 
+ * shared library revision numbers
+ 
+ Technically, the shared library changes are sufficient enough to warrent
+ a minor revision change.  On SunOS 4.1.3, this would mean the shared
+ library should be numbered libc.so.1.9.  However, if Sun could used that
+ in another SunOS release, and you went to upgrade, suddenly there would
+ be two libc.so.1.9's.  Programs would be compiled to use "libc.so.1.9"
+ and would be no distinction between those which want to use the SunOS
+ libc.so.1.9 and those which want the locally compiled libc.so.1.9.  At
+ this point, the locally compiled libc.so.1.9 should really be 1.10, and
+ you have to recompile everything you originally compiled, anyway.
+ 
+ So, stick with libc.so.1.8.x++.  Just be aware that if you compile on a
+ machine with this new shared library, and you use the res_ routines
+ directly without -lresolv (uncool, see above) you will not be able to
+ take it to a previous stock SunOS without a few problems.
+ 
+ 
+ * Compiling with gcc
+ 
+ Compiling resolv with gcc is highly preferably is it understands the
+ concept of making read only data shared.  Sun's 4.1.3 cc doesn't (simply
+ to make read-only strings shared takes some nasty effort).
+ 
+ Currently (4.9.2 resolv and gcc 2.5.8), the resolv library uses does not
+ create any special gcc references.  Specifically, there are no
+ unresolved references in the resolv objects, that are present in
+ libgcc.a.  This means that even if you compile with gcc, the objects
+ created may be linked with any compiler.  All is cool, use gcc.
+ 
+ SHOULD THIS CHANGE (in a new release of gcc, or resolv - not likely to
+ change, but possible), you can still use gcc and create objects usable
+ by any compiler.  You will need to add libgcc.a to the shared library
+ link line (before -ldl).
+ 
