Dependencies on shared libs, news and difference between archs
Hi,
following the last post I made changes to my dpkg branch to not include the
arch-specific symbols created by gcc on libraries in order to have as many
common symbols files as possible. See the current "black list" on top of
this file:
http://git.debian.org/?p=dpkg/dpkg.git;a=blob;f=scripts/Dpkg/Shlibs/SymbolFile.pm;h=051e7eb947fbd1febbef88f90bf5dd44f084436f;hb=40ed7b0685cfe9160dfd3a34b7babe3e604c8d7c
I also added an include mechanism to be able to share information between
various symbols files.
Everything is available in the git branch:
http://git.debian.org/?p=dpkg/dpkg.git;a=shortlog;h=dpkg-shlibdeps-buxy
I think my work is mostly ready for unstable as it is. The last step is to
convince Guillem Jover, the main dpkg maintainer, to merge that in the
master branch. He believes that supporting odd cases encourages bad
practice on library management. I don't think so. On the contrary I'd like
to promote sane library management and I made some efforts in the included
documentation to promote that. Feel free to check by yourself in the
current version of dpkg-gensymbols's manpage:
http://git.debian.org/?p=dpkg/dpkg.git;a=blob;f=man/dpkg-gensymbols.1;h=8bd39979599ba9580fa164cdddf73039a0e6c011;hb=40ed7b0685cfe9160dfd3a34b7babe3e604c8d7c
Your comments are welcome of course.
Some more in-depth analysis of my latest findings
-------------------------------------------------
Among 2195 packages with shlibs files, 1347 have the same symbols file across all
architectures, and on the 848 packages where we have differences, 354 of
them have differing versions in various architectures in unstable (so the
difference might be unrelated to the architecture, but simply because the
code base differs). That still lives 494 packages which are in sync in
unstable and who have different set of symbols on different architectures.
Many of them are C++ packages but not all.
1/ First example, libatspi1.0-0 on sparc lacks many cspi_* symbols that all
other architectures have. Checking the source you can find this:
#libtool option to strip symbols starting with cspi
#
LIBTOOL_EXPORT_OPTIONS='-export-symbols-regex "^[[^cspi]].*"'
AC_SUBST(LIBTOOL_EXPORT_OPTIONS)
So it looks like the binary on sparc is fine, but all other binaries
were built with a libtool version that doesn't respect this directive.
2/ Second example, libconfig0 has a supplementary symbols
_PROCEDURE_LINKAGE_TABLE_ on sparc and alpha. I don't know where it comes from.
Is this a internal symbols that I missed?
On powerpc it has _SDA_BASE_ and _SDA2_BASE_. Same question as above.
On amd64 it has lost the "_DYNAMIC" symbol. Same question as above.
Quick googling led me to believe that I can/should exclude all those. If
someone can confirm, it would be great.
3/ Third example, libgci0/0.9.5.dfsg-2 on mipsel has a "0x62" global symbol:
009b6870 g D *ABS* 009b6170 0x62
It also has a 0x63 symbol but this one is marked local so is already discarded.
009b4cb0 l D *ABS* 009b6580 0x63
I have no idea where they come from and what they're used for. Can someone
from debian-mips enlighten me?
4/ Fourth example, libgarlic2006 on alpha has many supplementary symbols ending
in "___elabs". No idea what the root difference is.
5/ Fifth example, it looks like 64 bits ports tend to have differences in common
like on libneon2.6 where various functions suffixed by "64" disappear on those
arches (ne_get_range64, ne_set_request_body_fd64, ne_set_request_body_provider64).
If you want to investigate a bit more on differences, you can grab that file:
http://users.alioth.debian.org/~hertzog/comparison.tar.bz2 (139 Mb)
the "result-compare" contain the information about differences on all packages.
You can then lookup the difference manually by diffing files in result/sid/*.symbols.*
About C++ libraries
-------------------
Can anyone explain me why there's randomness in symbol mangling? If I compare
the symbols file of gnunet-qt for example I get differences like this between
i386 and alpha:
@@ -67,10 +67,10 @@
_ZTV13GPluginLoader@Base 0.7.1-1
_ZTV6GEvent@Base 0.7.1-1
_ZTV7GPlugin@Base 0.7.1-1
- _ZThn8_N11GTextEditorD0Ev@Base 0.7.1-1
- _ZThn8_N11GTextEditorD1Ev@Base 0.7.1-1
- _ZThn8_N7GPluginD0Ev@Base 0.7.1-1
- _ZThn8_N7GPluginD1Ev@Base 0.7.1-1
+ _ZThn16_N11GTextEditorD0Ev@Base 0.7.1-1
+ _ZThn16_N11GTextEditorD1Ev@Base 0.7.1-1
+ _ZThn16_N7GPluginD0Ev@Base 0.7.1-1
+ _ZThn16_N7GPluginD1Ev@Base 0.7.1-1
libgnunetqtmodule_about.so.1 gnunet-qt #MINVER#
_ZN11Ui_WndAbout7setupUiEP7QWidget@Base 0.7.1-1
_ZN12GAboutPlugin11linkHandlerERK4QUrl@Base 0.7.1-1
But if you check what it refers too, they refer to the same symbol:
$ c++filt _ZThn8_N11GTextEditorD0Ev
non-virtual thunk to GTextEditor::~GTextEditor()
$ c++filt _ZThn16_N11GTextEditorD0Ev
non-virtual thunk to GTextEditor::~GTextEditor()
And if I convert the symbols files with c++filt then both files are identical.
Thanks for your input!
Cheers,
PS: For those who didn't follow the whole story, I'm speaking here
of that project:
http://wiki.debian.org/Projects/ImprovedDpkgShlibdeps
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Reply to: