VERSION.html 13 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267
  1. <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
  2. <html>
  3. <!-- This file documents the GNU linker LD
  4. (GNU Binutils)
  5. version 2.28.
  6. Copyright (C) 1991-2017 Free Software Foundation, Inc.
  7. Permission is granted to copy, distribute and/or modify this document
  8. under the terms of the GNU Free Documentation License, Version 1.3
  9. or any later version published by the Free Software Foundation;
  10. with no Invariant Sections, with no Front-Cover Texts, and with no
  11. Back-Cover Texts. A copy of the license is included in the
  12. section entitled "GNU Free Documentation License". -->
  13. <!-- Created by GNU Texinfo 5.2, http://www.gnu.org/software/texinfo/ -->
  14. <head>
  15. <title>LD: VERSION</title>
  16. <meta name="description" content="LD: VERSION">
  17. <meta name="keywords" content="LD: VERSION">
  18. <meta name="resource-type" content="document">
  19. <meta name="distribution" content="global">
  20. <meta name="Generator" content="makeinfo">
  21. <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  22. <link href="index.html#Top" rel="start" title="Top">
  23. <link href="LD-Index.html#LD-Index" rel="index" title="LD Index">
  24. <link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
  25. <link href="Scripts.html#Scripts" rel="up" title="Scripts">
  26. <link href="Expressions.html#Expressions" rel="next" title="Expressions">
  27. <link href="PHDRS.html#PHDRS" rel="prev" title="PHDRS">
  28. <style type="text/css">
  29. <!--
  30. a.summary-letter {text-decoration: none}
  31. blockquote.smallquotation {font-size: smaller}
  32. div.display {margin-left: 3.2em}
  33. div.example {margin-left: 3.2em}
  34. div.indentedblock {margin-left: 3.2em}
  35. div.lisp {margin-left: 3.2em}
  36. div.smalldisplay {margin-left: 3.2em}
  37. div.smallexample {margin-left: 3.2em}
  38. div.smallindentedblock {margin-left: 3.2em; font-size: smaller}
  39. div.smalllisp {margin-left: 3.2em}
  40. kbd {font-style:oblique}
  41. pre.display {font-family: inherit}
  42. pre.format {font-family: inherit}
  43. pre.menu-comment {font-family: serif}
  44. pre.menu-preformatted {font-family: serif}
  45. pre.smalldisplay {font-family: inherit; font-size: smaller}
  46. pre.smallexample {font-size: smaller}
  47. pre.smallformat {font-family: inherit; font-size: smaller}
  48. pre.smalllisp {font-size: smaller}
  49. span.nocodebreak {white-space:nowrap}
  50. span.nolinebreak {white-space:nowrap}
  51. span.roman {font-family:serif; font-weight:normal}
  52. span.sansserif {font-family:sans-serif; font-weight:normal}
  53. ul.no-bullet {list-style: none}
  54. -->
  55. </style>
  56. </head>
  57. <body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
  58. <a name="VERSION"></a>
  59. <div class="header">
  60. <p>
  61. Next: <a href="Expressions.html#Expressions" accesskey="n" rel="next">Expressions</a>, Previous: <a href="PHDRS.html#PHDRS" accesskey="p" rel="prev">PHDRS</a>, Up: <a href="Scripts.html#Scripts" accesskey="u" rel="up">Scripts</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="LD-Index.html#LD-Index" title="Index" rel="index">Index</a>]</p>
  62. </div>
  63. <hr>
  64. <a name="VERSION-Command"></a>
  65. <h3 class="section">3.9 VERSION Command</h3>
  66. <a name="index-VERSION-_007bscript-text_007d"></a>
  67. <a name="index-symbol-versions"></a>
  68. <a name="index-version-script"></a>
  69. <a name="index-versions-of-symbols"></a>
  70. <p>The linker supports symbol versions when using ELF. Symbol versions are
  71. only useful when using shared libraries. The dynamic linker can use
  72. symbol versions to select a specific version of a function when it runs
  73. a program that may have been linked against an earlier version of the
  74. shared library.
  75. </p>
  76. <p>You can include a version script directly in the main linker script, or
  77. you can supply the version script as an implicit linker script. You can
  78. also use the &lsquo;<samp>--version-script</samp>&rsquo; linker option.
  79. </p>
  80. <p>The syntax of the <code>VERSION</code> command is simply
  81. </p><div class="smallexample">
  82. <pre class="smallexample">VERSION { version-script-commands }
  83. </pre></div>
  84. <p>The format of the version script commands is identical to that used by
  85. Sun&rsquo;s linker in Solaris 2.5. The version script defines a tree of
  86. version nodes. You specify the node names and interdependencies in the
  87. version script. You can specify which symbols are bound to which
  88. version nodes, and you can reduce a specified set of symbols to local
  89. scope so that they are not globally visible outside of the shared
  90. library.
  91. </p>
  92. <p>The easiest way to demonstrate the version script language is with a few
  93. examples.
  94. </p>
  95. <div class="smallexample">
  96. <pre class="smallexample">VERS_1.1 {
  97. global:
  98. foo1;
  99. local:
  100. old*;
  101. original*;
  102. new*;
  103. };
  104. VERS_1.2 {
  105. foo2;
  106. } VERS_1.1;
  107. VERS_2.0 {
  108. bar1; bar2;
  109. extern &quot;C++&quot; {
  110. ns::*;
  111. &quot;f(int, double)&quot;;
  112. };
  113. } VERS_1.2;
  114. </pre></div>
  115. <p>This example version script defines three version nodes. The first
  116. version node defined is &lsquo;<samp>VERS_1.1</samp>&rsquo;; it has no other dependencies.
  117. The script binds the symbol &lsquo;<samp>foo1</samp>&rsquo; to &lsquo;<samp>VERS_1.1</samp>&rsquo;. It reduces
  118. a number of symbols to local scope so that they are not visible outside
  119. of the shared library; this is done using wildcard patterns, so that any
  120. symbol whose name begins with &lsquo;<samp>old</samp>&rsquo;, &lsquo;<samp>original</samp>&rsquo;, or &lsquo;<samp>new</samp>&rsquo;
  121. is matched. The wildcard patterns available are the same as those used
  122. in the shell when matching filenames (also known as &ldquo;globbing&rdquo;).
  123. However, if you specify the symbol name inside double quotes, then the
  124. name is treated as literal, rather than as a glob pattern.
  125. </p>
  126. <p>Next, the version script defines node &lsquo;<samp>VERS_1.2</samp>&rsquo;. This node
  127. depends upon &lsquo;<samp>VERS_1.1</samp>&rsquo;. The script binds the symbol &lsquo;<samp>foo2</samp>&rsquo;
  128. to the version node &lsquo;<samp>VERS_1.2</samp>&rsquo;.
  129. </p>
  130. <p>Finally, the version script defines node &lsquo;<samp>VERS_2.0</samp>&rsquo;. This node
  131. depends upon &lsquo;<samp>VERS_1.2</samp>&rsquo;. The scripts binds the symbols &lsquo;<samp>bar1</samp>&rsquo;
  132. and &lsquo;<samp>bar2</samp>&rsquo; are bound to the version node &lsquo;<samp>VERS_2.0</samp>&rsquo;.
  133. </p>
  134. <p>When the linker finds a symbol defined in a library which is not
  135. specifically bound to a version node, it will effectively bind it to an
  136. unspecified base version of the library. You can bind all otherwise
  137. unspecified symbols to a given version node by using &lsquo;<samp>global: *;</samp>&rsquo;
  138. somewhere in the version script. Note that it&rsquo;s slightly crazy to use
  139. wildcards in a global spec except on the last version node. Global
  140. wildcards elsewhere run the risk of accidentally adding symbols to the
  141. set exported for an old version. That&rsquo;s wrong since older versions
  142. ought to have a fixed set of symbols.
  143. </p>
  144. <p>The names of the version nodes have no specific meaning other than what
  145. they might suggest to the person reading them. The &lsquo;<samp>2.0</samp>&rsquo; version
  146. could just as well have appeared in between &lsquo;<samp>1.1</samp>&rsquo; and &lsquo;<samp>1.2</samp>&rsquo;.
  147. However, this would be a confusing way to write a version script.
  148. </p>
  149. <p>Node name can be omitted, provided it is the only version node
  150. in the version script. Such version script doesn&rsquo;t assign any versions to
  151. symbols, only selects which symbols will be globally visible out and which
  152. won&rsquo;t.
  153. </p>
  154. <div class="smallexample">
  155. <pre class="smallexample">{ global: foo; bar; local: *; };
  156. </pre></div>
  157. <p>When you link an application against a shared library that has versioned
  158. symbols, the application itself knows which version of each symbol it
  159. requires, and it also knows which version nodes it needs from each
  160. shared library it is linked against. Thus at runtime, the dynamic
  161. loader can make a quick check to make sure that the libraries you have
  162. linked against do in fact supply all of the version nodes that the
  163. application will need to resolve all of the dynamic symbols. In this
  164. way it is possible for the dynamic linker to know with certainty that
  165. all external symbols that it needs will be resolvable without having to
  166. search for each symbol reference.
  167. </p>
  168. <p>The symbol versioning is in effect a much more sophisticated way of
  169. doing minor version checking that SunOS does. The fundamental problem
  170. that is being addressed here is that typically references to external
  171. functions are bound on an as-needed basis, and are not all bound when
  172. the application starts up. If a shared library is out of date, a
  173. required interface may be missing; when the application tries to use
  174. that interface, it may suddenly and unexpectedly fail. With symbol
  175. versioning, the user will get a warning when they start their program if
  176. the libraries being used with the application are too old.
  177. </p>
  178. <p>There are several GNU extensions to Sun&rsquo;s versioning approach. The
  179. first of these is the ability to bind a symbol to a version node in the
  180. source file where the symbol is defined instead of in the versioning
  181. script. This was done mainly to reduce the burden on the library
  182. maintainer. You can do this by putting something like:
  183. </p><div class="smallexample">
  184. <pre class="smallexample">__asm__(&quot;.symver original_foo,foo@VERS_1.1&quot;);
  185. </pre></div>
  186. <p>in the C source file. This renames the function &lsquo;<samp>original_foo</samp>&rsquo; to
  187. be an alias for &lsquo;<samp>foo</samp>&rsquo; bound to the version node &lsquo;<samp>VERS_1.1</samp>&rsquo;.
  188. The &lsquo;<samp>local:</samp>&rsquo; directive can be used to prevent the symbol
  189. &lsquo;<samp>original_foo</samp>&rsquo; from being exported. A &lsquo;<samp>.symver</samp>&rsquo; directive
  190. takes precedence over a version script.
  191. </p>
  192. <p>The second GNU extension is to allow multiple versions of the same
  193. function to appear in a given shared library. In this way you can make
  194. an incompatible change to an interface without increasing the major
  195. version number of the shared library, while still allowing applications
  196. linked against the old interface to continue to function.
  197. </p>
  198. <p>To do this, you must use multiple &lsquo;<samp>.symver</samp>&rsquo; directives in the
  199. source file. Here is an example:
  200. </p>
  201. <div class="smallexample">
  202. <pre class="smallexample">__asm__(&quot;.symver original_foo,foo@&quot;);
  203. __asm__(&quot;.symver old_foo,foo@VERS_1.1&quot;);
  204. __asm__(&quot;.symver old_foo1,foo@VERS_1.2&quot;);
  205. __asm__(&quot;.symver new_foo,foo@@VERS_2.0&quot;);
  206. </pre></div>
  207. <p>In this example, &lsquo;<samp>foo@</samp>&rsquo; represents the symbol &lsquo;<samp>foo</samp>&rsquo; bound to the
  208. unspecified base version of the symbol. The source file that contains this
  209. example would define 4 C functions: &lsquo;<samp>original_foo</samp>&rsquo;, &lsquo;<samp>old_foo</samp>&rsquo;,
  210. &lsquo;<samp>old_foo1</samp>&rsquo;, and &lsquo;<samp>new_foo</samp>&rsquo;.
  211. </p>
  212. <p>When you have multiple definitions of a given symbol, there needs to be
  213. some way to specify a default version to which external references to
  214. this symbol will be bound. You can do this with the
  215. &lsquo;<samp>foo@@VERS_2.0</samp>&rsquo; type of &lsquo;<samp>.symver</samp>&rsquo; directive. You can only
  216. declare one version of a symbol as the default in this manner; otherwise
  217. you would effectively have multiple definitions of the same symbol.
  218. </p>
  219. <p>If you wish to bind a reference to a specific version of the symbol
  220. within the shared library, you can use the aliases of convenience
  221. (i.e., &lsquo;<samp>old_foo</samp>&rsquo;), or you can use the &lsquo;<samp>.symver</samp>&rsquo; directive to
  222. specifically bind to an external version of the function in question.
  223. </p>
  224. <p>You can also specify the language in the version script:
  225. </p>
  226. <div class="smallexample">
  227. <pre class="smallexample">VERSION extern &quot;lang&quot; { version-script-commands }
  228. </pre></div>
  229. <p>The supported &lsquo;<samp>lang</samp>&rsquo;s are &lsquo;<samp>C</samp>&rsquo;, &lsquo;<samp>C++</samp>&rsquo;, and &lsquo;<samp>Java</samp>&rsquo;.
  230. The linker will iterate over the list of symbols at the link time and
  231. demangle them according to &lsquo;<samp>lang</samp>&rsquo; before matching them to the
  232. patterns specified in &lsquo;<samp>version-script-commands</samp>&rsquo;. The default
  233. &lsquo;<samp>lang</samp>&rsquo; is &lsquo;<samp>C</samp>&rsquo;.
  234. </p>
  235. <p>Demangled names may contains spaces and other special characters. As
  236. described above, you can use a glob pattern to match demangled names,
  237. or you can use a double-quoted string to match the string exactly. In
  238. the latter case, be aware that minor differences (such as differing
  239. whitespace) between the version script and the demangler output will
  240. cause a mismatch. As the exact string generated by the demangler
  241. might change in the future, even if the mangled name does not, you
  242. should check that all of your version directives are behaving as you
  243. expect when you upgrade.
  244. </p>
  245. <hr>
  246. <div class="header">
  247. <p>
  248. Next: <a href="Expressions.html#Expressions" accesskey="n" rel="next">Expressions</a>, Previous: <a href="PHDRS.html#PHDRS" accesskey="p" rel="prev">PHDRS</a>, Up: <a href="Scripts.html#Scripts" accesskey="u" rel="up">Scripts</a> &nbsp; [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="LD-Index.html#LD-Index" title="Index" rel="index">Index</a>]</p>
  249. </div>
  250. </body>
  251. </html>