Packaging Rust for Fedora
Packaging Rust for Fedora
Posted Oct 28, 2022 17:51 UTC (Fri) by khim (subscriber, #9252)In reply to: Packaging Rust for Fedora by tchernobog
Parent article: Packaging Rust for Fedora
> Just use shared libraries? You seem to be under the impression Rust doesn't support them.
Rust doesn't really support shared libraries. swift does, though and Rust-the-language forces traits model which makes that support not impossible in the future.
That's hard task, though, not something you may demand while Rust developers are doing that development on shoestring budget.
Posted Oct 28, 2022 19:33 UTC (Fri)
by tchernobog (guest, #73595)
[Link] (7 responses)
Else, you can opt to stick with the same rustc version for a few years, and the unstable ABI producing dylibs (".rlib") will be enough.
I mean, it's not like Perl gets upgraded on my Debian system without hundreds of modules going through a mass rebuild. And C++ ABI got calmer only with libstdc++ versioning.
I am just saying: it's not a particularly new film we are seeing. Nor one which has an unsolvable scenario, given enough willingness to fix it.
Posted Oct 28, 2022 21:08 UTC (Fri)
by khim (subscriber, #9252)
[Link] (6 responses)
You can't. Ideomatic Rust is built on top Actually you can't even use other generic types without language support similar to what Swift did. That, basically, means that instead of using shared libraries as, well, libraries, you are creating modules, boundaries of which are almost as hard to cross as boundaries between processes. At this point making shared libraries makes no sense. Too much pain for too little gain. Better to link in network library and go with multiple processes. No. It got calmer when C++ developers have decided: yes, we do want to support shared libraries. Rust developers have never done that. This would have worked if Rust releases, like GNAT releases, happened once a year. And even that would have been problematic (I don't think any distribution releases too many shared Ada libraries). But they are released 8 times a year. That's too much churn to realistically support. You can't go against upstream, basically. If upstream doesn't want to support shared libraries and actively makes that support problematic then they wouldn't be supported.
Posted Oct 30, 2022 13:31 UTC (Sun)
by ssokolow (guest, #94568)
[Link] (4 responses)
Whether or not to build a ...not to mention, Rust's dependency counts are misleading when you're trying to make comparisons, because C and C++ are rife with bespoke reimplementations and single-header libraries that maintainers just take in stride, rather than trying to split out into their own packages. (See the Gotta go deeper section of Alopex's Let's Be Real About Dependencies for details on that.)
Posted Oct 30, 2022 14:50 UTC (Sun)
by khim (subscriber, #9252)
[Link] (3 responses)
No. The important thing is standard library. It's ideomatic to use it in both C++ and Rust. And while it's called Standard Template Library Swift as we all know picked different road, compiler-based. But, again: standard types and standard templates are usable when you build shared library. In Rust land… Rust developers have never done that and not even That means that shared-library-Rust doesn't even remotely resemble normal That's pretty big difference: while in C++ it's possible to write code which would be acceptable both in normal C++ project and in shared library, too… in Rust it's just impossible. Without ability to just return In C++, on the other hand, it's perfectly fine to accept
Posted Oct 30, 2022 15:02 UTC (Sun)
by ssokolow (guest, #94568)
[Link] (2 responses)
Posted Oct 30, 2022 16:51 UTC (Sun)
by khim (subscriber, #9252)
[Link] (1 responses)
There is no free lunch. Either you have ABI-stable standard library or shared libraries are, basically, impossible. And it's not as if Rust standard library can do sudden, radical, changes. It just wasn't in use for as long as C++ one.
Posted Oct 30, 2022 17:09 UTC (Sun)
by ssokolow (guest, #94568)
[Link]
Posted Oct 31, 2022 11:44 UTC (Mon)
by DianaNites (subscriber, #160945)
[Link]
Packaging Rust for Fedora
> You can use Packaging Rust for Fedora
#[repr(C)] if you want a stable ABI now.
Option<T> and Result<T, E> (some language construct don't even accept anything else!) — and these are not #[repr(C)].Packaging Rust for Fedora
No. It got calmer when C++ developers have decided: yes, we do want to support shared libraries. Rust developers have never done that.
cdylib from a Rust project is certainly a choice upstream makes, but also bear in mind in mind that, unless things have changed since 2012 on the ABI compatibility front, many of the core issues are just as unsolved in C++... it's just less idiomatic to rely on things like templates in C++ than on things like generics in Rust. (See The impact of C++ templates on library ABI by Michał Górny from 2012 for more on that.)
> it's just less idiomatic to rely on things like templates in C++ than on things like generics in Rust.
Packaging Rust for Fedora
libstdc++ developers have decided that they would find a way to make it work as shared library. And they did. Yes, templates are injected in your code, not in the shared library, but certain discipline on the side of libstdc++ developers made it possible.core is offered in a way suitable for use in shared libraries.std-based Rust. While in C++ the part which can be used as shared library is very much a subset of what you would do in normal C++.Result or accept Option your code is not Rust, it's different language.std::option or pass std::unique_ptr even in function which is part of shared library.
Fair point... though an argument has also been made that C++'s focus on ABI stability is killing the standard library.
Packaging Rust for Fedora
Packaging Rust for Fedora
Packaging Rust for Fedora
There is no free lunch. Either you have ABI-stable standard library or shared libraries are, basically, impossible.
Or you marshal your data in some way, like the abi_stable crate does for enabling dlopen-able libraries using higher-level Rust constructs via Rust-Rust FFI through the C ABI.
And it's not as if Rust standard library can do sudden, radical, changes. It just wasn't in use for as long as C++ one.
The Rust standard library has two advantages over C++ on that front:
HashMap implementation for a vendored copy of a port of Google's SwissTable. There's currently a PR being refined to replace the internals of std::sync::mpsc with a vendored copy of crossbeam-channel.)Packaging Rust for Fedora