home *** CD-ROM | disk | FTP | other *** search
/ PC-Online 1996 May / PCOnline_05_1996.bin / linux / source / n / bind / bind-4.001 / bind-4~ / bind-4.9.3-BETA9 / contrib / sunlibc / ISSUES < prev    next >
Text File  |  1994-06-06  |  8KB  |  166 lines
  1. - Dave Morrison <drmorris@mit.edu> - 2/3/94 -
  2. updates for 4.9.3 by Chris Davis <ckd@kei.com> 6 Jun 1994
  3.  
  4. Changes to the shared library setup have lots of little pitfalls and mines.
  5. This is an attempt to map the minefield, for those who feel they've
  6. noticed something that they think should be done another way.
  7.  
  8.  
  9. * What's shared, what's static
  10.  
  11. The purpose of these modifications to Sun's libc.so is to provide DNS
  12. lookup for gethostby* and if you desire, getnetby*.  This involves
  13. replacing the following SunOS libc routines.
  14.  
  15.     gethostbyname            getnetbyname
  16.     gethostbyaddr            getnetbyaddr
  17.     gethostent            getnetent
  18.     sethostent            setnetent
  19.     endhostent            endnetent
  20.  
  21. The routines use the res_* routines from the resolv library to get their
  22. information from DNS.  Because it is most convenient, all these objects
  23. are linked into the shared library, meaning they are linkable without
  24. using -lresolv.  Full details are given below, and unless you want to
  25. get into the nitty gritty, obey the following rule.
  26.  
  27. Anything which uses -lresolv rountines other than the stock OS routines
  28. above should link using -lresolv.
  29.  
  30. The symptom of not obeying this rule is finding that _res is unresolved
  31. at link time.
  32.  
  33.  
  34. * global variable collision
  35.  
  36. The global variable _res is particularly troublesome.  Any executables
  37. which was compiled with -lresolv before the shared library was installed
  38. has in it _res staticly compiled in as a global data structure.
  39. Unfortunately, the resolv library in 4.9.2 BIND has a global variable
  40. _res, and it is defined slightly differently.  At run time, when the
  41. shared libraries are loaded up, some linking is done at runtine.  The
  42. runtime linker, notices that _res is staticly defined and does not link
  43. in the dynamic version.  This means that if the shared libc calls ever
  44. call called from this executable, they would overwrite the static
  45. version.  Since the static version is a smaller data structure, this
  46. could overwrite bits of memory.  Not good.  It turns out the worst case
  47. is not a likely scenario, but I'd rather be safe then sorry.
  48.  
  49. This is why the Makefile for contrib/sunlibc does -D_res=_res_shlib.
  50. The collision is removed.  This means that _res is not accessable as a
  51. global variable in the shared libc library.  To compile a program which
  52. accesses _res directly, libresolv must linked in staticly.
  53.  
  54. This would not be a problem if you could recompile any code which used
  55. libresolv.  This would mean recompiling some of SunOS and perhaps other
  56. vendor code if you've obtained additional software.  Since people don't
  57. generally have the source to everything on the machine, this isn't a
  58. viable option except for Sun and miscellaneous wizards.
  59.  
  60.  
  61. * Having named and tools linked with a shared libc.
  62.  
  63. It is very tempting and almost doable to compiled the entire bind
  64. distribution with a resolv in a shared libc.  There are dangers
  65. associated with doing this.  First, there's the global variable
  66. collision problem mentioned above.  Second, there's a problem of
  67. maintaining the the shared library version control.
  68.  
  69. People have a tendency to copy tools like dig or the named server from
  70. machine to machine.  If the new shared library (the one with *this*
  71. distributions resolv) is not present on the machines to which these
  72. goodies are copied TO, the user will be getting SUN'S copy of resolv.
  73. This could cause you to lose most heinously, and you will spend DAYS if
  74. not WEEKS trying to figure out what the problem is.  It's debatable if
  75. there's even a performance improvement by doing the sharing.  Compare
  76. that to the debugging and frustration time you are going to spend.
  77.  
  78. You also will need to replace libc everywhere when a new release when
  79. new releases come out.  This isn't as big an issue for a production
  80. release of bind, but for the alpha test team, it means a few less things
  81. to worry about, when there is already plenty to worry about.
  82.  
  83. Again, if you could recompile the machine, there wouldn't be a problem.
  84. Vendors should release the tools and server shared, as they already have
  85. the assurance that there is a standard libc, and users may want to
  86. handle some problem routines by relinking the shared library.
  87.  
  88.  
  89. * shared archives
  90.  
  91. In addition to a shared object (the libc.so files) which contain the
  92. executable libc code, there is also a shared archive (the libc.sa
  93. files).   The shared archive contains global initialized data.  When a
  94. program is linked, if it accesses any of this global initialized data,
  95. that data is included from the shared archive in the final executable.
  96. Some examples include errno (intialzed to zero), the ctype.h tables,
  97. sys_errlist, and _iob for stdio.
  98.  
  99. If this data is not accessable from a shared archive, but is accessable
  100. from the shared object (e.g. no libc.sa.x.y.z exists for libc.so.x.y.z),
  101. the shared object copy will be used, but not linked into the executable.
  102. This results in a performance hit for executables which used that data.
  103. Sun's documentation claims this to be possibly degrading to the system
  104. as a whole on a heavily used library.  I have yet to observe anything
  105. besides a slight (max 10%) performance hit.
  106.  
  107. This is why it is important to copy+ranlib the old libc.sa.a.b.c, when
  108. creating a new libc.so.x.y.z.  Sun's instructions in building a new
  109. shared libc (shlib.etc package or patch) neglect to mention this.
  110.  
  111. There are 5 instances of global initialized data in -lresolv.  They are
  112. _res (renamed to _res_shlib), _res_resultcodes, _res_opcodes, h_errlist,
  113. and h_nerr.  In principle, they should be added to libc.sa.x.y.z.
  114. However, long as they are never referenced, it does not matter that they
  115. are not there.  Programs which use these variables should link with
  116. -lresolv to get the static version, and the problem is solved.
  117.  
  118. The reason for not including them in the shared archive, is that there
  119. is a potential problem in that if this global data ever changed, as it
  120. might in a future bind release, the MAJOR version of the library should
  121. change.  By using the static versions with -lresolv, you allow yourself
  122. the option to upgrade the -lresolv code without major fuss.
  123.  
  124. Update: in 4.9.3, the resolver library no longer uses initialized static
  125. data, so this should never be a problem again.  (You should still copy and
  126. re-ranlib the Sun-supplied libc.sa, however.)
  127.  
  128.  
  129. * shared library revision numbers
  130.  
  131. Technically, the shared library changes are sufficient enough to warrent
  132. a minor revision change.  On SunOS 4.1.3, this would mean the shared
  133. library should be numbered libc.so.1.9.  However, if Sun could used that
  134. in another SunOS release, and you went to upgrade, suddenly there would
  135. be two libc.so.1.9's.  Programs would be compiled to use "libc.so.1.9"
  136. and would be no distinction between those which want to use the SunOS
  137. libc.so.1.9 and those which want the locally compiled libc.so.1.9.  At
  138. this point, the locally compiled libc.so.1.9 should really be 1.10, and
  139. you have to recompile everything you originally compiled, anyway.
  140.  
  141. So, stick with libc.so.1.8.x++.  Just be aware that if you compile on a
  142. machine with this new shared library, and you use the res_ routines
  143. directly without -lresolv (uncool, see above) you will not be able to
  144. take it to a previous stock SunOS without a few problems.
  145.  
  146. Update: SunOS 4.1.3_U1 (aka Solaris 1.1.1) does, in fact, use libc.so.1.9.
  147.  
  148.  
  149. * Compiling with gcc
  150.  
  151. Compiling resolv with gcc is highly preferably is it understands the
  152. concept of making read only data shared.  Sun's 4.1.3 cc doesn't (simply
  153. to make read-only strings shared takes some nasty effort).
  154.  
  155. Currently (4.9.2 resolv and gcc 2.5.8), the resolv library uses does not
  156. create any special gcc references.  Specifically, there are no
  157. unresolved references in the resolv objects, that are present in
  158. libgcc.a.  This means that even if you compile with gcc, the objects
  159. created may be linked with any compiler.  All is cool, use gcc.
  160.  
  161. SHOULD THIS CHANGE (in a new release of gcc, or resolv - not likely to
  162. change, but possible), you can still use gcc and create objects usable
  163. by any compiler.  You will need to add libgcc.a to the shared library
  164. link line (before -ldl).
  165.  
  166.