[Nix-dev] Generating nixos-compatible binaries? And bootstrapped packages.

[Christian Theune]

Hi,

something related that we experienced: allowing users to compile/link against the system environment causes later mayhem: linkers will typically resolve any symlinks and then have shared libraries looked up by their store path. If that goes away later (as the manually compiled binary is not referenced from a GC root) this will cause breakage.

Linking things to /lib (or setting the LD_LIBRARY_PATH to a profile/lib) may be unpredictably bad. :)

Christian

> On 25 Aug 2016, at 00:37, Tomasz Czyż <tomasz.czyz at gmail.com> wrote:
> 
> Personaly, I was a little tired with repatching 3rd party binaries and I linked ld-linux-x86-64.so to /lib and /usr/lib (where most apps looks for this).
> 
> One time I even linked /usr/lib and /lib directly to /run/current-profile/sw/lib and even have got working some non static binaries :-) (but that's evil, don't do that :-))
> 
> 2016-08-24 20:24 GMT+01:00 Vladimír Čunát <vcunat at gmail.com <mailto:vcunat at gmail.com>>:
> On 08/24/2016 05:51 PM, Nick Sabalausky wrote:
> > Also, kind of related: When a package does depend on an older version of
> > itself in order to be built from source, what is the nix way of going
> > about that?
> >
> > Ie: Suppose building package foobar v3.0 depends on foobar v2.0, and
> > building foobar 2.0 depends on foobar v1.0.
> >
> > Would there be separate packages "foobar1, foobar2, and foobar3" with
> > foobar3 set to depend on foobar2, etc? But then wouldn't that lead to a
> > conflict when trying to build/install foobar v3.0 while foobar v2.0 is
> > already installed (since it needed to be installed in order to build v3.0)?
> >
> > Or would the nix expression for foobar v3.0 not *formally* depend on the
> > older packages and just simply *internally* download/build v1, then v2,
> > then v3? But then down the road, wouldn't that eventually severely bloat
> > build times for the latest versions?
> 
> We do have some packages that require a binary version to bootstrap
> itself - often compilers, e.g. gcc, ghc, etc. The dependency would be
> build-time only, so most people get the final binary directly from Hydra
> and never see the older one.
> 
> Conflicts: you have to realize that building a package doesn't normally
> put it into any visible/conflictable place - it's just a path in
> /nix/store/something. If the user *explicitly* asked to put multiple
> versions into a single environment (via nix-env -i or systemPackages),
> there would be a conflicting bin/foo most likely, but people typically
> don't need that...
> 
> --Vladimir
> 
> 
> 
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl <mailto:nix-dev at lists.science.uu.nl>
> http://lists.science.uu.nl/mailman/listinfo/nix-dev <http://lists.science.uu.nl/mailman/listinfo/nix-dev>
> 
> 
> 
> 
> --
> Tomasz Czyż
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev

--
Christian Theune · ct at flyingcircus.io · +49 345 219401 0
Flying Circus Internet Operations GmbH · http://flyingcircus.io
Forsterstraße 29 · 06112 Halle (Saale) · Deutschland
HR Stendal HRB 21169 · Geschäftsführer: Christian. Theune, Christian. Zagrodnick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160825/d5d0b766/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160825/d5d0b766/attachment-0001.sig>