Bug#454616: dpkg-dev: g++ links -lm by default, and dpkg-shlibdeps complains
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 : http://www.ouaza.com/livre/admin-debian/
Bug#455260: dpkg-gensymbols: symbol files cannot be shared across packages
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 lib64stdc++6.symbols.i386 -rw-r--r-- 1 doko doko 247102 Dec 9 15:34 lib64stdc++6.symbols.powerpc -rw-r--r-- 1 doko doko 247202 Dec 9 15:34 lib64stdc++6.symbols.s390 -rw-r--r-- 1 doko doko 212099 Dec 9 15:34 lib64stdc++6.symbols.sparc -rw-r--r-- 1 doko doko 247100 Dec 9 15:33 libstdc++6.symbols.alpha -rw-r--r-- 1 doko doko 212097 Dec 9 15:30 libstdc++6.symbols.amd64 -rw-r--r-- 1 doko doko 212718 Dec 9 15:33 libstdc++6.symbols.arm -rw-r--r-- 1 doko doko 213211 Dec 9 15:33 libstdc++6.symbols.hppa -rw-r--r-- 1 doko doko 208188 Dec 9 15:34 libstdc++6.symbols.hurd-i386 -rw-r--r-- 1 doko doko 212083 Dec 9 15:29 libstdc++6.symbols.i386 -rw-r--r-- 1 doko doko 212097 Dec 9 15:33 libstdc++6.symbols.ia64 -rw-r--r-- 1 doko doko 208924 Dec 9 15:33 libstdc++6.symbols.m68k -rw-r--r-- 1 doko doko 212717 Dec 9 15:33 libstdc++6.symbols.mips -rw-r--r-- 1 doko doko 212717 Dec 9 15:33 libstdc++6.symbols.mipsel -rw-r--r-- 1 doko doko 247086 Dec 9 15:33 libstdc++6.symbols.powerpc -rw-r--r-- 1 doko doko 247086 Dec 9 15:33 libstdc++6.symbols.s390 -rw-r--r-- 1 doko doko 247086 Dec 9 15:33 libstdc++6.symbols.sparc Now trying to factor out some of the symbols (starting with the symbols introduced in the ldbl128 transition): $ fgrep -c LDBL * | grep -v ':0$' lib64stdc++6.symbols.powerpc:280 lib64stdc++6.symbols.s390:280 libstdc++6.symbols.alpha:280 libstdc++6.symbols.powerpc:280 libstdc++6.symbols.s390:280 libstdc++6.symbols.sparc:280 There are symbols which can be shared between two packages, but dpkg-gensymbols doesn't allow so: An included file must be a valid symbols file on its own. Thus you have to repeat the header line containing the SONAME of the library and the dependency template. Please allow this kind of symbol version sharing. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453267: tested patch
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 locally. This is why we are at the current impasse - too
many permutations.
Emdebian provides ready to use cross compiler. You can also provides
ready-to-use source packages for building other cross-compilers that are
not yet provided.
? You make it sound as trivial as providing a web page.
Emdebian provides a small selection of binary toolchains containing
selected cross compilers. Extending that range is a truly massive
undertaking that nobody has the time to do. There are no usable
toolchain-source packages anymore - unmaintainable - we can provide
simple scripts that can assist in building a variant toolchain but we do
not provide ready-to-use source packages for building cross compilers.
The major reason why this is so much work is because the necessary
changes have not been incorporated into dpkg and we end up having to
patch a patch of a diversion of a patch.
Emdebian has quite a good relationship with the gcc maintainers and our
patches are generally welcome but that does not diminish the amount of
time involved in making a tested patch in the first place. Emdebian only
has enough developer time to derive patches for the latest versions of
gcc and even then it can be difficult to keep up with gcc releases. We
look forward to the stability of the pre-Lenny freeze because we know
that we can catch up and get a stable set of toolchains for unstable and
testing, all thoroughly tested and fixed. Then as soon as Lenny comes
out, we'll be swamped by gcc changes again. (We, in this case, equals
Hector Oron, myself and Wookey - gcc has a much larger team just for
itself.)
Why propose changing every version of gcc (a process that could take
extreme amounts of time to test, implement and get into testing) and
then make it impossible to build cross compilers in Etch? Are we looking
at backports as well?? Who is going to do all that work? (Not me, before
anyone asks.)
ARCH is a very generic environment variable that might be set for some
other reasons (I use it for example in debian-cd) and I don't like to
change the behaviour of dpkg-shlibdeps just because it's set. IMO,
there should be a single check to activate cross-building support
cross building != building a cross compiler, as I've said many times.
A single check for cross building is already in place -
DEB_BUILD_GNU_TYPE != DEB_HOST_GNU_TYPE
I created a patch for that in gcc for reverse cross support, it is
included in gcc-4.2.
A mass bug filing is already under way to implement this single check
for cross building support across Debian. The patch to dpkg-shlibdeps
contains a part of that support.
Cross building gcc is NOT the problem. gcc now cross builds just like
any other package in Debian. If reverse cross support in Debian goes
wrong, I'll fix it. I've no problem with that.
Building a cross compiler is a completely separate task and one that has
only become a problem *after* changes in dpkg made the dpkg-cross
diversions impractical.
and gcc's crossbuild should provide the right variables.
It does, thanks to the reverse cross support in gcc-4.2. Thankfully, we
don't need reverse cross support in 4.1 or earlier. (Well, it would be
nice if it could happen but then nobody has the time to do it so ...)
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 to the patch for scripts/Dpkg/Shlibs.pm
# GCC_TARGET for cross compiler builds
my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{GCC_TARGET}) if
($ENV{GCC_TARGET});
...
I went for ARCH before because, in the context of building a cross
compiler, ARCH is only set at certain times. GCC_TARGET is set at the
beginning and is present throughout the build. This means that the
patched dpkg-shlibdeps behaves much more like the original diversion
from dpkg-cross - it effectively extends the list of directories
searched by dpkg-shlibdeps to include the ${crossprefix} ones for every
call throughout the entire build. It may slow things down a little bit
but building a cross compiler isn't exactly quick anyway. It is far more
important that the build completes than shaving a few more seconds off
the build time.
Furthermore, all the cross-building support in gcc has been contributed
by various Emdebian people (according to doko), so it looks like Emdebian
is also able to fix gcc in that regard if needed.
Those fixes (or hacks) were implemented piecemeal over many years and
the cross building support in Emdebian has recently been rewritten so
some of those hacks (i.e. the dpkg-cross
Processed: setting package to dpkg dpkg-dev dselect, tagging 455260
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 There were no tags set. Tags added: pending End of message, stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453267: tested patch
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 to the patch for scripts/Dpkg/Shlibs.pm
# GCC_TARGET for cross compiler builds
my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{GCC_TARGET}) if
($ENV{GCC_TARGET});
...
I went for ARCH before because, in the context of building a cross
compiler, ARCH is only set at certain times. GCC_TARGET is set at the
beginning and is present throughout the build.
If I understand you correctly, we can check for GCC_TARGET only and we
don't need to check DEB_TARGET_GNU_TYPE != DEB_BUILD_GNU_TYPE.
Is that correct and does that work ?
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Bug#453267: tested patch
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 with this change to the patch for scripts/Dpkg/Shlibs.pm
# GCC_TARGET for cross compiler builds
my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{GCC_TARGET}) if
($ENV{GCC_TARGET});
...
I went for ARCH before because, in the context of building a cross
compiler, ARCH is only set at certain times. GCC_TARGET is set at the
beginning and is present throughout the build.
If I understand you correctly, we can check for GCC_TARGET only and we
don't need to check DEB_TARGET_GNU_TYPE != DEB_BUILD_GNU_TYPE.
What's the obsession with cutting components out of the patch?? I'm
confused.
dpkg-shlibdeps should at least *support* the right way of doing
things, even if the packages currently do not use that. At least it
supports a migration route away from GCC_TARGET for future releases of
gcc. GCC_TARGET is a hack, yes, but we need it around for older
compilers that simply aren't going to get fixed. It would be nice to
provide a migration path to do it TheRightWay(TM) eventually because
that only means changing the latest version of gcc (probably 4.3) and we
can do that in the Lenny freeze when everything else gets easier too. I
don't want to have to go through all this again. GCC_TARGET is likely to
be around until gcc-4.3 gets into oldstable but that's a small price to
pay, IMHO. (It's been around for as long as dpkg-cross which is a decade
so a bit longer isn't going to hurt.)
Is that correct and does that work ?
I don't believe it is correct but it happens to work - for now.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
signature.asc
Description: OpenPGP digital signature
