Bug#590563: dpkg-gensymbols can't handle biarch libs with different symbol names
Hi, On Tue, 27 Jul 2010, Matthias Klose wrote: A C++ library like libstdc++ built for 32bit and 64bit in the same source can have different symbol names in the 32bit and 64bit builds, and different symbol names on different architectures. The current `arch' attribute only allows selection of the architecture. dpkg should allow the biarch architecture names in the `arch' attribute and do the right thing when processing libs, e.g. arch=i386 should trigger for a symbol in a 32bit library for a build on amd64. Modestas, do you feel like providing a fix for this one? Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590563: dpkg-gensymbols can't handle biarch libs with different symbol names
severity 590563 wishlist thanks Hello, On trečiadienis 28 Liepa 2010 09:24:31 Raphael Hertzog wrote: On Tue, 27 Jul 2010, Matthias Klose wrote: A C++ library like libstdc++ built for 32bit and 64bit in the same source can have different symbol names in the 32bit and 64bit builds, and different symbol names on different architectures. The current `arch' attribute only allows selection of the architecture. 'arch' tag allows selection of multiple architectures (e.g. anything you would use in Build-Depends [] field). You can list both i386 and amd64 as 'arch=i386 amd64'. dpkg should allow the biarch architecture names in the `arch' attribute and do the right thing when processing libs, e.g. arch=i386 should trigger for a symbol in a 32bit library for a build on amd64. It is not really easy for me to understand this issue without any background on libstdc++ packaging. Can you give a real world example of the problem you want to solve with your proposal? 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? Modestas, do you feel like providing a fix for this one? 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`. 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. 3) biarch will go away eventually and I don't think this new tag would be useful for proper multiarch (or in other words, there will be better more standard ways to detect multiarch package). 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. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#590563: dpkg-gensymbols can't handle biarch libs with different symbol names
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. 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. 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. 3) biarch will go away eventually and I don't think this new tag would be useful for proper multiarch (or in other words, there will be better more standard ways to detect multiarch package). That's true. 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. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590563: dpkg-gensymbols can't handle biarch libs with different symbol names
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.
Bug#590563: dpkg-gensymbols can't handle biarch libs with different symbol names
On 28.07.2010 15:13, Modestas Vainius wrote: 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? that should work. are all of the required names supported? e.g. sparc64, ppc64, s390x, mips-newabi, mips64? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590563: dpkg-gensymbols can't handle biarch libs with different symbol names
Hello, On trečiadienis 28 Liepa 2010 16:17:30 Matthias Klose wrote: On 28.07.2010 15:13, Modestas Vainius wrote: 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? that should work. are all of the required names supported? e.g. sparc64, ppc64, s390x, mips-newabi, mips64? -a just makes dpkg-gensymbols think that host-arch is the one you specify in this option (with respect to arch tag and *.symbols.$arch files). If something works differently when `dpkg-gensymbols` is run on $arch and when `dpkg- gensymbols -a$arch` is run on different arch than $arch, I consider this a bug which you should report. -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#590563: dpkg-gensymbols can't handle biarch libs with different symbol names
Hi, On Wed, 28 Jul 2010, Modestas Vainius wrote: 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. Yes, dpkg-shlibdeps respect the ELF format. It will look for a library with the same ELF format than the binary analyzed. 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? Indeed, it looks like a good solution as well. Matthias, are you satisfied with this suggestion? If yes, please close this bug report. Cheers, -- Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693] Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590563: dpkg-gensymbols can't handle biarch libs with different symbol names
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? Indeed, it looks like a good solution as well. Matthias, are you satisfied with this suggestion? just the remaining question: which are the architecture names for ppc64, mips-newabi and mips64? I see that I can invent my own ones, but I would prefer to use ones which are probably already used in other places. Matthias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590563: dpkg-gensymbols can't handle biarch libs with different symbol names
On Wed, 2010-07-28 at 23:15:33 +0200, Matthias Klose wrote: just the remaining question: which are the architecture names for ppc64, mips-newabi and mips64? I see that I can invent my own ones, but I would prefer to use ones which are probably already used in other places. ppc64 is a know architecture to dpkg, but it does not know about mips-newabi nor mips64. regards, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590563: dpkg-gensymbols can't handle biarch libs with different symbol names
Package: dpkg A C++ library like libstdc++ built for 32bit and 64bit in the same source can have different symbol names in the 32bit and 64bit builds, and different symbol names on different architectures. The current `arch' attribute only allows selection of the architecture. dpkg should allow the biarch architecture names in the `arch' attribute and do the right thing when processing libs, e.g. arch=i386 should trigger for a symbol in a 32bit library for a build on amd64. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
