Rust 1.15 was released today, yay! I'm working on the update, but wanted to run something by you folks.
First, thanks to the Rust ABI or lack thereof, I've made efforts to strongly discourage the use of "dylib" targets and linking, to the point that I currently have removed *.so from rustlib/ entirely, and the remaining libraries in %{_libdir} have their .rustc metadata stripped. Without the metadata, you can't link to them at all, so they're only useful to rustc itself. Finally, the rust.spec has requires/provides filtering to exclude all Rust libraries.
However, the big new feature of 1.15 is proc_macro, aka custom derive, aka macros 1.1. These are basically compiler plugins, and must be compiled as a shared library for the build system (not the target). But that also means it's linking user code to dynamic versions of Rust libraries, so it needs the libraries to be in rustlib/$build_target/lib with the .rustc metadata that I've been stripping.
So, I need to restore that (or rather leave it alone), yet I still would insist that no other code should ship linked to dynamic libraries. The ABI is not a problem for custom derive because these are transient during a build, not something we'll package up.
Another thing to note is that the libraries that Rust installs in %{_libdir} are identical to those under rustlib/$target/lib/.
So my tentative plan is:
- Stop stripping .rustc from the libraries. - Also have to set _find_debuginfo_opts -g, so eu-strip will leave the unallocated section alone. (It's very eager.) - Package the rustlib/ libraries in the base rust.rpm. - Remove the %{_libdir} libraries that are identical anyway, and instead install an entry to rustlib/ in /etc/ld.so.conf.d/. - Continue the requires/provides filtering. - Continue shipping *.rlib in rust-std-static. - This still works for multilib/cross-compiling too.
This will make it possible now for anyone to link dynamically, with "rustc -Cprefer-dynamic", but we won't support this officially, and won't heed compatibility when upgrading rust. Without the RPM provides, nothing can be packaged in Fedora with prefer-dynamic.
Does that make sense? Any other ideas?
On 02/02/2017 06:41 PM, Josh Stone wrote:
So my tentative plan is:
- Stop stripping .rustc from the libraries.
- Also have to set _find_debuginfo_opts -g, so eu-strip will leave the unallocated section alone. (It's very eager.)
- Package the rustlib/ libraries in the base rust.rpm.
- Remove the %{_libdir} libraries that are identical anyway, and instead install an entry to rustlib/ in /etc/ld.so.conf.d/.
- Continue the requires/provides filtering.
- Continue shipping *.rlib in rust-std-static.
- This still works for multilib/cross-compiling too.
I've done this -- everything seems to work great locally. See the spec and its diff attached, and let me know if there's anything else you'd like to tweak right now.
There will probably be a quick 1.15.1 point release for a soundness bug in one of the new APIs (rust#39466), so I think I'll wait for that before sending a proper build out to koji.
On 02/03/2017 03:10 PM, Josh Stone wrote:
On 02/02/2017 06:41 PM, Josh Stone wrote:
So my tentative plan is:
- Stop stripping .rustc from the libraries.
- Also have to set _find_debuginfo_opts -g, so eu-strip will leave the unallocated section alone. (It's very eager.)
- Package the rustlib/ libraries in the base rust.rpm.
- Remove the %{_libdir} libraries that are identical anyway, and instead install an entry to rustlib/ in /etc/ld.so.conf.d/.
- Continue the requires/provides filtering.
- Continue shipping *.rlib in rust-std-static.
- This still works for multilib/cross-compiling too.
I've done this -- everything seems to work great locally. See the spec and its diff attached, and let me know if there's anything else you'd like to tweak right now.
There will probably be a quick 1.15.1 point release for a soundness bug in one of the new APIs (rust#39466), so I think I'll wait for that before sending a proper build out to koji.
This update is in rawhide now, and on its way to testing:
f25: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9d616a3b75 f24: https://bodhi.fedoraproject.org/updates/FEDORA-2017-9e7217f11d epel7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2017-f9554c9ddb