Re: dpkg symbol dependencies
Hi all,
I'm porting Debian to Interix, see http://debian-interix.net/
On interix there is no ELF file format, but PE-COFF instead.
Some problems arised for me because of that with the new symbol
dependency stuff.
For reference here my previous mail to Raphael:
In the build log above you can find several warnings about failed
symbol readings. These warnings itself are understandable, as
objdump on Interix has a different output format than on Linux, as
Interix uses PE-COFF instead of ELF. While this may be patched in,
I'm currently asking why the old behaviour is now broken, and no
dependencies are calculated at all. Only warnings were printed, so
I would not expect things to be broken.
In general I like the idea of symbol dependencies, and I would like
to implement it for Debian/Interix, too. 3 problems I currently see
for that:
1. Interix ld doesn't support versioned symbols currently, this may
change soon, however. (shouldn't matter hopefully, but I can't test
with those)
2. On Interix PE-COFF all symbols have a preceding "_", while ELF
has C symbols and asm symbols equal. While I could change this in a
rebuilt gcc, this seems to be PE-COFF standard and I don't want to
change it for compatibility reasons with other compilers.
3. PE-COFF doesn't have weak symbols. It has only weak aliases.
I.e. you need a strong symbol and give it a weak alias. This then
works like a weak symbol on ELF, but you can't have a weak symbol
without a strong one.
The questions now are:
1. What do I need to change to get the old behaviour back?
2. How do symbol dependencies work? Supposedly these fields need to
be filled in correctly in Dpkg::Shlibs::Objdump.pm:
name,version,section,dynamic,debug,type,weak,
local,global,visibility,hidden,defined
Which of these are really needed, and which may be set to
default/unknown values so
that basic symbol dependencies still work?
(No versioned symbols are currently needed.)
3. Would you be available for further questions on this topic, not
the Interix specifics, of course, but for implementation problems
resulting from differences between ELF and PE-COFF?
On Sat, 12 Apr 2008, Raphael Hertzog wrote:
On Sat, 12 Apr 2008, Martin Koeppe wrote:
Hi Raphael,
Hi,
I built the new dpkg twice, so that it got built with itself. The second
build log is here:
http://debian-interix.net/debian-interix/pool/unreleased35/main/d/dpkg/dpkg_1.14.16.6-0+interix.1_20080409-2338.gz
There you can see that no shlibdeps have been created.
At least the Depends: on ms-libc3.5 is missing.
I have no idea why the dependency is missing. Please add a "-v" to
dpkg-shlibdeps call (dh_shlibdeps -- -v) to get more information about
what it's doing. Maybe we'll have a better hint then...
Symbols based dependencies are only used when such dependencies are
provided and obviously your platform doesn't provide any. It should still
use shlibs as usual.
I now found out why it didn't got the Depends: right: The parsing of
objdump output for NEEDED libs must have been changed. On linux the
header is "Dynamic Section" while on interix it is "Dynamic (.so) Section".
New diff and buildlog is here:
http://debian-interix.net/debian-interix/pool/unreleased35/main/d/dpkg/dpkg_1.14.16.6-0+interix.2.diff.gz
http://debian-interix.net/debian-interix/pool/unreleased35/main/d/dpkg/dpkg_1.14.16.6-0+interix.2_20080413-2230.gz
[ Looking further... ]
I see a debian/shlibs.default file. This one is not used during the
build... does it exist as "/etc/dpkg/shlibs.default" during the build?
If not, then the problem is here... debian/shlibs.local is the way to
provide such shlibs for a single build.
This is special for interix. I cannot package the libc because of
licensing issues. So I made an empty dummy package for it. Maybe I
should transfer the shlibs entries to this package instead of
including them in /etc/dpkg/shlibs.default ...
2. How do symbol dependencies work? Supposedly these fields need to be
filled in correctly in Dpkg::Shlibs::Objdump.pm:
name,version,section,dynamic,debug,type,weak,
local,global,visibility,hidden,defined
Which of these are really needed, and which may be set to
default/unknown values so that basic symbol dependencies still work?
(No versioned symbols are currently needed.)
I've built this system for ELF binaries only, it's difficult to say which
of those are needed or not without having an understanding of PE-COFF...
which I don't have.
name is needed obviously
version can be left empty if your don't have symbol versioniong
defined is important, defined=0 is a symbol used, defined=1 is a symbol
exported...
dynamic / local / defined are used only to select symbols we care about
Clearly most of the work is Dpkg::Shlibs::Objdump. We don't care much
of what attributes symbols have but we care of the functions used in that
module. And also look at merge_symbols() in Dpkg/Shlibs/SymbolFile.pm,
this functions interacts with Objdump.pm.
I now have successfully adapted Objdump.pm for interix to work
basically, see diff. Thanks for the info. I had to make one change
which I don't fully understand:
With add_dynamic_symbol($symbol) a symbol is added, with empty
version, if it doesn't have a version. But then locate_symbol() is
called, but the symbol name to locate has a dummy version "@Base"
attached to it. Because of this, on interix with my patch above the
symbol can't be located correctly. I therefore decided to always
attach this dummy version "Base" from the beginning, and it then
works, but I think this is not the right way of doing it.
Any help would be welcome.
3. Would you be available for further questions on this topic, not the
Interix specifics, of course, but for implementation problems resulting
from differences between ELF and PE-COFF?
Maybe... you could use debian-dpkg@lists.debian.org for your questions
so that other can answer too. :)
Martin
Reply to: