I have just uploaded four pull requests [1] to fix various packages.
Amongst them, ldb is akin to a mass-rebuild and is probably the most
used package keeping a reference to gcc.
@Wout, Which packages do you have that depend on gcc ?
It is quite annoying that nixpkgs requires to specify which paths to strip.
Only one package keeping build dependencies can pull a lot of bloat.
Of course, having checks for this like suggested in #12898 would help a lot.
[1] https://github.com/NixOS/nixpkgs/pull/14821 and following.
On 19/04/16 12:52, Wout Mertens wrote:
BTW, that reminds me of https://github.com/NixOS/nixpkgs/issues/12898
On Tue, Apr 19, 2016 at 12:50 PM Wout Mertens <wout.mert...@gmail.com
<mailto:wout.mert...@gmail.com>> wrote:
Thanks, that really helps!
On Tue, Apr 19, 2016 at 12:21 PM Layus <layus...@gmail.com
<mailto:layus...@gmail.com>> wrote:
On 19/04/16 11:52, Wout Mertens wrote:
> Hi,
>
> I would like to make a specialized image that just runs some
tools and
> has nothing else installed.
>
> If I uset the minimal profile it has stdenv, which includes
100MB of gcc.
>
> Pointers?
I am also working on this. From my investigations, the
closure-size
feature has everything required to get rid of gcc.out (and
keep gcc.lib
if required).
However, many packages are not correctly stripped or somehow
maintain a
reference to build inputs like gcc.
To benefit from this feature, you need to build from master.
If your closure still includes some gcc-X.Y.Z (gcc-X.Y.Z-lib
is ok),
here are some hints to track the misbehaving package.
You need to find package depending on gcc, then find why they have
runtime dependencies on their compiler.
$ nix-store -qR ./result | grep gcc
/nix/store/ikzdbd65z7453spdvm05r0izd56zdvkx-gcc-4.9.3 <- you
want to get
rid of this one.
...
$ blame () {comm -12 <(nix-store -qR "$1" | sort) <(nix-store -q
--referrers "$2" | sort); }
$ blame ./result
/nix/store/ikzdbd65z7453spdvm05r0izd56zdvkx-gcc-4.9.3
/nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/
... # (All these packages have runtime dependencies on gcc
binaries.)
Now you can try to investigate why they do depend on the full gcc.
It is probably an unstripped binary, or a wrong rpath.
Sometimes, the package keeps track of its buld flags, as mongo
does for
its --version info.
$ grep /nix/store/ikzdbd65z7453spdvm05r0izd56zdvkx-gcc-4.9.3 -r
/nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3 -al
/nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/bin/ppdhtml
/nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/bin/ppdc
/nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/bin/ppdpo
/nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/bin/ppdmerge
/nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/bin/ppdi
/nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/lib/cups/daemon/cups-driverd
/nix/store/rdp4z92qb7jr082pfl5b7jxwiiv3pic0-cups-2.1.3/lib/libcupsppdc.so.1
Now you can simply fix the derivations of these packages and
get rif of gcc.
Layus
_______________________________________________
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
