<div dir="ltr">I'm sure you've already had this conversation in the past, so sorry for reopening the topic.  After thinking about this for a bit, my conclusions are:<div><br></div><div>- dylibs (rust shared libraries) aren't ABI compatible between compiler releases (yet, they presumably will be one day).  And the shv checksum thing on libraries looks promising but isn't used by upstream as part of a process for introducing ABI changes.</div><div><br></div><div>So I figure our options are:</div><div><br></div><div>1. Use dylibs and have a strong dependency on the specific compiler/stdlib version and recompile every rust package when a new compiler comes out.</div><div>This probably requires patching trivial SONAME support (just SONAME=file name) into the rust compiler, because the various dpkg/lintian tools get upset when they don't find an SONAME.</div><div><br></div><div>2. Only use dylibs between rustc and rustdoc since those are released from the same source package anyway (even easier if they're all in the same binary package).  We have dylibs in the package, but the compiler defaults to rlibs (static libraries) and we put a warning somewhere suggesting users don't depend on dylib ABI compatibility.</div><div>Requires the same SONAME patch as (1), or disabling the lintian/etc warnings.</div><div><br></div><div>3. Don't offer dylibs at all.  Build rustc+rustdoc statically and only ship rlibs.</div><div><br></div><div>4. Build dylibs but hide them in a subdirectory not on LD_LIBRARY_PATH.  This means rustc+rustdoc (and any other binary that uses them) needs to find them via rpath.</div><div><br></div><div>-----</div><div><br></div><div>If I've understood correctly, (4) is the current Debian packaging approach.</div><div><br></div><div>I think (1) is too complex, and results in every rust package having to be recompiled and transition unstable->testing in a single group every time a new rustc is released.  Yuck.</div><div><br></div><div>(2) is basically what happens if you just naively package up rustc with a make-install.  I actually don't think that's terrible except for the tools that get upset by missing SONAMEs.</div><div><br></div><div>(3) is the safest and simplest, and I'm inclined to go that way until the upstream plans for ABI compatibility become clearer.   The only downside appears to be wasted disk space from the duplicated code in any statically linked rust binaries.</div><div><br></div><div>(4) Seems like it doesn't actually improve the versioning problem, is starting to diverge from what upstream are doing, and requires rpath which limits our ability to change dylib location in the future.  Obviously I haven't appreciated the original motivation for this approach, so feel free to point out what I've missed ;)</div><div><br></div><div><br></div><div>I'm inclined to suggest we go with (3 - rlibs only) for now, partly because it gives us the most freedom to move to something better when upstream also sorts this out.</div><div><br></div><div>Thoughts?</div><div><br></div><div> - Gus</div></div>