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.
