On Thu, 06 Dec 2007, Colin Watson wrote:
Perhaps dpkg-shlibdeps should ignore libm.so.6 for binaries also linked
against libstdc++.so.*?
Yeah, I agree. A fix has been committed to the git repo.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
Package: dpkg-dev
Version: 1.14.12
Looking at symbol files for the libstdc++ packages built from GCC I
end up with 4MB symbol information just for libstdc++:
$ ls -l
total 4036
-rw-r--r-- 1 doko doko 212085 Dec 9 15:34 lib32stdc++6.symbols.amd64
-rw-r--r-- 1 doko doko 213295 Dec 9 15:34
Raphael Hertzog wrote:
On Sun, 09 Dec 2007, Neil Williams wrote:
Emdebian cannot build, patch or test every permutation of toolchain that
people need so this isn't about us patching locally, it is about
lowering the barrier to cross building on Debian by not forcing every
user to patch
Processing commands for [EMAIL PROTECTED]:
# Automatically generated email from bts, devscripts version 2.10.11
package dpkg dpkg-dev dselect
Ignoring bugs not assigned to: dselect dpkg-dev dpkg
tags 455260 + pending
Bug#455260: dpkg-gensymbols: symbol files cannot be shared across packages
On Sun, 09 Dec 2007, Neil Williams wrote:
I'm ok with a
supplementary specific check for building of a cross-compiler, but not
with a generic check like testing the ARCH environment variable.
OK, I have a solution for that - replace $ARCH with $GCC_TARGET.
I've tested with this change
Raphael Hertzog wrote:
On Sun, 09 Dec 2007, Neil Williams wrote:
I'm ok with a
supplementary specific check for building of a cross-compiler, but not
with a generic check like testing the ARCH environment variable.
OK, I have a solution for that - replace $ARCH with $GCC_TARGET.
I've tested
6 matches
Mail list logo
