Hello, On trečiadienis 28 Liepa 2010 15:08:54 Raphael Hertzog wrote: > On Wed, 28 Jul 2010, Modestas Vainius wrote: > > Maybe you want to be able use the same symbol file for both libstdc++6 on > > i386 and lib32stdc++6 on amd64 (because in theory their symbol sets > > should be identical AFAIU) and that's what is this bug actually about? > > AFAIU, that's right. He has a different symbols in libstdc++ for i386 and > amd64 and he uses a symbols file with entries like this: > (arch=i386)32_bit_symbol > (arch=amd64)64_bit_symbol > > He would like the system to use 64_bit_symbol when the library analyzed is > compiled for amd64 even when the system is i386.
Ok, I have a proposal for that. Read below. > > As far as I understand, the proposed solution is to detect architecture > > from the binary file itself (by reading ELF header). I don't feel like > > changing arch= semantics for this because: > > > > 1) reading ELF/other binary format is less portable than > > `dpkg-architecture - qDEB_HOST_ARCH`. > > Why do you believe that? I don't know of many cases where the name of an > ELF binary format got changed... but I haven't studied the question. That > said we have no official mapping between ELF format and Debian > architecture and the mapping might not always be 1 to 1. So maybe changing > the meaning of the arch tag is not the best solution. It's an additional complexity. Thinking more about it, does dpkg-shlibdeps compare ELF architectures when looking for the library the binary links to? ldconfig does differentiate on the arch level as well, not just soname. > > 2) scope of new semantics would be per object rather than per symbol file > > (in theory symbol file may contain objects compiled for different > > arches) which may only add more confusion in the end. > > But it looks like the correct behaviour IMO. Or at least a logical > behaviour that we ought to support. My original idea behind arch tag was to avoid #include "foobar.common" when only a few symbols differ. In addition, it is much easier to edit/track a single file and dpkg-gensymbols patches always apply against symbol files without #includes. > > Therefore I would prefer to avoid this 'binarch' (or whatever we would > > call it) tag. However, I may try to help Matthias to find an alternative > > solution to his particular issue as soon as I know more about it. > > I don't see any solution that does not involve duplicating the list of > symbols in multiple files. So there is a (very easy) solution for that. I added -a option to dpkg- gensymbols 1.15.6. I must admit that it was for different purpose but it should work very nicely in this context. So: $ dpkg-gensymbols -plib32std++6 -ai386 ... or $ dh_makeshlibs -plib32std++6 -- -ai386 Biarch is a hack, but maintainer is in control of this hack and probably fiddle with a couple of similar options. So I don't think that using -a option this way is a big problem, is it? -- Modestas Vainius <mo...@debian.org>
signature.asc
Description: This is a digitally signed message part.
