[bug] Incorrect llvm target

[JonasKruckenberg]

Describe the bug

tauri/tooling/bundler/src/bundle/platform.rs

Lines 27 to 30 in 9bb6897

	let output = Command::new("rustc")
	.args(&["-Z", "unstable-options", "--print", "target-spec-json"])
	.env("RUSTC_BOOTSTRAP", "1")
	.output()?;

This line uses the rust compiler to identify the current target arch, which is problematic for two reasons:

1. It uses nightly rust through an undocumented semi-private environment variable even if the users chose a stable rust toolchain
2. It identifies the arch incorrectly. It identifies my m1 macbook pro as arm64-apple-macosx11.0.0 (it even identifies my colleagues macbook as x86_64-apple-macosx10.12.0)

Reproduction

1. Install or update rust
2. run RUSTC_BOOTSTRAP=1 rustc -Z unstable-options --print target-spec-json

Expected behavior

It should correctly identify the current target as aarch64 (the arch property of the same json object even correctly states aarch64).

Platform and versions

Operating System - Mac OS, version 12.2.0 X64

Node.js environment
  Node.js - 16.5.0
  @tauri-apps/cli - 1.0.0-beta.10
  @tauri-apps/api - Not installed

Global packages
  npm - 8.3.1
  pnpm - 6.27.2
  yarn - 1.22.17

Rust environment
  rustc - 1.58.1
  cargo - 1.58.0

Rust environment
  rustup - 1.24.3
  rustc - 1.58.1
  cargo - 1.58.0
  toolchain - stable-aarch64-apple-darwin (environment override by RUSTUP_TOOLCHAIN)

App directory structure
/node_modules
/scripts
/src-tauri
/src

App
  tauri.rs - path:"../../../core/tauri" [1.0.0-beta.8] (no lockfile)
  build-type - bundle
  CSP - default-src blob: data: filesystem: ws: wss: http: https: tauri: 'unsafe-eval' 'unsafe-inline' 'self'
  distDir - ["../index.html"]
  devPath - ["../index.html"]

Stack trace

No response

Additional context

We should use rustc --print cfg instead of RUSTC_BOOTSTRAP=1 rustc -Z unstable-options --print target-spec-json or even remove the whole command and just use the cfg! macros instead

[lucasfernog]

We need runtime check because the binary-releases repo does not compile the CLI for all archs, so cfg!() doesn't help us here.

[JonasKruckenberg]

I also realized the cargo env vars don't help at all, because we resolve the arch before we enter the cargo build context, so those env vars aren't set anyway.

Have a look at the PR though, we can use a different property on that json object.

[betamos]

Thanks a ton. I ran into this the other day as well and look now it's fixed!

[JonasKruckenberg]

The magic of bug fixes 😁