You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I love the idea of Rust cross-compiling to arbitrary glibc versions as easily as Zig does. Seems like parsing Zig's abilists is one part of that goal. Are you working on the complete picture? Is anyone?
My understanding (which could be way off) is that in general terms, Zig uses these abilists to represent the ABI (exported symbols, some with versioning/weak definition or something) of all versions of glibc. You can select one and the linker essentially assumes the existence of a matching .so somehow.
So how can this work for Rust out of the box? My thoughts below but perhaps yours are more fleshed out...
Short-term: maybe a linker script that can be dropped in via target.<triple>.linker (see docs) and actually constructs a dummy .so file (a .so with the correct definitions and non-functioning implementations) and somehow sets up linker arguments to assume it's installed in the system search path (i.e., not adding an rpath entry to a tempdir or some such).
Long-term: it'd be nice if you could just add glibc-version to a [target.<arch>-unknown-linux-gnu] section of your .cargo/config.toml and cargo plumbed along the option to rustc, which took care of the rest for you. Maybe it does what that linker script does, or maybe the linker does/should provide some more abstract interface than an existing .so file.
The text was updated successfully, but these errors were encountered:
I love the idea of Rust cross-compiling to arbitrary glibc versions as easily as Zig does. Seems like parsing Zig's abilists is one part of that goal.
Ditto! I don't have much experience with actually working on the compilation toolchain itself or doing advanced linking configuration in any language, but I'm excited to contribute. :) It was easy enough for me to write a binary parsing lib -- now I'm hoping I can actually get familiar with the domain it'll actually get used in!
Are you working on the complete picture? Is anyone?
WRT glibc symbols? IDK, actually. I'm asking on the #t-compiler stream right now in the official Rust Zulip.
RE: your long- and short-term suggestions: I unfortunately don't feel like I have a good enough grasp on the process of actually targeting different glibc versions to give intelligent feedback, unfortunately! I would like to learn enough to change that, and maybe you could help me do that.
I love the idea of Rust cross-compiling to arbitrary glibc versions as easily as Zig does. Seems like parsing Zig's abilists is one part of that goal. Are you working on the complete picture? Is anyone?
My understanding (which could be way off) is that in general terms, Zig uses these abilists to represent the ABI (exported symbols, some with versioning/weak definition or something) of all versions of glibc. You can select one and the linker essentially assumes the existence of a matching
.so
somehow.So how can this work for Rust out of the box? My thoughts below but perhaps yours are more fleshed out...
Short-term: maybe a linker script that can be dropped in via
target.<triple>.linker
(see docs) and actually constructs a dummy.so
file (a.so
with the correct definitions and non-functioning implementations) and somehow sets up linker arguments to assume it's installed in the system search path (i.e., not adding an rpath entry to a tempdir or some such).Long-term: it'd be nice if you could just add
glibc-version
to a[target.<arch>-unknown-linux-gnu]
section of your.cargo/config.toml
andcargo
plumbed along the option torustc
, which took care of the rest for you. Maybe it does what that linker script does, or maybe the linker does/should provide some more abstract interface than an existing.so
file.The text was updated successfully, but these errors were encountered: