<div dir="ltr"><span style="font-size:13.1999998092651px">Just before I forget what I've managed to unravel:</span><div style="font-size:13.1999998092651px"><br></div><div>I'm trying to compile cargo using rustc from our rustc.deb.  The first issue I've hit is that the <a href="http://build.rs">build.rs</a> commands fail because rustc isn't using -C rpath by default and cargo builds the build scripts with -C prefer_dynamic.</div><div><br></div><div>I think that the -C prefer_dynamic bit might be a cargo bug in this situation, but the issue is still a valid one.  Perhaps a clearer<span style="font-size:13.1999998092651px"> example raised by <a href="https://github.com/rust-lang/rfcs/blob/master/text/0404-change-prefer-dynamic.md">https://github.com/rust-lang/rfcs/blob/master/text/0404-change-prefer-dynamic.md</a> is that linking against dylibs are necessary when writing compiler plugins (and any other form of rust plugin) so I expect we'll hit this again soon with libregex and friends.</span></div><div><span style="font-size:13.1999998092651px"><br></span></div><div><emphasis></div><div><span style="font-size:13.1999998092651px">So long as we have _any_ use-case for dylibs, I think we need to either patch rustc to enable -C rpath by default, or move the dylibs back into LD_LIBRARY_PATH (and thus no longer require rpath).</span></div><div></emphasis></div><div><br></div><div>My preference is on the latter.  One day we will have library ABI compatibility and need to split out a "rust-libstd" package from rustc.deb, so we're going to need some major library upheaval in the not-too-distant future.  I suggest we do the simplest thing now (move the dylibs back into standard lib dirs) and deal with installing multiple library versions later - once we know more about exactly what that will require.</div><div><br></div><div>Of course from a packaging pov, any _package_ that shipped dylibs (compiler plugins?) would need a strong dependency on the rustc version and get complicated and we should avoid those cases for now.  Cargo's use of dylibs as a temporary step in the build process (for <a href="http://build.rs">build.rs</a>) seems like something we should support, however.</div><div><br></div><div>Anyone want to make the case for taking the rpath-by-default approach instead?</div><div><br></div><div> - Gus</div></div>