<div dir="ltr"><div class="gmail_quote">On Tue, 3 Mar 2015 at 09:27 Luca Bruno <<a href="mailto:lucab@debian.org">lucab@debian.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Saturday 28 February 2015 11:18:59 Angus Lees wrote:<br>
> Just before I forget what I've managed to unravel:<br>
><br>
> I'm trying to compile cargo using rustc from our rustc.deb.<br>
<br>
Is alpha2 actualy buildable with that rustc or are we still hitting #1223?<br>
<a href="https://github.com/rust-lang/cargo/issues/1223" target="_blank">https://github.com/rust-lang/<u></u>cargo/issues/1223</a></blockquote><div><br></div><div>I had to go back and rebuild our rustc before I could get past the <a href="http://build.rs">build.rs</a> failures, so I don't know yet ;)</div><div><br></div><div>I talked with upstream (huonw) a few days ago and they merged/patched HEAD into a state that was able to build with alpha.2.  There was apparently still some outstanding (runtime) issue, but I was unclear on the details without experimenting with it myself.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> The first issue I've hit is that the <a href="http://build.rs" target="_blank">build.rs</a> commands fail because rustc<br>
> isn't using<br>
> -C rpath by default and cargo builds the build scripts with -C<br>
> prefer_dynamic.<br>
><br>
> I think that the -C prefer_dynamic bit might be a cargo bug in this<br>
> situation, but the issue is still a valid one.<br>
<br>
I suspect the same. Can you please share the build log or the source package,<br>
just to get a better idea?<br>
I haven't checked the details, but I think we should probably ask them to<br>
build cargo with a [profile.dev] containing:<br>
"""<br>
rpath = true<br>
# or<br>
lto = true<br>
"""<br>
and wait for #1368 to land:<br>
<a href="https://github.com/rust-lang/cargo/pull/1368" target="_blank">https://github.com/rust-lang/<u></u>cargo/pull/1368</a><br>
<br>
Does the above work for you? If so, can you please open a bug upstream to<br>
discuss this? Also, we would probably need a way to set/override build<br>
profiles system-wide.<span style="font-size:13.1999998092651px"> </span></blockquote><div><br></div><div>lto=true seems a bit heavy-handed for a dev build, but rpath=true would presumably work ok.</div><div><br></div><div>Do we need to support rustc uses without cargo?  (ie: do we need to patch rustc platform definitions rather than cargo profiles)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> <emphasis><br>
> So long as we have _any_ use-case for dylibs, I think we need to either<br>
> patch rustc to enable -C rpath by default, or move the dylibs back into<br>
> LD_LIBRARY_PATH (and thus no longer require rpath).<br>
> </emphasis><br>
><br>
> My preference is on the latter.  One day we will have library ABI<br>
> compatibility and need to split out a "rust-libstd" package from rustc.deb,<br>
> so we're going to need some major library upheaval in the not-too-distant<br>
> future.  I suggest we do the simplest thing now (move the dylibs back into<br>
> standard lib dirs) and deal with installing multiple library versions later<br>
> - once we know more about exactly what that will require.<br>
<br>
I'm also not a great fan of rpath. Upstream suggests static linking, but still<br>
they ship several .so and many stuff subtly depends on that.<br></blockquote><div><br></div><div>.. and rustc plugins will always need to be dynamically linked (but the resulting binaries that _used_ those plugins to compile don't need the runtime dependency, so the rebuild cascade is short)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
However, it may makes sense to keep hiding the .so away for now and see how<br>
many stuff breaks. These are genuine bugs in the "build statically" strategy<br>
upstream is suggesting, so they should be fixed now.<br></blockquote><div><br></div><div>We should be sure to separate "build statically" from "ship static binaries" in the conversation with upstream.  Only the latter runs into ABI versioning issues.</div><div><br></div><div>Cargo's use of prefer-dynamic here (for example) _should_ be fine (and is apparently fine for everyone other than our Debian rustc, or else it would have been noticed earlier).  The build script is a throwaway executable that doesn't appear in the resulting installed binaries, so ABI compatibility is not a concern.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> Of course from a packaging pov, any _package_ that shipped dylibs (compiler<br>
> plugins?) would need a strong dependency on the rustc version<br>
<br>
I expect compiler plugins to be tightly linked to rustc version anyway.<br>
<br>
> Cargo's use of dylibs<br>
> as a temporary step in the build process (for <a href="http://build.rs" target="_blank">build.rs</a>) seems like<br>
> something we should support, however.<br>
<br>
I think this specific case is something to be fixed in cargo.<br>
<br>
The bigger point is still open for discussion, though.<br></blockquote><div><br></div><div>Yeah.  I'm putting together a rustc that installs into /usr/lib so I can compare experiences.  (It will stay in a non-master branch until/unless there's further consensus).</div><div><br></div><div> - Gus</div></div></div>