Bug#753934: Bug#750722: libsvn1: libsvn_ra_local inexplicably gains 2044KiB of zero bytes
On Sun, Jul 06, 2014 at 11:49:01PM +0300, Niko Tyni wrote: On Sat, Jun 07, 2014 at 09:39:12PM -0400, James McCoy wrote: Control: reassign -1 binutils 2.24.51.20140604-3 On Fri, Jun 06, 2014 at 09:32:37AM +0100, RjY wrote: During a recent package update I noticed libsvn1 grew a lot in installed-size. Upon investigation it turned out this was: % for i in libsvn1_1.8.8-2_amd64.deb libsvn1_1.8.9-1_amd64.deb ; do dpkg -c $i ; done | grep ra_local | grep -v '^l' -rw-r--r-- root/root 39800 2014-04-01 03:20 ./usr/lib/x86_64-linux-gnu/libsvn_ra_local-1.so.1.0.0 -rw-r--r-- root/root 2132856 2014-05-21 12:33 ./usr/lib/x86_64-linux-gnu/libsvn_ra_local-1.so.1.0.0 Why would a (relatively simple) module for local file:// url access suddenly gain 2044KiB in a minor update? The extra space appears to consist entirely of zero bytes, as well. Good question. Rebuilding 1.8.8-2 in a current sid chroot causes the same thing. This seems to be caused by something in the toolchain. Based on my minimal knowledge of what goes into building the shared libraries, I'll start this off in binutils' court. It does seem to be binutils. Bisecting one of the overgrown .so files in the perl package (see #753934) with different versions of binutils installed, sizes before stripping: -rwxr-xr-x 1 niko niko 1341099 Jul 6 23:13 lib/auto/Unicode/Collate/Collate.so-binutils_2.22-8 -rwxr-xr-x 1 niko niko 1341187 Jul 6 23:22 lib/auto/Unicode/Collate/Collate.so-binutils_2.24-5 -rwxr-xr-x 1 niko niko 3434243 Jul 6 23:24 lib/auto/Unicode/Collate/Collate.so-binutils_2.24.51.20140411-2 -rwxr-xr-x 1 niko niko 3434243 Jul 6 23:35 lib/auto/Unicode/Collate/Collate.so-binutils_2.24.51.20140425-1 -rwxr-xr-x 1 niko niko 3434243 Jul 6 23:19 lib/auto/Unicode/Collate/Collate.so-binutils_2.24.51.20140604-3 -rwxr-xr-x 1 niko niko 3434243 Jul 6 23:14 lib/auto/Unicode/Collate/Collate.so-binutils_2.24.51.20140617-1 The latest subversion upload used binutils 2.24.51.20140709-1 and the library sizes are back to normal. I don't see anything relevant in the changelog, but it'd be worth seeing if that also resolves the issue for Perl's build. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org signature.asc Description: Digital signature
Bug#753934: Bug#750722: libsvn1: libsvn_ra_local inexplicably gains 2044KiB of zero bytes
On Sat, Jun 07, 2014 at 09:39:12PM -0400, James McCoy wrote: Control: reassign -1 binutils 2.24.51.20140604-3 On Fri, Jun 06, 2014 at 09:32:37AM +0100, RjY wrote: During a recent package update I noticed libsvn1 grew a lot in installed-size. Upon investigation it turned out this was: % for i in libsvn1_1.8.8-2_amd64.deb libsvn1_1.8.9-1_amd64.deb ; do dpkg -c $i ; done | grep ra_local | grep -v '^l' -rw-r--r-- root/root 39800 2014-04-01 03:20 ./usr/lib/x86_64-linux-gnu/libsvn_ra_local-1.so.1.0.0 -rw-r--r-- root/root 2132856 2014-05-21 12:33 ./usr/lib/x86_64-linux-gnu/libsvn_ra_local-1.so.1.0.0 Why would a (relatively simple) module for local file:// url access suddenly gain 2044KiB in a minor update? The extra space appears to consist entirely of zero bytes, as well. Good question. Rebuilding 1.8.8-2 in a current sid chroot causes the same thing. This seems to be caused by something in the toolchain. Based on my minimal knowledge of what goes into building the shared libraries, I'll start this off in binutils' court. It does seem to be binutils. Bisecting one of the overgrown .so files in the perl package (see #753934) with different versions of binutils installed, sizes before stripping: -rwxr-xr-x 1 niko niko 1341099 Jul 6 23:13 lib/auto/Unicode/Collate/Collate.so-binutils_2.22-8 -rwxr-xr-x 1 niko niko 1341187 Jul 6 23:22 lib/auto/Unicode/Collate/Collate.so-binutils_2.24-5 -rwxr-xr-x 1 niko niko 3434243 Jul 6 23:24 lib/auto/Unicode/Collate/Collate.so-binutils_2.24.51.20140411-2 -rwxr-xr-x 1 niko niko 3434243 Jul 6 23:35 lib/auto/Unicode/Collate/Collate.so-binutils_2.24.51.20140425-1 -rwxr-xr-x 1 niko niko 3434243 Jul 6 23:19 lib/auto/Unicode/Collate/Collate.so-binutils_2.24.51.20140604-3 -rwxr-xr-x 1 niko niko 3434243 Jul 6 23:14 lib/auto/Unicode/Collate/Collate.so-binutils_2.24.51.20140617-1 This is with just the linking step, Collate.o was the same all the time. I was using rm lib/auto/Unicode/Collate/Collate.so make lib/auto/Unicode/Collate/Collate.so which seems to execute just cc -shared -Wl,-z,relro -L/usr/local/lib -fstack-protector Collate.o -o ../../lib/auto/Unicode/Collate/Collate.so However, the weird thing is that perl_5.18.2-4 has a smaller Collate.so even though it was built with binutils_2.24.51.20140425-1. I see gcc was still at 4.8 then, so maybe it needs a specific pattern that just happens to get triggered with gcc-4.9 or something like that. Hope this helps tracking it down, -- Niko Tyni nt...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750722: libsvn1: libsvn_ra_local inexplicably gains 2044KiB of zero bytes
Control: reassign -1 binutils 2.24.51.20140604-3 On Fri, Jun 06, 2014 at 09:32:37AM +0100, RjY wrote: During a recent package update I noticed libsvn1 grew a lot in installed-size. Upon investigation it turned out this was: % for i in libsvn1_1.8.8-2_amd64.deb libsvn1_1.8.9-1_amd64.deb ; do dpkg -c $i ; done | grep ra_local | grep -v '^l' -rw-r--r-- root/root 39800 2014-04-01 03:20 ./usr/lib/x86_64-linux-gnu/libsvn_ra_local-1.so.1.0.0 -rw-r--r-- root/root 2132856 2014-05-21 12:33 ./usr/lib/x86_64-linux-gnu/libsvn_ra_local-1.so.1.0.0 Why would a (relatively simple) module for local file:// url access suddenly gain 2044KiB in a minor update? The extra space appears to consist entirely of zero bytes, as well. Good question. Rebuilding 1.8.8-2 in a current sid chroot causes the same thing. This seems to be caused by something in the toolchain. For reference, here are the differences in some key toolchain packages for the original 1.8.8-2 build and the one I just re-ran: package | small lib version | large lib version - binutils | 2.24-5| 2.24.51.20140604-3 g++4.8| 4.8.2-18 | 4.8.3-3 gcc-4.8 | 4.8.2-18 | 4.8.3-3 gcc-4.9 | n/a | 4.9.0-5 libc6-dev | 2.18-4| 2.19-1 libstdc++-4.8-dev | 4.8.2-18 | 4.8.3-3 libstdc++6| 4.8.2-18 | 4.9.0-5 Based on my minimal knowledge of what goes into building the shared libraries, I'll start this off in binutils' court. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy james...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750722: libsvn1: libsvn_ra_local inexplicably gains 2044KiB of zero bytes
Package: libsvn1
Version: 1.8.9-1
Severity: minor
During a recent package update I noticed libsvn1 grew a lot in
installed-size. Upon investigation it turned out this was:
% for i in libsvn1_1.8.8-2_amd64.deb libsvn1_1.8.9-1_amd64.deb ; do dpkg -c
$i ; done | grep ra_local | grep -v '^l'
-rw-r--r-- root/root 39800 2014-04-01 03:20
./usr/lib/x86_64-linux-gnu/libsvn_ra_local-1.so.1.0.0
-rw-r--r-- root/root 2132856 2014-05-21 12:33
./usr/lib/x86_64-linux-gnu/libsvn_ra_local-1.so.1.0.0
Why would a (relatively simple) module for local file:// url access
suddenly gain 2044KiB in a minor update? The extra space appears to
consist entirely of zero bytes, as well.
As far as I can tell, the module source hasn't changed:
diff -ur subversion-1.8.{8,9}/subversion/libsvn_ra_local
produced no output.
I think there's been some kind of build error somewhere.
--
http://rjy.org.uk/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
