Stream: t-compiler/help

Topic: Why are my native rustlibs missing for a cross-compile?


Jake Goulding (Jul 05 2020 at 00:03, on Zulip):

When cross-compiling from x86_64 to aarch64, the native rustlib directory is empty in the target compiler. However, my x86_64 compiler has the rustlibs for the _target_:

% ls build/aarch64-apple-darwin/stage1/lib/rustlib/aarch64-apple-darwin/lib | cat
libLLVM.dylib

% ls build/x86_64-apple-darwin/stage1/lib/rustlib/aarch64-apple-darwin/lib | cat
liballoc-bc1bed71af59030d.rlib
libbacktrace-908ce5b600cbb5e4.rlib
libbacktrace_sys-73640f972bd0168e.rlib
libcfg_if-ed32d5eef52668e4.rlib
libcompiler_builtins-48b6ebeb945f7f23.rlib
libcore-eae2616245cf1435.rlib
libgetopts-4868046cc68f6a07.rlib
libhashbrown-4019ac1df1726b61.rlib
liblibc-147e2bbc2c8920b5.rlib
libpanic_abort-2d6d15cfb868ff37.rlib
libpanic_unwind-5fba9238dd90a238.rlib
libproc_macro-7b75bc3478afb07d.rlib
librustc_demangle-022c7d6aca3d2ccc.rlib
librustc_std_workspace_alloc-322b374d69dcba49.rlib
librustc_std_workspace_core-3322a8e8a27ca844.rlib
librustc_std_workspace_std-12218c207bcf61af.rlib
libstd-6247a4aa0eaf3fee.dylib
libstd-6247a4aa0eaf3fee.rlib
libterm-fe16d30007d35333.rlib
libtest-23728a41e0e6f04a.dylib
libtest-23728a41e0e6f04a.rlib
libunicode_width-e2337f69b5becf1b.rlib
libunwind-65eb1f72892d4a26.rlib
self-contained
Jake Goulding (Jul 05 2020 at 00:04, on Zulip):

Is this "normal" for a cross-compile? Did I do something wrong?

eddyb (Jul 05 2020 at 04:37, on Zulip):

probably. there are 3 triples: "target", "host" and "build"

eddyb (Jul 05 2020 at 04:37, on Zulip):

I can never remember what the "host" vs "build" distinction is

eddyb (Jul 05 2020 at 04:38, on Zulip):

but AFAIK you use --target to get cross-compilation stdlib

eddyb (Jul 05 2020 at 04:39, on Zulip):

@Jake Goulding actually, wait, I misread, why would build/aarch64-apple-darwin exist/work?

André Arko (Jul 05 2020 at 04:39, on Zulip):

it was in the host array, I think

eddyb (Jul 05 2020 at 04:39, on Zulip):

unless you can execute aarch64-apple-darwin binaries, that directory shouldn't make sense I don't think?

André Arko (Jul 05 2020 at 04:39, on Zulip):

we can

eddyb (Jul 05 2020 at 04:40, on Zulip):

is this using the OS-level emulation layer thing?

André Arko (Jul 05 2020 at 04:40, on Zulip):

no, I have physical arm64 macOS hardware

André Arko (Jul 05 2020 at 04:40, on Zulip):

and that build above produces a rustc that works, but complains about a missing libstd

eddyb (Jul 05 2020 at 04:41, on Zulip):

I am talking about a system that can execute both aarch64-apple-darwin and x86_64-apple-darwin

André Arko (Jul 05 2020 at 04:41, on Zulip):

oh I see, yes, the physical hardware can execute both

eddyb (Jul 05 2020 at 04:41, on Zulip):

AFAIK that's the only reason to have both under ./build/

André Arko (Jul 05 2020 at 04:41, on Zulip):

so what's the right way to cross-compile from x86_64 to aarch64 then?

eddyb (Jul 05 2020 at 04:41, on Zulip):

@André Arko the hardware you're building Rust on?

eddyb (Jul 05 2020 at 04:42, on Zulip):

which one is the native and which one is it emulating?

André Arko (Jul 05 2020 at 04:42, on Zulip):

okay let me back up :)

André Arko (Jul 05 2020 at 04:42, on Zulip):

I have 1 intel x86_64 macOS machine, and 1 apple arm64 macOS machine

eddyb (Jul 05 2020 at 04:43, on Zulip):

to be clear: I'm asking about the machine that has both directories under ./build/

eddyb (Jul 05 2020 at 04:43, on Zulip):

no other machine

André Arko (Jul 05 2020 at 04:43, on Zulip):

that directory was produced by @Jake Goulding's x86_64 machine, where he was trying to cross-compile a rustc that would work an arm64

André Arko (Jul 05 2020 at 04:43, on Zulip):

he succeeded, the output rustc works when copied to the arm64 hardware

eddyb (Jul 05 2020 at 04:43, on Zulip):

can the x86_64 machine run aarch64 executables?

André Arko (Jul 05 2020 at 04:43, on Zulip):

no

eddyb (Jul 05 2020 at 04:44, on Zulip):

okay then AFAIK build/aarch64-apple-darwin shouldn't exist on that machine

André Arko (Jul 05 2020 at 04:44, on Zulip):

the one inside stage1, or the one containing stage1?

André Arko (Jul 05 2020 at 04:44, on Zulip):

oh you mean the top level one?

eddyb (Jul 05 2020 at 04:45, on Zulip):

yes, that's the one that depends on the hardware you're running on. or at least I haven't seen it any other way

André Arko (Jul 05 2020 at 04:45, on Zulip):

...your message is very confusing because the entire point of running the build was to create that directory

André Arko (Jul 05 2020 at 04:45, on Zulip):

like, cross compiling an arm64 rustc from x86_64

eddyb (Jul 05 2020 at 04:45, on Zulip):

hmmmmmm

André Arko (Jul 05 2020 at 04:45, on Zulip):

and it worked, build/aarch64-apple-darwin contained a working rustc at the end

eddyb (Jul 05 2020 at 04:45, on Zulip):

oh I see, our buildsystem is even more confusing than I expected

André Arko (Jul 05 2020 at 04:46, on Zulip):

but, confusingly, it was missing libstd

André Arko (Jul 05 2020 at 04:46, on Zulip):

unlike the x86_64 directory, which was not missing libstd

eddyb (Jul 05 2020 at 04:46, on Zulip):

(it can build anything cross-compiled into build/x86_64-apple-darwin, it's just the sysroot that wouldn't make sense)

André Arko (Jul 05 2020 at 04:46, on Zulip):

(literally copying the libs from x86_64 to aarch64 made it a full, working rustc, which I have then used to cargo install ripgrep and some other things successfully)

André Arko (Jul 05 2020 at 04:47, on Zulip):

huh okay

André Arko (Jul 05 2020 at 04:47, on Zulip):

in that case, what would be the "right" way to do that?

eddyb (Jul 05 2020 at 04:48, on Zulip):

not sure. to expand a bit, we have build/$tripleX/stage0-rustc/release/ and build/$tripleX/stage0-rustc/$tripleY/release/

eddyb (Jul 05 2020 at 04:48, on Zulip):

the former will contain things like build scripts and proc macros, that have to run on the same hardware that's doing the build

eddyb (Jul 05 2020 at 04:49, on Zulip):

while the latter will contain cross-compilation artifacts

eddyb (Jul 05 2020 at 04:49, on Zulip):

and I'm not even sure $tripleX matters for those

André Arko (Jul 05 2020 at 04:49, on Zulip):

ah ok, interesting

eddyb (Jul 05 2020 at 04:49, on Zulip):

(meaning we might be able to simplify our directory structure. not sure though)

André Arko (Jul 05 2020 at 04:49, on Zulip):

so (iirc) the configuration was build="x86_64-apple-darwin" and host=["aarch64-apple-darwin"]

eddyb (Jul 05 2020 at 04:50, on Zulip):

however, what you are talking about is the sysroots, e.g. build/$tripleX/stage1 (which has bin/rustc and lib/rustlib/$tripleZ etc.)

eddyb (Jul 05 2020 at 04:50, on Zulip):

that's what I was missing at first, those don't have more than $tripleX for the binaries

André Arko (Jul 05 2020 at 04:51, on Zulip):

ahh, yes that seems right

eddyb (Jul 05 2020 at 04:51, on Zulip):

@André Arko @Jake Goulding okay now that I'm not (as) confused... did you copy directories from build/ or try to use installing into a temporary directory?

eddyb (Jul 05 2020 at 04:52, on Zulip):

the former is not really supported

eddyb (Jul 05 2020 at 04:52, on Zulip):

except for rustup toolchain link and that's for non-cross-compiled rustc anyway

eddyb (Jul 05 2020 at 04:53, on Zulip):

I think you need something like DESTDIR=some/empty/dir ./x.py install

eddyb (Jul 05 2020 at 04:53, on Zulip):

and then that directory should contain bin, lib, etc, etc.

André Arko (Jul 05 2020 at 04:53, on Zulip):

ahh, okay. I didn't see anything in the rustc book that explained that, but maybe I missed it

André Arko (Jul 05 2020 at 04:53, on Zulip):

I was confused about why everything seemed so scattered in build/ :)

eddyb (Jul 05 2020 at 04:54, on Zulip):

yeah you're not supposed to poke around in there

eddyb (Jul 05 2020 at 04:54, on Zulip):

I guess this is just ./configure && make install tbh

eddyb (Jul 05 2020 at 04:54, on Zulip):

that's where the DESTDIR env var convention comes from

eddyb (Jul 05 2020 at 04:54, on Zulip):

this is how distros (are supposed to) build rustc

André Arko (Jul 05 2020 at 04:55, on Zulip):

got it, I'm not familiar with DESTDIR (only ./configure --prefix) so that didn't occur to me

André Arko (Jul 05 2020 at 04:55, on Zulip):

we also had the small intermediate problem of needing to edit rustc, build a new one, and use that one to run the cross-compile build

eddyb (Jul 05 2020 at 04:56, on Zulip):

--prefix is where you'll install stuff (so /usr typically), DESTDIR is whatever dir to dump the actual files in

eddyb (Jul 05 2020 at 04:56, on Zulip):

that the packager will put into a rpm, deb, etc.

André Arko (Jul 05 2020 at 04:56, on Zulip):

got it

André Arko (Jul 05 2020 at 04:56, on Zulip):

thanks, this is helpful

eddyb (Jul 05 2020 at 04:56, on Zulip):

I only learned about it a few months ago, from someone trying to package Rust without using Python (that was... a lot of fun :P)

eddyb (Jul 05 2020 at 04:57, on Zulip):

you should also be able to create whatever rustup downloads and install, using... ./x.py dist I think?, but presumably that's harder to use than installing into a directory that you then copy over

eddyb (Jul 05 2020 at 04:58, on Zulip):

@André Arko this seems useful https://www.gnu.org/prep/standards/html_node/DESTDIR.html

eddyb (Jul 05 2020 at 04:59, on Zulip):

this also mentions DESTDIR https://www.debian.org/doc/manuals/maint-guide/modify.en.html#destdir

eddyb (Jul 05 2020 at 04:59, on Zulip):

so yeah it's a common convention

André Arko (Jul 05 2020 at 04:59, on Zulip):

yeah, makes sense! I clearly have never built linux distro packages before :)

eddyb (Jul 05 2020 at 05:02, on Zulip):

@simulacrum what do you think about replacing build/$triple/stage$n-$foo with just build/stage$n-$foo? given that inside each of those, there's $triple/release already for the target, as per Cargo. although maybe this is a half-baked idea

eddyb (Jul 05 2020 at 05:03, on Zulip):

maybe build/$triple is for the "build" triple which if you changed, a different beta would be downloaded, right? so it'd make sense to keep the current stratification

eddyb (Jul 05 2020 at 05:04, on Zulip):

but then why would this:

so (iirc) the configuration was build="x86_64-apple-darwin" and host=["aarch64-apple-darwin"]

result in build/aarch64-apple-darwin existing?

simulacrum (Jul 05 2020 at 11:37, on Zulip):

Otherwise you'd clobber the stage2/bin/rustc (and everything else in there)

Jake Goulding (Jul 05 2020 at 12:34, on Zulip):

@simulacrum maybe the question i should be asking is "what is the right invocation of x.py?"

simulacrum (Jul 05 2020 at 12:34, on Zulip):

You're trying to produce a full toolchain, cross-compiling?

Jake Goulding (Jul 05 2020 at 12:35, on Zulip):

Yeah. I have one, but I'm doing copy-pasting of files myself.

Jake Goulding (Jul 05 2020 at 12:36, on Zulip):

https://github.com/shepmaster/rust/blob/silicon-bootstrap/silicon/README.md#copy-the-cross-compiler-to-the-dtk

simulacrum (Jul 05 2020 at 12:36, on Zulip):

I would look at one of the dist builders, say for ppc - IIRC, those cross compile currently so you can likely make use of the same invocation

simulacrum (Jul 05 2020 at 12:37, on Zulip):

(swapping dist for build perhaps)

Jake Goulding (Jul 05 2020 at 12:39, on Zulip):
 python3 ../x.py dist --host $HOSTS --target $HOSTS
Jake Goulding (Jul 05 2020 at 12:41, on Zulip):

That seems overly simple

simulacrum (Jul 05 2020 at 12:42, on Zulip):

Hm that looks about right. I'd try it

simulacrum (Jul 05 2020 at 12:42, on Zulip):

Target for std, host for rustc

Jake Goulding (Jul 05 2020 at 12:43, on Zulip):

So x.py dist --host aarch64-apple-darwin --target aarch64-apple-darwin and that will produce a single directory I could copy around?

Jake Goulding (Jul 05 2020 at 12:43, on Zulip):

Can I mix in a stage 1 in there too?

simulacrum (Jul 05 2020 at 12:43, on Zulip):

Should, I think, yeah

simulacrum (Jul 05 2020 at 12:43, on Zulip):

I think so

Jake Goulding (Jul 05 2020 at 12:44, on Zulip):

s/dist/build/

simulacrum (Jul 05 2020 at 12:44, on Zulip):

Though it won't speed things up I imagine

simulacrum (Jul 05 2020 at 12:44, on Zulip):

Since you're building the compiler again anyway

simulacrum (Jul 05 2020 at 12:44, on Zulip):

I could be wrong though

Jake Goulding (Jul 05 2020 at 12:46, on Zulip):

It is the nature of the beast

eddyb (Jul 05 2020 at 14:10, on Zulip):

@Jake Goulding in case you didn't see it, I suggested using DESTDIR=some/empty/dir x.py install instead of copying things from the build directory

eddyb (Jul 05 2020 at 14:10, on Zulip):

wasn't sure what dist does but it sounds similar

Jake Goulding (Jul 05 2020 at 14:12, on Zulip):

Dist produces the .gz and .xz files. Install is probably more want I want for “copy things around”

eddyb (Jul 05 2020 at 14:12, on Zulip):

simulacrum said:

Otherwise you'd clobber the stage2/bin/rustc (and everything else in there)

if you're not going to execute it, why should it be in stageN/bin/rustc?

eddyb (Jul 05 2020 at 14:13, on Zulip):

@Jake Goulding note that the intended "automated distro build" workflow is ./configure ... && make && make DESTDIR=... install

eddyb (Jul 05 2020 at 14:13, on Zulip):

so you don't even need to touch x.py or config.toml if you want to automate this

Jake Goulding (Jul 05 2020 at 14:15, on Zulip):

"automate" is not quite a goal, beyond allowing rustup install. Mostly just documenting what we need to do as we get to there.

eddyb (Jul 05 2020 at 14:16, on Zulip):

fair enough. I wonder if you can make x.py dist work with rustup install without having the components published on the official server, I sadly doubt it because I've seen a separate tool being needed even just to install PR artifacts (which are similar to nightlies but on a different S3 bucket or something)

Jake Goulding (Jul 05 2020 at 14:17, on Zulip):

Yeah. I think I asked about something similar before — would have loved to publish AVR-enabled rustc builds that were usable by rustup somehow.

eddyb (Jul 05 2020 at 14:17, on Zulip):

@simulacrum basically I'm suggesting that the triple in build/$triple always be the build triple (and all of the sysroots would be of that triple), and host triples would only exist under e.g. stageN-rustc/$triple/release

eddyb (Jul 05 2020 at 14:18, on Zulip):

@simulacrum and only x.py install / x.py dist would know how to create a sysroot for a host triple different than the build triple

eddyb (Jul 05 2020 at 14:18, on Zulip):

is that too convoluted? idk

simulacrum (Jul 05 2020 at 14:18, on Zulip):

oh it's probably possible, just not what we do today and may break some expectations

simulacrum (Jul 05 2020 at 14:18, on Zulip):

seems like a "good" change though generally speaking

eddyb (Jul 05 2020 at 14:19, on Zulip):

also if this works the next question is "do we need the stratification of build/$triple or can we just expect the build triple to just never change on a given system"

simulacrum (Jul 05 2020 at 14:19, on Zulip):

IIRC someone complained when I said it probably never changes, iirc talking about running i686 and x86_64 compilers on the same platform or something

simulacrum (Jul 05 2020 at 14:19, on Zulip):

(i.e., build compilers)

Jake Goulding (Jul 05 2020 at 14:19, on Zulip):

Ditto x86_64 and aarch64 in my case :-)

eddyb (Jul 05 2020 at 14:20, on Zulip):

no, build triples you have to be able to run on the machine you're building on

Jake Goulding (Jul 05 2020 at 14:20, on Zulip):

Yes, and the new apple machines can run both :-)

eddyb (Jul 05 2020 at 14:20, on Zulip):

you have a x86_64 build triple and a aarch64 host triple

simulacrum (Jul 05 2020 at 14:20, on Zulip):

wrt to making rustup work, you can do it if you don't mind being "nightly" or "beta" or "stable"

eddyb (Jul 05 2020 at 14:20, on Zulip):

@Jake Goulding sure, that's why I kept asking confusing questions last night :P

simulacrum (Jul 05 2020 at 14:20, on Zulip):

(we do so for say dev-static)

simulacrum (Jul 05 2020 at 14:21, on Zulip):

RUSTUP_DIST_SERVER=https://dev-static.rust-lang.org rustup -v update stable with a URL that's to, say, jakes-apple-builds.com would in theory work, you'd just need the same directory structure and manifests

eddyb (Jul 05 2020 at 14:21, on Zulip):

(because it wasn't clear what machine these dirs were on. IMO the only reasons to have more than one dir under build/ is 32-bit vs 64-bit or musl vs glibc, that sort of t hing)

simulacrum (Jul 05 2020 at 14:22, on Zulip):

even then we can probably say "edge case" and tell people to use different build/ directories

eddyb (Jul 05 2020 at 14:22, on Zulip):

@simulacrum huuuuh do PR builds not work like that because rustup doesn't understand their versioning?

simulacrum (Jul 05 2020 at 14:22, on Zulip):

well rustup has 3 channels

Jake Goulding (Jul 05 2020 at 14:23, on Zulip):

it wasn't clear what machine these dirs were on

Yep, we've been bouncing around a bit — as you do when getting a new platform going :-)

simulacrum (Jul 05 2020 at 14:23, on Zulip):

maybe you could finagle the PR builds as "future nightlies" but there's not really support in rustup for hashes I think

simulacrum (Jul 05 2020 at 14:23, on Zulip):

it's long been on my todo list to try and get that support integrated

eddyb (Jul 05 2020 at 14:23, on Zulip):

NixOS patches rustup to auto-patch toolchains to work directly, so anything that uses rustup as a dependency, as opposed to executing the one on the system, will be missing the requisite patchelf invocations :(

eddyb (Jul 05 2020 at 14:23, on Zulip):

I have a bunch of patchelf commands in my fish history so this isn't too bad but I don't like it very much

eddyb (Jul 05 2020 at 14:24, on Zulip):

@simulacrum anyway, thanks for the explanation! I was mostly trying to clean up my own understanding. and hoping we can make this less confusing in the future

eddyb (Jul 05 2020 at 14:25, on Zulip):

@Jake Goulding sure, but based on having both dirs under build/ I thought this was a machine that could run both, but that was wrong (as made clear by @André Arko)

Jake Goulding (Jul 05 2020 at 14:26, on Zulip):

Well, it depends who and when you ask :wink:. I currently am building the rustc compiler on the aarch64 machine. that machine can run both aarch64 and x86-64 binaries natively.

eddyb (Jul 05 2020 at 14:26, on Zulip):

uhhhhhhh @André Arko claimed the situation you were in was on a x64 machine

Jake Goulding (Jul 05 2020 at 14:27, on Zulip):

"natively" as in ./some-x86-binary and ./some-aarch64-binary; there's still some emulation happening somewhere

Jake Goulding (Jul 05 2020 at 14:27, on Zulip):

That's what I mean by "when". At one point we only were able to cross-compile. Now we are able to natively compile.

Jake Goulding (Jul 05 2020 at 14:28, on Zulip):

But I'm still doing steps on both machines, in order to be able to reproduce this elsewhere.

eddyb (Jul 05 2020 at 14:28, on Zulip):

@simulacrum the thing that is fascinating to me and which wasn't really there ages ago in this form, is the existence of stageN-X/$triple/release, which comes from how Cargo target dir works I guess, and which can service both host and target triples equally, leaving stageN-X/release to be the build triple, implicitly

simulacrum (Jul 05 2020 at 14:29, on Zulip):

hm yeah that's been a thing in cargo for as long as I remember but maybe we weren't always passing --target to cargo? not sure

eddyb (Jul 05 2020 at 14:29, on Zulip):

we weren't using Cargo pre-"rustbuild" :P

simulacrum (Jul 05 2020 at 14:30, on Zulip):

oh right

eddyb (Jul 05 2020 at 14:30, on Zulip):

and I'm not sure we've fully looked into the consequences of that - another example is the effort being put into making "rustbuild" less necessary for doing builds, and relying on Cargo more

eddyb (Jul 05 2020 at 14:30, on Zulip):

@Jake Goulding oh btw, speaking of this whole thing, are you aware of the person trying to get aarch64 builds going, on Discord?

eddyb (Jul 05 2020 at 14:30, on Zulip):

they had a lot of trouble and I wasn't sure who to point them to

Jake Goulding (Jul 05 2020 at 14:31, on Zulip):

which channel?

eddyb (Jul 05 2020 at 14:31, on Zulip):

#compiler, scroll up and you'll find a bunch of stuff

eddyb (Jul 05 2020 at 14:31, on Zulip):

I expected other people would also try to do this sort of thing, and that someone would know more about LLVM and buildsystems, enough to deal with everything quicker, I just didn't know who to point them to

eddyb (Jul 05 2020 at 14:32, on Zulip):

they eventually got rustc running on iOS

Jake Goulding (Jul 05 2020 at 14:32, on Zulip):

yeah, the ios person

Jake Goulding (Jul 05 2020 at 14:33, on Zulip):

I think this is them https://github.com/rust-lang/rust/issues/73628

eddyb (Jul 05 2020 at 14:33, on Zulip):

I just feel bad if they wasted their time

eddyb (Jul 05 2020 at 14:33, on Zulip):

due to lack of coordination

Jake Goulding (Jul 05 2020 at 14:33, on Zulip):

jokes on you, I know nothing, other than to ask smarter people :wink:

eddyb (Jul 05 2020 at 14:33, on Zulip):

I mean idk who the macOS ppl are

eddyb (Jul 05 2020 at 14:34, on Zulip):

other than acrichto who is probably too busy

eddyb (Jul 05 2020 at 14:34, on Zulip):

that issue sounds relevant but I wonder if there's two people

eddyb (Jul 05 2020 at 14:36, on Zulip):

oh, @aspen, they're on here as well

Jake Goulding (Jul 05 2020 at 14:39, on Zulip):

The main place for ARM stuff is #t-compiler/arm. I've just been popping out into other streams for help from a broader perspective

Jake Goulding (Jul 05 2020 at 14:39, on Zulip):
  DESTDIR=/tmp/crossed \
  ../../x.py install --stage 1 --host aarch64-apple-darwin --target aarch64-apple-darwin,x86_64-apple-darwin --warnings warn

Does seem to do what I'd want though!

eddyb (Jul 05 2020 at 14:40, on Zulip):

nice :D

Jake Goulding (Jul 05 2020 at 14:41, on Zulip):
% cargo new hello-world
% cd hello-world

% cargo +installed-cross run
Hello, world!

% file target/debug/hello-world
target/debug/hello-world: Mach-O 64-bit executable arm64

% cargo +installed-cross run --target=x86_64-apple-darwin
Hello, world!

% file target/x86_64-apple-darwin/debug/hello-world
target/x86_64-apple-darwin/debug/hello-world: Mach-O 64-bit executable x86_64
Jake Goulding (Jul 05 2020 at 14:43, on Zulip):
% lipo -output hello-world -create target/{,x86_64-apple-darwin}/debug/hello-world
% file hello-world
hello-world: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64]
hello-world (for architecture x86_64):  Mach-O 64-bit executable x86_64
hello-world (for architecture arm64):   Mach-O 64-bit executable arm64
eddyb (Jul 05 2020 at 14:50, on Zulip):

isn't there a cargo-lipo as well :P?

Jake Goulding (Jul 05 2020 at 14:54, on Zulip):

I know of it, but I've never used it. Figured I'd do the simpler thing for now. I'm sure that project will be picking up steam soon.

Last update: Jan 22 2021 at 13:15UTC