[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

linker related changes for wheezy



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Two linker-related changes were recently made in the toolchain in unstable,
which may cause build failures. The BTS also contains reports relating to other
linker-related bugs which I recommend you investigate

 - binutils 2.21 linker scripts:

     Linker script expression evaluation is somewhat more sane.  This may
     break scripts that depend on quirks of the old expression evaluation.

   This is PR ld/12356, see the ld info manual, Linker Scripts /
   Expression Section.  Only packages using linker scripts may be
   affected.

 - Both gcc-4.4 and gcc-4.5 pass --no-copy-dt-needed-entries to the linker.

The latter change is described in [1] (section [2]).  To summarize: If a library
symbol is directly used by an object without explicitly linking this library,
the link step now fails.  The fix is to pass the library explictly to the
linker.  Rationale for this change:

 - Correctness.  Symbols should not be resolved unintentionally.

 - Robustness.  If a library drops a dependency on another library
   with the involved symbol, then the application still using this
   symbol will fail to build.

 - Buildability with the gold linker.  Gold defaults to
   --no-copy-dt-needed-entries.  Using gold as the default linker
   is not a goal for wheezy, but buildability of the archive with
   gold is required as a prerequisite.


Default to --no-copy-dt-needed-entries
- --------------------------------------

Bug reports are filed in [3]. Please see [2] how to tag new bug reports.

Build logs for failed builds usually have a comprehensive error message.  If you
only see the error message, but not the linker command line, please file an
extra bug report for the package not to hide information in the build log.

  gcc -o foo foo.o
  /usr/bin/ld: foo.o: undefined reference to symbol 'bar_symbol'
  /usr/bin/ld: note: 'bar_symbol' is defined in DSO /usr/lib/libbar.so.1 so try
adding it to the linker command line
  /usr/lib/libbar.so.1: could not read symbols: Invalid operation collect2: ld
returned 1 exit status

There are two cases to differentiate:

 - "foo.o: undefined reference to symbol 'bar_symbol'", the symbol is
   referenced in an object file on the command line.  The fix is to
   add the library to the link command, like "gcc -o foo foo.o -lbar"

 - "libbaz.la: undefined reference to symbol 'bar_symbol'", the symbol
   is referenced in a local/convenience/system library.  The fix is to
   link the library against the library defining the symbol, linking
   the app against the library would just work around the issue.
   In many cases you'll already see dpkg-shlibdeps complaining about
   undefined symbols in libraries.  See [3] for a list of known issues.

Changes may require changing/patching Makefile.am and configure.* files.


Undefined symbols in shared libraries
- -------------------------------------

Some shared libraries do not link with libraries which they use. This may result
in build failures with the --no-copy-dt-needed-entries default.

dpkg-shlibdeps warns about these in the form:

  dpkg-shlibdeps: warning: symbol <symbol> used by debian/<foo>/usr/lib/<libfoo>
found in none of the libraries.

These symbols should be resolved.  There may be exceptions why there are
unresolved symbols such as the one mentioned in bug #558872.

A list of issues can be found at [3]. Please tag new issues accordingly.


Fix build failures with ld --as-needed
- --------------------------------------

[Note this is not turned on by default]

Many packages fail to build when the linker is passed --as-needed as the
default.  These issues are collected at [4] (please tag new issues accordingly).
 The vast majority of these kind of failures are some assumptions about link
order with the GNU linker (ld), which may not be fulfilled with other linkers.
Issues are of the form:

  gcc -o foo -lbar foo.o

When processing the command line, libbar isn't needed to fulfil any
dependencies, so it is ignored, and the link step will fail when trying to
resolve symbols found in foo.o. The fix is to pass object files before libraries
on the command line:

  gcc -o foo foo.o -lbar

A common mistake with automake is to add libraries to the various LDFLAGS
macros.  If you need to link a program with a library, add this library to one
of the LDADD macros, if you need to link a library with a library, add to one of
the LIBADD macros.  For tracking dependencies with local libraries, you may need
add the library to one of the DEPENDENCIES macros.  See the automake manual for
more details.


Please feel free to clarify the wiki page at [1], and make sure to tag new bug
reports according to the wiki page.

Thanks, Matthias


[1] http://wiki.debian.org/ToolChain/DSOLinking
[2]
http://wiki.debian.org/ToolChain/DSOLinking#Notresolvingsymbolsinindirectdependentsharedlibraries
[3] http://wiki.debian.org/ToolChain/DSOLinking#Unresolvedsymbolsinsharedlibraries
[4] http://wiki.debian.org/ToolChain/DSOLinking#Onlylinkwithneededlibraries

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1qdSAACgkQStlRaw+TLJx0VwCgnnqsBLtq5dQrzY3nx9Y/00n/
2DkAoJyM4kkZMUPZjrU1leRxd1P9Y2lL
=jL9o
-----END PGP SIGNATURE-----


Reply to: