[Nix-dev] Minimal disk image without gcc?

[Layus]

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.mertens at gmail.com 
> <mailto:wout.mertens at gmail.com>> wrote:
>
>     Thanks, that really helps!
>
>     On Tue, Apr 19, 2016 at 12:21 PM Layus <layus.on at gmail.com
>     <mailto:layus.on at 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160419/7b5a35f7/attachment.html