mail/deplibs.html

   1 <html>
   2 <head>
   3 <title>Libtool Inter-library Dependencies</title>
   4 <body bgcolor="#ffffff">
   5 <center><h1><img src="/graphics/libtool.gif" width=477 height=192
   6  alt="Libtool"></h1></center>
   7
   8 <h1>Inter-library Dependencies</h1>
   9
  10 <p>About twice a week, for the last five weeks, I've been receiving
  11 bug reports which tell me that libtool's inter-library dependency
  12 handling is broken.
  13
  14 <p>I know.  I broke it intentionally, until I have the time to fix it
  15 myself, or somebody else takes the time to help me with it.
  16
  17 <p>These same people often give me a simple one-line patch which
  18 re-enables my old, simplistic inter-library dependencies, but nobody
  19 seems to want to test things thoroughly and come up with a real
  20 solution.
  21
  22 <p>If you don't care about the history, and you just want to help me
  23 out, jump to <a href="#solution">the bottom of this document</a>.
  24
  25 <h2>Background</h2>
  26
  27 <p>Libtool's basic premise is to make static and shared libraries
  28 behave the same way from a programmer's point of view.  This allows
  29 users to build a libtoolized package with or without shared libraries,
  30 determined at configuration time.  It does this by using a
  31 <dfn>libtool object</dfn> (<samp>.lo</samp>) and <dfn>libtool
  32 archive</dfn> (<samp>.la</samp>) abstraction, so that the package
  33 maintainer can use libtool to operate on these files without making
  34 any assumptions about their underlying representation.
  35
  36 <p>For the most part, this abstraction works well, and has made
  37 libtool as popular as it is today.  Without this abstraction, it would
  38 be significantly harder to port libtool to new platforms.
  39
  40 <p>Unfortunately, what this abstraction has also done is reveal some
  41 fundamental inconsistencies with most shared library implementations.
  42 Every shared library implementation works well for `hello world'-type
  43 examples, but very few are robust and well-designed so that libtool
  44 doesn't need special tricks in order to build correct, featureful
  45 shared libraries.
  46
  47 <p>Providing inter-library dependencies is one feature that has
  48 revealed these kinds of inconsistencies.
  49
  50 <h2>The problem</h2>
  51
  52 <p>My original inter-library dependency code received rigourous testing
  53 in beta releases of <a href="http://www.red-bean.com/guile/">GNU
  54 Guile</a>.  As soon as the Guile people started using my code, I
  55 received a flood of bug reports.  People were reporting that
  56 <samp>libguile</samp> (Guile's main shared library) was failing to
  57 link, or that programs linked against <samp>libguile</samp> were
  58 dumping core.
  59
  60 <p>Not good.
  61
  62 <p>The Guile people chased this bug down to the following scenario:
  63
  64 <ol>
  65 <li>The user's system has a static regexp library installed,
  66 <samp>librx.a</samp>.
  67
  68 <li>Guile's <samp>configure</samp> script detects that the
  69 <samp>-lrx</samp> linker option can be used to link in
  70 <samp>librx</samp>.
  71
  72 <li>When <samp>libguile</samp> is built, the <samp>-lrx</samp> linker
  73 option is used.
  74
  75 <li>Some linkers fail at this point, because they don't allow shared
  76 libraries to contain or depend on static libraries.
  77
  78 <li>If the linker didn't fail, then a few programs are linked against
  79 <samp>libguile</samp>.
  80
  81 <li>On some systems, these programs core dump because
  82 <samp>libguile</samp> is a shared library that contains non-PIC code
  83 (from <samp>librx</samp>).
  84 </ol>
  85
  86 <h2>The interim solution</h2>
  87
  88 <p>I needed some way to respond to these reports.  I saw my options (in
  89 order of my preference) as:
  90
  91 <ol>
  92 <li>Write code in <samp>ltmain.sh</samp> to prevent static libraries
  93 from appearing in inter-library dependencies.  This would take some
  94 work, but obviously is the best solution.
  95
  96 <li>Find the systems that fail, and turn off inter-library
  97 dependencies on only those systems.
  98
  99 <li>Force the package maintainer to guarantee that static libraries
 100 never appear in inter-library dependencies.
 101 </ol>
 102
 103 <p>I immediately vetoed the last solution, because that would violate
 104 the whole point of using libtool, and would cause a lot of people to
 105 waste time solving a problem that really should be fixed by libtool.
 106
 107 <p>I preferred the first solution, but at the time of the reports, I
 108 didn't see an obviously simple mechanism for detecting the difference
 109 between shared and static libraries.
 110
 111 <p>So, in the meantime, I tried turning off inter-library dependencies
 112 on the systems that failed.
 113
 114 <p>I quickly discovered, to my chagrin, that many systems fail.  So,
 115 it was be simpler for me to turn off <em>all</em> inter-library
 116 dependencies, then find out which systems work, rather than vice
 117 versa.
 118
 119 <h2>The current situation</h2>
 120
 121 <p>I've been busy trying to avoid bankruptcy.  It's been over three
 122 months since I first turned off inter-library dependencies, and I
 123 still haven't completed the solution I want.
 124
 125 <p>I've been gearing up for the 1.1 release of libtool, because there
 126 is a high demand for a stable public release.  So, I'm not going to
 127 introduce any destabilizing changes to the inter-library dependency
 128 code until after 1.1 is released.
 129
 130 <h2><a name="solution">The solution</a></h2>
 131
 132 <p>So, I want to tell you how you can help me solve the various
 133 dilemmas surrounding this issue:
 134
 135 <ol>
 136 <li>I need to find out more about the nature of the problems I ran
 137 into with Guile.  Unfortunately, I cannot reproduce them in simple
 138 tests on my own platform (i586-pc-linux-gnulibc1), even though I think
 139 they were reported here.  I need to find out which platforms already
 140 have perfect inter-library dependency support, how to work around the
 141 problem on other platforms, and, more importantly, exactly
 142 <em>why</em> some systems give me problems and others don't.
 143
 144 <p>On correct platforms, you can link <em>any</em> static library
 145 against a shared library via the <samp>-lNAME</samp> option without
 146 the linker complaining, then link a program against this library and
 147 run it without dumping core.  I know that this scenario will always
 148 work fine on the following systems:
 149
 150  <ul>
 151  <li>None reported yet.
 152  </ul>
 153
 154 <p>I also know that on some systems, you can create a shared library
 155 linked against a static one, but running programs linked against such
 156 a library will dump core:
 157
 158  <ul>
 159  <li>None reported yet.
 160  </ul>
 161
 162 <p>Finally, there are some systems which won't even allow you to link
 163 a shared library against a static one:
 164
 165  <ul>
 166  <li>Solaris 2.x
 167  </ul>
 168
 169 <li>Help me figure out a good, portable way to detect if a given
 170 <samp>-lNAME</samp> option refers to a shared library or not, since
 171 that is needed as a workaround to the problem.  Some suggestions so
 172 far have been:
 173
 174  <ul>
 175  <li>Link the library against a tiny test program, and:
 176
 177   <ul>
 178   <li>run <samp>ldd(1)</samp> on the test program and search for
 179   <samp>libNAME</samp> in the ldd output.
 180   <li>use the <samp>-verbose</samp> flag for GNU ld in order to see
 181   which library is actually linked.
 182   <li>run some sort of other program to determine if the library was
 183   dynamic.
 184   </ul>
 185
 186  <li>Track the <samp>-LDIR</samp> flags, do a search for the library,
 187  and then check whether it is shared by:
 188
 189   <ul>
 190   <li>using the <samp>file(1)</samp> program.
 191   <li>looking at its suffix.
 192   </ul>
 193  </ul>
 194
 195 <li>Contact any people you know who might be interested, get them to
 196 read this page, so that they can help me solve the problem.
 197
 198 <li>Send me money, so that I can devote more of my time to solving the
 199 problem.
 200 </ol>
 201
 202 <p>Thank you for your help, and have fun.
 203
 204 <hr>
 205 <a href="http://www.gimp.org/"><img src="/graphics/gfx_by_gimp.gif"
 206 align="right" border=0></a>
 207
 208 <p><a href="libtool.html">Back to the libtool home page.</a>
 209
 210 <address>
 211 Gordon Matzigkeit <a href="mailto:gord@profitpress.com">&lt;gord@profitpress.com&gt;</a>
 212 </address>
 213 </html>