Rust: Apple 앱 스토어 비트코드 지원

우리는 LLVM을 동적으로 로드하도록 rustc를 변경하고, rust-llvm 패키지와 선택 사항인 rust-llvm-apple 패키지를 만들고, rustc는 비트코드를 처리하기 위해 사과 LLVM을 로드하도록 합니다.

LLVM을 동적으로 로드하는 것은 확실히 옵션이 아닙니다. LLVM API는 비트코드보다 덜 안정적이며 LLVM xy에 대해 빌드하는 경우 xy 대신 LLVM xz를 사용하면 거의 확실히 rustc가 중단됩니다. 시스템 LLVM에 정적으로 연결하기만 하면 됩니다( --llvm-root 이미 하는 것처럼).

우리는 rustc_llvm_apple 크레이트를 만들고 두 개의 전체 LLVM을 항상 rustc에 연결합니다. 이것은 아마도 날지 않을 것입니다

사과 배포를 위해 시스템 LLVM(정적으로)을 연결하기만 하면 됩니다. 내 경험상 이미 잘 작동합니다.

우리는 우리의 비트코드를 그들의 비트코드로 번역하기 위해 비트코드 소독제를 조사할 수 있습니다. 유지 보수가 있기 때문에 성공 가능성은 낮다고 생각합니다. 나는 RenderScript가 이것을 한다고 믿습니다.

좋아요... 그래서 문제는 LLVM 비트코드 형식이 LLVM 버전 간에 다소 안정적이라는 것입니다. 사과는 사실이 아닌 것을 만들기 위해 이상한 일을 합니까? 아니면 비트코드 형식이 LLVM이 아닌(예: 사과 관련 항목이 있음) 사용됩니까?

2013년에 LLVM 비트코드를 배포 형식으로 사용하는 것은 어리석다는 말을 들은 것 같습니다. 나는 확실히 동의합니다. iOS에서 네이티브 바이너리 라이브러리 배포가 더 이상 작동하지 않습니까?

또한 Apple이 내부적으로 호환되지 않는 비트코드 형식을 사용하는 LLVM 버전으로 업그레이드하고 사람들이 여전히 오래된 컴파일러로 컴파일할 때 어떤 일이 일어날지 매우 관심이 있습니다.

나는 이것에 대해 간략하게 실험했습니다. 즉, 화물 빌드 동안 출력 비트코드를 사용한 다음 비트코드가 포함된 정적 라이브러리를 만들려고 했습니다. 비트코드 라이브러리에 대해 llvm-링크를 시도했을 때 비트코드에서 호환되지 않는 LLVM 버전을 얻었습니다.

이것을 재현할 수 있는 쉬운 테스트가 없지만 내 생각에는 다른 LLVM 버전 간의 연결을 거부하는 멍청한 버전 검사가 있는 것 같습니다. 아니면, 내가 완전히 잘못된 일을 했을 뿐입니다. 나는 이것을 다시 볼 시간이있을 때 테스트 케이스를 생각해 내기 위해 노력할 것입니다.

llvm-link의 정확한 오류 메시지가 있으면 유용할 것입니다.

@bluejekyll LLVM의 테스트 디렉토리에는 많은 비트코드 파일이 있습니다. 이러한 비트코드 파일에 대한 테스트는 지속적으로 실행되므로(예: llvm-dis-3.8/opt-3.8은 3.2에서 3년 된 비트코드 파일을 잘 이해합니다), 일부 사과 항목이어야 합니다.

사과 배포를 위해 시스템 LLVM(정적으로)을 연결하기만 하면 됩니다. 내 경험상 이미 잘 작동합니다.

이것은 말보다 쉽지가 않습니다. 제가 아는 한, App Store 업로드를 위한 유일한 축복받은 apple-llvm 버전은 현재 Xcode와 함께 제공되는 버전입니다. 이것은 또한 잠재적으로 두 개의 LLVM 버전에 대한 LLVM 바인딩을 유지하는 것을 의미합니다(반드시 인접한 두 개의 마이너 버전일 필요는 없음). 이전 버전의 apple-llvm을 사용하는 것이 유효하지 않다고 생각합니다.

또한 Apple이 내부적으로 호환되지 않는 비트코드 형식을 사용하는 LLVM 버전으로 업그레이드하고 사람들이 여전히 오래된 컴파일러로 컴파일할 때 어떤 일이 일어날지 매우 관심이 있습니다.

나는 그들이 최신 Xcode가 앱을 제출하도록 허용함으로써 이것을 피한다고 생각합니다.

IIRC에서는 아키텍처 간 비트코드가 clang에 의해 생성되지 않기 때문에 각 아키텍처에 대해 비트코드가 패키지됩니다(일반적으로 이것이 clang 및 비트코드의 반대 목표라고 생각합니다). 각 오브젝트 파일에 대한 섹션에 저장되므로 최소한 복제됩니다. 누군가 비트코드가 이에 대한 최선의 방법이 아닐 수도 있다고 언급한 이유 중 일부일 수 있습니다.

권장되는 모든 솔루션이 다소 엉뚱한 것 같은 느낌이 듭니다. 내가 생각할 수 있는 가장 지저분한 방법은 다른 대상이 codegen 동작을 오버로드하도록 허용하고 Apple codegen 경로가 동적 크레이트에 있도록 하는 것입니다. (apple-llvm에 대해 컴파일된 일반 codegen 경로일 뿐입니다.)

이 버그가 App Store를 언급하기 때문에 여기서 예외 처리에 대해 이야기할 가치가 있습니까? (즉, 현재 panic=abort 는 엄격하게 필요합니다.)

LLVM의 테스트 디렉토리에는 많은 비트코드 파일이 있습니다. 이러한 비트코드 파일에 대한 테스트는 지속적으로 실행되므로(예: llvm-dis-3.8/opt-3.8은 3.2에서 3년 된 비트코드 파일을 잘 이해합니다), 일부 사과 항목이어야 합니다.

@nagisa 알려 주셔서 감사합니다. 여기에 아직 해결책이 있을 수 있다는 희망과 내가 뭔가 잘못하고 있는 것 같다는 희망을 줍니다.

@ricky26 좋은 점.

내가 아는 한, App Store 업로드를 위한 유일한 축복된 apple-llvm 버전은 현재 Xcode와 함께 제공되는 버전입니다.

Apple의 Xcode LLVM은 시스템 LLVM과 동일하지 않습니까? 나는 그때 Xcode LLVM을 의미했습니다. Rustc 열차를 배송할 때 xcode가 항상 최신 버전인지 확인해야 합니다.

물론 Apple이 작업하는 방식은 우리가 이전 버전의 rustc로 유효한 사과 비트코드를 생성하는 것을 배제하고 본질적으로 우리의 안정성 스토리가 제공하는 모든 이점을 창 밖으로 던지도록 강요하며 이것이 고칠 수 있는 방법이 보이지 않습니다.

이것은 또한 잠재적으로 두 개의 LLVM 버전에 대한 LLVM 바인딩을 유지해야 함을 의미합니다.

우리는 이미 LLVM 버전 3.7에서 3.9(및 잠재적으로 트렁크)에 대한 지원을 유지합니다. Xcode의 LLVM이 고대 버전이 아닌 한 우리는 그런 점에서 좋다고 생각합니다. Xcode LLVM이 실제로 고대/사용자 정의/기타 버전이라면 이 기능을 전혀 지원할 수 없다고 봅니다. 특히 필요한 기능을 추가하기 위해 _that_ LLVM에 패치를 보낼 수 있는 옵션이 없기 때문에 특히 그렇습니다. 또한 Apple이 2038년까지 Xcode LLVM을 업데이트하지 않기로 결정한 경우에 대비하여 3.7을 영원히 지원하도록 rustc를 잠그고 싶지 않습니다.

¹: 그러나 Rustc가 LLVM xy에 대해 빌드된 경우 LLVM xy에 정확히 연결되어야 합니다.

LLVM을 동적으로 로드하는 것은 확실히 옵션이 아닙니다. LLVM API는 비트코드보다 덜 안정적이며 LLVM xy에 대해 빌드하는 경우 xy 대신 LLVM xz를 사용하면 거의 확실히 rustc가 중단됩니다. 시스템 LLVM에 정적으로 연결하기만 하면 됩니다(예: --llvm-root가 이미 하고 있음).

@nagisa C++ API는 불안정하지만 우리는 C API를 사용하고 있으며 한 번에 여러 버전의 LLVM을 지원하는 데 많은 성공을 거두었습니다. API 지원 측면에서 차이점이 보이지 않습니다.

사과 배포를 위해 시스템 LLVM(정적으로)을 연결하기만 하면 됩니다. 내 경험상 이미 잘 작동합니다.

모든 Apple 플랫폼에 대해 Apple의 LLVM을 일괄 배송할 수 있지만 이는 데스크톱 기계 코드 생성을 위해 LLVM을 Apple에 결합하는 것을 의미하며 Apple이 아닌 호스트에서 iOS 비트코드를 지원하는 옵션을 배제합니다.

좋아요... 그래서 문제는 LLVM 비트코드 형식이 LLVM 버전 간에 다소 안정적이라는 것입니다. 사과는 사실이 아닌 것을 만들기 위해 이상한 일을 합니까? 아니면 비트코드 형식이 LLVM이 아닌(예: 사과 관련 항목이 있음) 사용됩니까?

비트코드 형식은 버전 간에 안정적이지 않습니다.

iOS에서 네이티브 바이너리 라이브러리 배포가 더 이상 작동하지 않습니까?

그것은 오늘 작동합니다. 선호하는 방법이 아니며 계속 지원될지는 확실하지 않습니다.

이것은 또한 잠재적으로 두 개의 LLVM 버전에 대한 LLVM 바인딩을 유지하는 것을 의미합니다(반드시 인접한 두 개의 마이너 버전일 필요는 없음). 이전 버전의 apple-llvm을 사용하는 것이 유효하지 않다고 생각합니다.

@ricky26 여러 버전의 LLVM 간에 호환성을 성공적으로 유지하고 있습니다. Apple과 우리가 너무 멀리 떨어져 있지 않는 한 가능해야 하지만 분할을 넘을 수 없을 정도로 큰 파손의 위험이 항상 존재하며 주요 API 변경 사항이 있을 것임을 알고 있습니다.

Xcode의 LLVM이 고대 버전이 아닌 한 우리는 그런 점에서 좋다고 생각합니다.

이 페이지에서 https://gist.github.com/yamaya/2924292 :

clang-700.0.72 => LLVM 3.7.0
clang-700.1.76 => LLVM 3.7.0
clang-700.1.81 => LLVM 3.7.0
clang-703.0.29 => LLVM 3.8.0
clang-703.0.31 => LLVM 3.8.0

C++ API는 불안정하지만 C API를 사용하며 한 번에 여러 버전의 LLVM을 지원하는 데 많은 성공을 거두었습니다. API 지원 측면에서 차이점이 보이지 않습니다.

그것은 사실이 아니다. 우리는 Rustllvm의 형태로 C++ API에 대한 많은 바인딩을 가지고 있습니다. 컴파일된 LLVM 버전에 따라 래퍼를 컴파일하는 경우가 많이 있습니다. 사용 및 컴파일된 LLVM의 버전이 일치하지 않는 경우 동적 링커 오류가 발생하거나 더 심하게는 런타임에 문제가 발생합니다.

Apple이 아닌 호스트에서 iOS 비트코드를 지원하는 옵션을 배제합니다.

Apple이 LLVM 포크 이외의 다른 것으로 생성된 비트코드를 원하지 않는다면 유사한 포크를 유지하고 내부 패치를 리버스 엔지니어링하는 것 외에는 어떻게 할 수 있는지 알 수 없습니다.

비트코드 형식은 버전 간에 안정적이지 않습니다.

물론입니다. 그러나 예를 들어 3.7.0으로 알려진 LLVM의 다양한 개정판 사이의 비트코드는 3.7.0 시리즈의 다른 LLVM 빌드에서 사용할 비트코드를 생성하기 위해 충분히 호환 가능하다고 가정하는 것이 공정합니다. libLLVM에 동적으로 연결하는 것보다 확실히 낫습니다.

¹: 특히 3.2 시리즈의 비트코드가 매우 작은 표본일지라도 3.8 LLVM과 여전히 호환된다는 점을 고려할 때.

몇 가지 참고 사항:

• Xcode는 연결 가능한 libLLVM(정적 또는 동적)과 함께 제공되지 않고 LLVM에 정적으로 연결되는 libclang.dylib만 제공됩니다.
• Apple은 https://opensource.apple.com의 '개발자 도구' 아래에 있는 'clang'(LLVM 포함)으로 소스를 제공하지만 해당 사이트는 업데이트되는 데 영원히 걸리는 경향이 있습니다.
• 릴리스 태그 가 있는 자체 LLVM 포크가 있는 Swift의 경우 이야기가 더 나을 수 있지만 Xcode와 함께 제공되는 것과 완벽하게 일치하지 않을 수 있습니다. (Xcode와 함께 오픈 소스 도구 체인 스냅샷을 사용할 수 있지만 이러한 도구 체인으로 빌드된 프로젝트는 App Store에 제출할 수 없습니다.)

cc @rust-lang/컴파일러

다른 프로그래밍 언어가 이 문제를 어떻게 처리할 계획인지 듣고 싶습니다. 특히 모노 앤 고.

이 문제에 대한 Unity의 대답은 모든 IL 어셈블리를 C++ 코드로 빌드하는 il2cpp입니다.

관련 golang 버그: https://github.com/golang/go/issues/12682; LLVM go 도구 체인(표준 go 도구 체인만큼 기능하지 않음)을 사용할 수 있다는 제안이 있습니다.

대체로 Apple 외부의 비트코드 지원에 대한 이야기는 좋지 않습니다.

적절한 Mono는 Apple LLVM을 통해 표시됩니다. http://tirania.org/blog/archive/2015/Sep-02.html

한 가지 걸림돌은 비트코드로 인라인 어셈블리를 전달할 수 없다는 것입니다.

모노 이야기를 위해 나는 Mono가 호기심 많은 사람들을 위해 무엇을 하는지에 대해 Miguel de Icaza와 빠른 교환을 했습니다: https://twitter.com/mitsuhiko/status/769458873237434368

@mitsuhiko iOS 및 tvOS에서는 비트코드로 인라인 어셈블리를 _할 수_ 있지만 어떤 이유로 watchOS는 없습니다.

이에 대한 움직임이 있습니까? 비트코드 지원 계획 없이 iOS에서 Rust를 사용하는 것은 전혀 기분이 좋지 않습니다. 애플은 이런 옵셔널을 상당히 갑자기 비 옵셔널로 만든 역사가 있고 실제로 비트코드는 이미 watchOS와 tvOS에서 필요합니다.

권장되는 모든 솔루션이 다소 엉뚱한 것 같은 느낌이 듭니다. 내가 생각할 수 있는 가장 지저분한 방법은 다른 대상이 codegen 동작을 오버로드하도록 허용하고 Apple codegen 경로가 동적 크레이트에 있도록 하는 것입니다. (apple-llvm에 대해 컴파일된 일반 codegen 경로일 뿐입니다.)

이 접근 방식(@ricky26)은 Rustc 사용자인 저에게 가장 자연스러운 것 같습니다.

나는 최근에 적어도 내가 아는 한 이것에 대해 아무것도 바뀌지 않았다고 생각합니다. 버전 관리에 대한 LLVM의 최근 발표 에서 비트코드는 (내 생각에) 항상 LLVM의 향후 버전에서 로드할 수 있어야 한다고 표시했습니다. 이는 이 문제가 근본적인 수준에서 "해결됨"을 의미 할 수 있지만 모든 비트코드를 추출하려면 더 인체공학적인 인터페이스가 여전히 필요합니다.

이에 대한 업데이트가 있습니까?

HackerNews의 이 댓글 작성자는 macOS 및 iOS에서 Rust에서 생성된 Bitcode를 사용하는 데 성공했습니다. 스레드에는 Rust 바이너리에 대한 비트코드를 활성화하는 방법에 대한 자세한 정보가 있습니다. 이것은 좋은 소식처럼 들립니다!

https://news.ycombinator.com/item?id=14305084

문제의 댓글 작성자는 다음과 같이 간략히 설명합니다.

• -C lto --emit llvm-bc 를 사용하여 현재 상자와 모든 종속성을 포함하는 하나의 .bc 파일을 내보내도록 rustc를 가져왔습니다. 이것은 작동하지만 본질적으로 해킹입니다. 특히 jemalloc을 포함한 C 종속성에서는 작동하지 않습니다(어쨌든 iOS에서는 사용되지 않음). Rustc가 "내장된 비트코드"로 Mach-O 방출을 적절히 지원한다면 더 좋을 것입니다. clang 소스를 보고 어떻게 완료되었는지 확인할 수 있습니다.

• 그것을 시도하고 해킹에 신경 쓰지 않는다면 버전 문제를 제외하고는 '그냥 작동'하는 것 같습니다.

• 주요 실제 장애물은 Rust가 Xcode보다 더 자주 LLVM 트렁크와 동기화한다는 것입니다. Xcode는 매년 그렇게 하는 것으로 보입니다. 최신 LLVM 버전은 이전 비트코드를 로드할 수 있지만 그 반대는 불가능하므로 이전 버전의 rustc를 사용하거나 이전 LLVM에 대해 최신 버전을 빌드해야 합니다. (사실, Rustc 1.17은 여전히 ​​Xcode 8.x에서 작동하는 것 같지만 LLVM 4.0 업그레이드 이후로 야간에는 작동하지 않습니다. 그것은 단지 우연의 일치입니다.)

• 이상적으로 Rust는 적절한 LLVM 버전에 대해 빌드된 공식 바이너리를 제공합니다. 실제로는 올바른 버전의 스톡 LLVM을 사용하는 것이 좋은 것 같지만 Apple의 포크를 사용하려는 경우:

  • 이전 의견에서 말했듯이 Xcode는 동적으로 연결 가능한 형태로 LLVM 바이너리를 제공하지 않습니다. clang 및 libclang.dylib만(Clang API는 내보내지만 LLVM은 내보내지 않음).
  • 그러나 내가 또한 말했듯이 소스 코드는 일반적으로 약간 일관성이 없이/지연 후에 opensource.apple.com(개발자 도구 -> clang 아래, 아카이브에는 모든 LLVM 포함)에 올라갑니다. 그러나 특히 @alexcrichton이 언급한 확장된 하위 호환성 보장을

(테스트로 방금 Xcode 8.2.1 Clang에 대해 Rust를 컴파일하려고 시도했습니다. rustllvm 는 빌드에 실패합니다. #if LLVM_VERSION_GE(..) 조건문 중첩으로 인해 두 가지 모두에 대해 컴파일할 수 있기 때문입니다. 이전 및 최신 LLVM은 LLVM 3.9svn이라고 주장하지만 API 방식은 3.8과 3.9 사이에 있는 이 분기로 인해 혼란스러워집니다. Xcode는 어쨌든 다음 해마다 새로 고칠 예정이므로 수정할 가치가 없을 것입니다.)

이 부분에서 진전이 있었습니까? 대안으로 당신(핵심 팀)은 이 시련을 확실한 영구적인 수정이 있는 문제로 간주하시겠습니까, 아니면 이 버전 호핑이 가까운 장래에 유지될 것으로 예상하십니까?

저는 iOS 앱의 우수한 유형 시스템과 저수준 의미 체계를 위해 Rust에서 iOS 앱의 일부를 구현하는 것을 고려하고 있으며 Xcode 또는 Rustc에 대한 업데이트가 있을 때마다 비트코드가 아닌 일반 핵/지연에 얽매이지 않을 것입니다.

@regexident

다른 이유로 교체 가능한 LLVM 버전을 구현할 것이라고 생각합니다. 이것이 구현된다면 Apple, wasm 및 기타 모든 제품에 대해 별도의 트랜스를 배송하는 데 문제가 없을 것입니다.

참조 #45684

https://medium.com/@FredericJacobs/why -im-not-enabling-bitcode-f35cd8fbfcc5 빌드 확인이 불가능합니다. 암호화 문제. 등.

@burdges 특정 앱의 경우 이것은 절대적으로 문제입니다.

그러나 watchOS 및 tvOS의 경우 Apple은 실제로 App Store 제출을 위해 Bitcode를 요구합니다. 선택의 여지가 없습니다. "해당 플랫폼에서 암호화 또는 중요한 작업을 수행하지 마십시오" 외에는. 또한 미래의 어느 시점에서 Apple이 iOS용 Bitcode를 시행하는 것을 두려워해야 합니다. 나는 그 시점에서 벽돌로 된 제품을 가지고 있지 않는 것이 좋습니다.

-C lto --emit=llvm-bc 트릭을 사용하여 iOS용 Rust 1.24.0으로 빌드를 시도했지만 링커에서 다음 오류가 발생했습니다.

Undefined symbols for architecture x86_64:
  "_backtrace_create_state", referenced from:
      std::sys_common::gnu::libbacktrace::init_state::h686c3e443c712b0f in Logger(x86_64.o)
  "_backtrace_syminfo", referenced from:
      std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::h598a932d5bb0d80b in Logger(x86_64.o)
      core::iter::iterator::Iterator::position::_$u7b$$u7b$closure$u7d$$u7d$::hbf03153d55553502 in Logger(x86_64.o)
  "_backtrace_pcinfo", referenced from:
      std::panicking::default_hook::_$u7b$$u7b$closure$u7d$$u7d$::h598a932d5bb0d80b in Logger(x86_64.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

어떤 아이디어가 문제가 될 수 있습니까?

편집: 각 public extern fn의 모든 코드를 AssertUnwindSafe 로 래핑하여 해당 문제를 최소한 억제할 수 있는 것으로 보입니다.

libbacktrace는 Rust 소스 트리에 포함된 C 라이브러리입니다:

https://github.com/rust-lang/rust/tree/master/src/libbacktrace

어떻게든 비트코드로 컴파일해야 합니다.

내 랩톱용으로 빌드된 libbacktrace만 찾을 수 있지만 전화 OS용은 아니기 때문에 혼란스럽습니다. 녹은 어떻게 해당 기호를 stdlib에 삽입합니까? 어떻게든 역추적 기능을 비활성화하여 이를 수행하는 더 쉬운 방법이 있습니까? RUST_BACKTRACE 환경 변수를 제거했지만 도움이 되지 않았습니다. 나는 당신이 역추적 없이 Rustc를 컴파일할 수 있다는 것을 읽었지만, 내 프로젝트의 화물.toml 파일과 같이 더 쉬운 것을 원했습니다.

기본적으로 당신은 C 컴파일러에 -fembed-bitcode 를 전달하라고 말하면서 Rustc 소스 트리를 만들고 싶습니다. 이상적으로는 CFLAGS 에 추가할 수 있습니다. 불행히도 방금 시도했지만 gcc-rs (rustc의 빌드 시스템에서 C 종속성을 빌드하는 데 사용)의 두 가지 문제로 인해 제대로 작동하지 않았습니다. 그러나 약간의 해킹 절차로 작동하도록 했습니다.

cd /tmp/build
cat >ccwrap.py <<END

#!/usr/bin/env python
import os, sys
os.execv('/usr/bin/xcrun', ['clang', '-fembed-bitcode'] + [arg for arg in sys.argv[1:] if arg not in {'-ffunction-sections', '-fdata-sections'}])

END

chmod 755 ccwrap.py
ln -s /usr/bin/ar ar
export CC_aarch64_apple_ios=`pwd`/ccwrap.py
/usr/src/rust/configure --target=aarch64-apple-ios
make

비트코드가 포함된 libbacktrace.a ( ./build/aarch64-apple-ios/native/libbacktrace/.libs/ )를 얻을 수 있습니다. __LLVM,__bitcode 에 비트코드를 포함하는 것입니다 __LLVM,__bitcode 섹션: 그러면 .bc 파일을 수동으로 컴파일하고 링크할 필요가 없습니다.

(사실, 인용하신 오류는 일반 링커 오류처럼 보이기 때문에 비트코드가 포함되지 않은 일반 libbacktrace.a 을 연결하는 것만으로도 지나칠 수 있다고 생각합니다. 하지만 기껏해야 출력 파일이 생성될 것입니다. 포함된 비트코드가 깨짐)

앞서 언급한 문제:

• gcc-rs는 -ffunction-sections 및 -fdata-sections 를 해제할 방법 없이 전달합니다. clang은 -fembed-bitcode 와 결합할 때 이에 대해 불평합니다( -fno-function-sections 가 나중에 전달되더라도).

문제 보고서를 제출했으며 해결 방법으로 위의 절차에서는 이러한 인수를 제거하는 래퍼 스크립트를 사용합니다. 그러나 두 번째 문제가 발생했습니다.

• GCC-RS 시도 찾을 ar 과 같은 디렉토리에 CC_aarch64_apple_ios (!?) AR_aarch64_apple_ios 수동으로 설정해도 효과가 없습니다.

최신 cc-rs ( gcc-rs 에서 이름 변경)으로 이것을 재현할 수 없어서 문제를 제기하지 않았습니다. 해결 방법으로 위의 절차는 ar 를 동일한 디렉토리에 심볼릭 링크합니다.

제안 감사합니다! 실제로 백트레이스 항목이 아닌 내 자신의 코드에 대한 비트코드가 필요했기 때문에 비트코드 임베딩 없이 컴파일된 libbacktrace를 사용했습니다.

내가 시도한 해킹으로 이제 dSYM을 만들려고 할 때 dsymutil segfaults라는 또 다른 문제가 발생합니다. dSYM이 없는 일반 실행은 잘 작동하지만 dSYM 생성이 어떤 이유로 중단되었습니다. 내 libbacktrace.a를 제거하고 빈 자리 표시자 기능으로 대체했는데 모든 것이 잘 작동했기 때문에 내 rust lib에 문제가 있는 것 같습니다.

그것은 LLVM에 업스트림으로 보고되어야 하는 dsymutil의 버그처럼 들립니다. LLDB에서 dsymutil을 실행하고 충돌의 역추적을 게시할 수 있습니까? 또는 더 나은 디버그 정보를 얻으려면 디버그 모드에서 LLVM을 빌드하고 이를 사용하여 재현할 수 있습니다.

(스톡 LLVM 설치의 바이너리는 llvm-dsymutil 라고 하지만 요즘 Xcode의 dsymutil 는 llvm-dsymutil 대한 심볼릭 링크일 뿐입니다. dsymutil 에는 별도의 비공개 소스 유틸리티이지만 몇 년 동안 해당 버전은 dsymutil-classic 로 배송되었으며 기본적으로 사용되지 않습니다.)

@comex 는 호기심에, cc 크레이트는 -fembed-bitcode 모든 것을 컴파일해야 합니까? 또는 "공식" clang을 사용하는 경우 비트코드를 포함하지 않아도 괜찮습니까?

(죄송합니다 제가 ios 모범 사례에 익숙하지 않습니다!)

Rust 코드 자체의 경우 객체 파일 대신 바이트 코드를 내보내는 것이 가장 좋습니까? Clang/링커가 이해할 수 있는 내용인가요?

@alexcrichton

cc 크레이트는 -fembed-bitcode 모든 것을 컴파일해야 합니까? 또는 "공식" clang을 사용하는 경우 비트코드를 포함하지 않아도 괜찮습니까?

공식 clang을 사용한다고 해서 포함된 비트코드가 필요하지 않은 것은 아닙니다. 오히려 비트코드는 네이티브 코드와 함께 Apple에 업로드된 앱 아카이브에 포함되고 Apple은 서버 측에서 이를 다시 컴파일하여 예를 들어 다양한 마이크로아키텍처에 최적화할 수 있습니다.

iOS/watchOS/tvOS에서 기본적으로 -fembed-bitcode 를 전달하는 것이 합리적일 것입니다. 그렇다면 디버그 모드에서 빌드할 때 -fembed-bitcode-marker 를 전달해야 합니다(대신 또는 추가로 상관 없음). 이것은 포함된 비트코드가 최종 앱 아카이브에만 필요하고 이를 생략하기 위해 컴파일 속도가 약간 빨라지기 때문에 clang이 실제 비트코드가 아닌 더미 비트코드 섹션만 포함하도록 지시합니다. 실제로 Xcode는 최종 앱 아카이브를 빌드하는 것 이외의 모든 것에 대해 -fembed-bitcode-marker 를 전달합니다. 심지어 최적화가 켜진 개발 빌드조차도 - 하지만 cc 에는 "진짜 최종 릴리스"라는 별도의 개념이 없기 때문에 모드", 디버그 모드에서 그냥 전달해야 합니다. 최종 빌드에 비트코드가 필요하지 않더라도 비트코드를 포함하는 것이 안전합니다.

Rust 코드 자체의 경우 객체 파일 대신 바이트 코드를 내보내는 것이 가장 좋습니까? Clang/링커가 이해할 수 있는 내용인가요?

clang과 ld 모두 입력으로 전달된 원시 비트코드 파일을 지원합니다. 이것은 일반적으로 LTO가 활성화된 경우( -flto ) 사용되며, 이 경우 clang이 생성하는 .o 파일은 Mach-O가 아니라 실제로 원시 비트코드입니다. (이것은 여전히 ​​일반 lipo 명령을 사용하여 정적 라이브러리로 구성할 수 있습니다.) 그러나 이것은 __LLVM,__bitcode 섹션에 채워진 비트코드가 있는 Mach-O로 구성된 "임베디드 비트코드" 형식과 별개입니다. 일반적인 섹션의 기본 코드에 추가합니다. 이 형식은 LTO가 꺼져 있을 때 개체 파일에서 사용되며 LTO 설정에 관계없이 최종 링크된 실행 파일이나 동적 라이브러리에서 사용됩니다. (LTO가 켜져 있으면 링커가 이 섹션을 생성하는 역할을 합니다. LTO가 꺼져 있으면 링커 는 단일 결합을 생성하는 대신 다른 섹션과 마찬가지로 각 개체 파일의 __LLVM,__bitcode 섹션을 단순히 연결합니다. 비트코드 모듈. ) 편집: 실제로 는 비트 코드 섹션의 xar 아카이브를 생성하고 __LLVM,__bundle 라는 섹션에 넣는 좀 더 복잡한 작업 을 수행합니다. 어쨌든 우리가 신경 써야 할 것은 아닙니다.

이상적으로는 Rustc가 원시 비트코드가 아닌 iOS에서 기본적으로 "포함된 비트코드"를 생성해야 한다고 생각합니다. 그렇게 하는 것은 어렵지 않으며 증분 컴파일이 중단되는 것을 방지합니다. 특히 더미 비트코드 섹션 ala -fembed-bitcode-marker 생성할 수 있는 디버그 모드에서 링커가 개체를 채우기 때문에 릴리스 모드에서도 잠재적으로 가능합니다. ' 링크 타임에 비용이 많이 드는 작업을 수행하는 대신 비트코드 섹션을 함께 사용합니다.

clang이 포함된 비트코드를 생성하는 방법은 다음과 같습니다.

https://github.com/llvm-mirror/clang/blob/master/lib/CodeGen/BackendUtil.cpp#L1242

비교적 간단함 - 백엔드를 호출하기 전에 현재 LLVM 모듈을 비트코드로 덤프한 다음
__LLVM,__bitcode 섹션에 배치된 이진 데이터를 새 전역 변수(같은 모듈에 있음)에 넣습니다. 일종의 해키 디자인처럼 보이지만(프론트엔드에서 수동으로 이 작업을 수행해야 하는 이유는 무엇입니까?), rustc에서 재현하기에는 너무 어렵지 않아야 합니다.

@comex 그 접근 방식은 의미가 있지만(방금 만든 #48833 참조) Apple의 clang을 백엔드로 사용하는 데에는 이유가 있다고 생각하지만 이와 같은 변경 사항에 대해 생각하고 있습니다. 또한 내장된 비트코드에서 컴파일하는 것이 얼마나 쉬운가요?

@michaeleiselsc 죄송합니다. "임베디드 비트코드에서 우리 자신을 컴파일"한다는 말이 무슨 뜻인지 이해가 되지 않습니다.

마찬가지로 비트코드가 포함된 바이너리를 App Store에 제공하는 대신 Apple clang을 사용하여 비트코드를 가져와서 자체적으로 빌드하는 이점도 있습니다. 내가 관심을 갖고 있는 두 가지 이점은 Apple clang의 다운스트림 수정 사항과 clang 소독제(예: 적용 범위 소독제)를 사용할 수 있는 기능입니다.

@comex ok 그래서 조금 파고 충분히 쉬운 것처럼 보이지만 몇 가지 질문이 있습니다.

• -fembed-bitcode-marker 가 왜 중요한가요? 로컬에서 clang을 사용하면 빈 정적을 섹션으로 내보냅니다. 그 섹션 수단 무언가의 단순한 존재를 의미 하는가? 섹션이 없으면 iOS의 일부 도구가 중단됩니까? (그러나 비어 있기 때문에 실제로 섹션 내부를 보지 않습니까?
• __cmdline 섹션이 필요한지 알고 계십니까? -fembed-bitcode 도 바이너리에 명령줄 형식을 포함하는 것처럼 보입니다. 이것은 아마도 Rustc의 명령줄이 아니기 때문에 여기에 무엇을 넣을지 잘 모르겠지만 어떤 도구가 이것을 볼 수 있습니까? iOS에서 -fembed-bitcode=bitcode 를 사용하면 컴파일이 중단됩니까?
• 마지막으로 이것을 비활성화하려는 이유가 있습니까? 아니면 iOS 대상에 대해 이것을 무조건 활성화하고 계속 진행해야 합니까?

-fembed-bitcode-marker가 왜 중요한가요?

나는 그것의 무언가를 나타 내기 위해 엑스 코드에 의해 사용이 사용 비트 코드로 추정 되나 비트 코드가 실제로 컴파일되지 않은 생각합니다. 나중에 그러한 프로젝트를 아카이브하려고 하면 ld가 오류와 함께 실패합니다.

이것을 항상 활성화하고 싶은지 여부에 대한 질문에 대해 우리가 주의해야 할 몇 가지 경우가 분명히 있습니다. 예를 들어 누군가 HockeyApp과 같은 베타 앱 배포 플랫폼에 제출하면 HockeyApp에서 해당 비트코드 섹션을 제거하거나 베타 테스터가 필요한 것보다 훨씬 더 큰 바이너리를 다운로드해야 합니까?

@mitsuhiko 예, 아이디어는 현재 실제로 비트코드가 필요하지 않은 빌드를 테스트하고 있는 경우에도 링커가 빌드가 비트코드에 대해 올바르게 설정되었는지 확인할 수 있다는 것입니다.

예를 들어, 비트코드를 언급하지 않고 C 파일을 컴파일하고 -fembed-bitcode-marker 와 링크하려고 하면 다음을 얻습니다.

$ clang -c -o test.o test.c
$ clang -dynamiclib -o test.dylib test.o -fembed-bitcode-marker
ld: warning: all bitcode will be dropped because 'test.o' was built
without bitcode. You must rebuild it with bitcode enabled (Xcode
setting ENABLE_BITCODE), obtain an updated library from the vendor,
or disable bitcode for this target.

첫 번째 줄에도 -fembed-bitcode-marker 를 전달하면 경고가 사라집니다.

@alexcrichton __cmdline ... 흠... 링커가 있어야 하는 것 같습니다("비트 코드 생성" 검색).

https://opensource.apple.com/source/ld64/ld64-274.2/src/ld/parsers/macho_relocatable_file.cpp.auto.html

그러나 실제 가치에 대해 관심을 갖는 것은 없습니다. 아마도 더미 값을 거기에 두는 것이 가장 좋습니다.

#48896을 병합하여 이 문제가 해결되었습니까?

나는 야간 빌드에서 이것을 가지고 놀았고 Xcode로 아카이브를 시도할 때까지 훌륭하게 작동합니다. Rust 정적 라이브러리 출력에 fembed-bitcode-marker가 추가되지만 fembed-bitcode는 추가되지 않는 것 같습니다. 다음을 사용하여 cargo lipo --release 로 컴파일됩니다.

$ cargo --version
cargo 1.27.0-nightly (af3f1cd29 2018-05-03)
$ cargo lipo --version
cargo-lipo 2.0.0-beta-2
$ rustc --version
rustc 1.27.0-nightly (565235ee7 2018-05-07)

ld: '/Users/chrisbal/Documents/Beach/rust-universal-template/target/universal/release/libexample.a(example_generic-be72fb1769c1779b.example_generic6-152d14edfb6970f54250733c74e59b7.rs.rcgu.o)' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

otool -arch arm64 -l /Users/chrisbal/Documents/Beach/rust-universal-template/target/universal/release/libexample.a | grep bitcode 실행하면 많은 sectname __bitcode 가 발생하지만 이것이 마커가 아니라 실제 비트코드인지 확인하는 방법을 모르겠습니다.

중첩된 크레이트를 사용하고 있으므로 내부 "일반" 크레이트에 비트코드 플래그가 표시되지 않습니까?

편집: 다음은 문제를 시연하는 리포지토리입니다. https://github.com/Raizlabs/rust-universal-template/tree/879e7412d729e8963586c5b083d51b09733aec32

@chrisballinger , 추가 플래그와 함께 작동합니다. 참조
RUSTFLAGS="-Z embed-bitcode" cargo lipo --release

$ cargo --version
cargo 1.28.0-nightly (f352115d5 2018-05-15)
$ cargo lipo --version
cargo-lipo 2.0.0-beta-2
$ rustc --version
rustc 1.28.0-nightly (952f344cd 2018-05-18)

그러나 arm7 아치에 대해서만 다른 컴파일 오류가 있습니다.

.rs.rcgu.o)' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture armv7

arm7 arch 수정하는 방법 아시는 분 계신가요?

슬프게도 @chrisballinger 와 동일한 오류가 발생하여 작동하도록 할 수 없습니다.

ld: '/sandbox/target/universal/release/librgame.a(std-da6dba40351cda22.std3-d36cd881bae00a8b5fc36289b5737f78.rs.rcgu.o)' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

나는 그것을 컴파일 시도했습니다 RUSTFLAGS="-Z embed-bitcode" cargo lipo --release 하고 그것을 설정 .cargo/config . 그래도 플래그를 추가합니다.

` Executing: "cargo" "build" "--target" "x86_64-apple-ios" "--lib" "--features" "" "--color" "auto" "--release" "--verbose" Compiling libc v0.2.42 Compiling rand_core v0.2.1 Running `rustc --crate-name libc /Users/aleksandrivanov/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.42/src/lib.rs --crate-type lib --emit=dep-info,link -C opt-level=3 --cfg 'feature="default"' --cfg 'feature="use_std"' -C metadata=dce309634355ac97 -C extra-filename=-dce309634355ac97 --out-dir /Users/aleksandrivanov/Sandbox/Projects/tetris/rgame/target/x86_64-apple-ios/release/deps --target x86_64-apple-ios -L dependency=/Users/aleksandrivanov/Sandbox/Projects/tetris/rgame/target/x86_64-apple-ios/release/deps -L dependency=/Users/aleksandrivanov/Sandbox/Projects/tetris/rgame/target/release/deps --cap-lints allow -Zembed-bitcode` ...

업데이트가 있습니까? 이 고정 C++ 없이 앱의 공유 코어 라이브러리를 크게 고려하는 것이 가능한 옵션입니다.

@chrisballinger , https://github.com/rust-lang/rust/issues/52686 과 관련이

@volodg 아니요, 이 문제는 얼마 전의 문제입니다.

#48896의 병합으로 즉시 작동해야 합니까?

저는 1.29.1을 사용 중이고 객체에는 기본적으로 비트코드가 포함되어 있지 않습니다. @volodg 가 앞서 언급했듯이 RUSTFLAGS="-Z embed-bitcode" 사용하여 녹을 포함할 수 있습니다. 그러나 내가 경험한 바에 따르면 Rust의 자체 라이브러리(compiler_builtins, std)가 embed-bitcode로 컴파일되지 않는 문제가 발생합니다. 아마도 Embed-bitcode와 함께 xargo를 사용하여 iOS 타겟을 재구축하는 것이 효과가 있을 수 있지만 저는 시도하지 않았습니다.

나는 당신이 제안한대로 xargo 을 사용하려고 시도했지만 문제는 여전히 여기에있는 것 같습니다 :(

이 Xargo.toml

[dependencies]
std = {}
[target]
features = ["jemalloc"]

또한 이것을 Cargo.toml :

[profile.release]
panic = "abort"

모든 대상에 대해 xargo build --release --target $TARGET 를 사용하여 컴파일했습니다.

• aarch64-애플-다윈
• armv7-apple-darwin
• armv7s-apple-darwin
• i386-애플-다윈
• x86_84-애플-다윈

그런 다음 lipo 를 사용하여 하나의 정적 라이브러리를 만들었습니다.

여전히 링커 오류가 있습니다.

ld: '../../cargo/target/universal/libgreetings.a(greetings-ceeec73d35f7dbe0.greetings.9kcaav8v-cgu.2.rcgu.o)' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

xargo 경로로 조금 더 나아갔습니다.

내 Xargo.toml

[dependencies]
std = {}

내 Cargo.toml

[profile.release]
panic = "abort"

필요한지 모르겠으나 xargo 문서에서 명시적으로 extern crate compiler_builtins 사용해야 하며 이를 lib.rs에 추가했습니다.

그런 다음 컴파일하기 위해 RUSTFLAGS="-Z embed-bitcode" xargo build --target $TARGET --release 로 컴파일했습니다. core/std/compiler_bultins를 빌드하는지 확인하십시오. xargo clean 는 내가 경험한 것에서 이전 빌드를 올바르게 정리하지 않으므로 다른 Xargo.toml 조정을 시도할 때 std를 다시 컴파일하려면 rm -rf ~/.xargo 가 필요했습니다.

그러나 Xcode 10에 보관하면 ( armv7 링크에서) 다음을 얻습니다.

Intrinsic has incorrect argument type!
void (i8*, i8, i32, i1)* @llvm.memset.p0i8.i32
Intrinsic has incorrect argument type!
void (i8*, i8*, i32, i1)* @llvm.memcpy.p0i8.p0i8.i32
Intrinsic has incorrect argument type!
...
(lots of it)
...
LLVM ERROR: Broken module found, compilation aborted!
clang: error: linker command failed with exit code 1 (use -v to see invocation)

버그가 LLVM에 의존한다는 의미입니까?

편집 : 이 문제를 진행하는 데 어떻게 도움이 됩니까?

최근에 이것을 시도한 사람이 있습니까? armv7이 가장 큰 문제인 것 같은데요?

안녕하세요 여러분. 저는 이 스레드를 한동안 팔로우해 왔으며 Apple 비트코드가 Rust에서 지원되는 것을 보게 되어 매우 기쁩니다. 지금까지 이 작업을 수행할 수 있는 사람이 있습니까? 현재 누락된 것은 무엇이며 어떻게 도울 수 있습니까?
감사 해요!

몇 시간 동안 이 문제를 찾아본 결과 Rust의 비트코드 임베딩이 Xcode에서 작동하지 않는 이유를 찾았습니다. 짧은 대답은 Xcode의 LLVM 버전은 LLVM 6.0 비트 코드를 예상하는 반면 Rust는 2018년 7월 에 LLVM 7.0으로 충돌 했다는 것 입니다.

이제 긴 답변이...

LLVM 7.0의 changelog 에서 볼 수 있듯이 @llvm.memcpy , @llvm.memmove 및 @llvm.memset 대한 서명을 변경했으며 Xcode 빌드 오류는 잘못된 인수 유형에 대해 명확했습니다. 내 이전 댓글에서 .

그건 그렇고, Kotlin Native는 2018년 10월 에 Embed-bitcode에 대한 지원을 추가했으며 분명히 Xcode에서 잘 작동하고 있습니다. 그 이유는 Kotlin이 여전히 LLVM 6.0을 사용하기 때문입니다.

그걸 보고 7.0으로 올라가기 전에 구 버전의 Rust를 사용하여 컴파일을 시도했습니다. nightly-2018-06-01-x86_64-apple-darwin 시도했는데 성공하면 컴파일됩니다!

나는 또한 성공하지 못한 Xargo를 사용하지 않고 컴파일을 시도했습니다. 모든 종속성은 비트코드 임베딩으로 컴파일해야 합니다.

결론적으로, Apple이 LLVM 버전을 범하지 않는 한, 임베디드 비트코드에 대한 지원을 곧 보게 될 것이라고 생각하지 않습니다... 누군가 임베디드 비트코드를 6.0의 비트코드로 변환하는 영리한 방법을 찾지 않는 한...

@appaquet 자세히 알아 주셔서 감사합니다! 그것은 나에게 아주 신비로운 일이었고 당신처럼 깊이 잠수하게 될 것이라고는 생각하지 않습니다. Apple이 LLVM 버전을 범하면 작동을 시작해야 한다는 사실을 아는 것이 좋습니다.

@appaquet님 의 명쾌한 답변에 감사드립니다. 이제 우리는 올바른 일을 하기 위해 Apple에 의존해야 한다고 생각합니다.

모바일용 멀티플랫폼에 관심이 있고 대부분의 유망한 솔루션(React Native, Flutter, Kotlin/Native, Rust)을 비교한 사람의 측면

네이티브에 반응합니다. 기본적으로 브리지는 C++로 작성되고 런타임에서 JS 코드를 해석하기 때문에 처음부터 비트코드를 지원합니다.

실룩 거리다. 아직 비트코드를 지원하지 않습니다 - https://github.com/flutter/flutter/issues/15288

코틀린/네이티브. JetBrains는 모바일 플랫폼을 우선 순위로 고려하고 있으며 시간이 오래 걸리고 비트코드 마커일 뿐(아직 전체 비트코드가 아님) 작업을 시작하기에 충분합니다. https://github.com/JetBrains/kotlin-native/ 참조 pull/1564 및 https://github.com/JetBrains/kotlin-native/issues/1202#issuecomment -444022513

녹. LLVM 7용 비트코드를 지원하지만 Apple은 버전 6을 사용합니다.

비즈니스 로직과 UI 크로스 플랫폼을 모두 갖고 싶다면 React Native 또는 Flutter를 사용하겠습니다. 그러나 많은 심각한 앱의 경우 이 경로는 너무 위험합니다. React Native는 성능이 충분하지 않으며 API 및 종속성 안정성 이 문제입니다(v1.0이 올까요?). Flutter는 약간 미숙하지만 점점 더 많은 견인력을 얻는 것 같습니다.

이제 어떤 종류의 모듈에서 비즈니스 로직만 공유하고(예: C++ 및 JNI/Obj-C++로 수행한 이전 대형 앱처럼) 그 위에 진정한 네이티브 UI를 구축하려는 경우 처음에는 4가지 모두 중에서 선택할 수 있습니다. 그런 다음 JS<->Native 사이에서 비즈니스 로직을 실행하기 위해 완전한 JavaScriptCore와 브리지를 사용하는 것이 약간 오버인 것처럼 보이기 때문에 React Native를 지웁니다(이 브리지를 초기화하는 것도 상당히 비용이 많이 듭니다). Flutter는 잠재적으로 사용될 수 있지만 그런 식으로 의도된 것은 아니므로 다시 비즈니스 로직을 실행하기 위해 UI 프레임워크를 사용하게 될 것입니다. 또한 비트 코드를 지원하지 않습니다.
Rust와 Kotlin/Native는 모두 이 틈새 시장을 목표로 하고 있으며, 적절한 도구를 갖추고 있으며, 기본 바이너리(성능 및 공간!)를 생성합니다. Bitcode는 모바일 플랫폼에서 다중 플랫폼 모듈을 구축하기 위한 언어로 Rust를 채택하려는 사람들에게 큰 문제입니다. 이제 Kotlin/Native에 이점이 있습니다.

iOS 개발자에게 비트코드가 매우 중요한 이유를 요약하자면. tvOS 또는 watchOS에서 아무 것도 쓸 수 없습니다. 바이너리로 배포되는 많은 타사 프레임워크에는 비트코드가 활성화되어 있습니다. 일부 보안 감사에서는 이를 요구합니다. 그리고 마지막으로 Apple이 "내년부터 비트코드가 완전히 포함되지 않은 앱은 더 이상 허용하지 않습니다"라고 말할 때마다 모든 사람이 타이머를 받습니다.

이제 우리는 올바른 일을 하기 위해 Apple에 의존해야 한다고 생각합니다.

예, 맞습니다. 이것이 Apple이 악명 높은 것입니다 ;)
가장 좋은 솔루션이 무엇인지는 모르겠지만(일시적으로 LLVM 6으로 다운그레이드하는 것은 선택 사항이 아닙니다. 맞죠?) Rust는 iOS 및 모바일 크로스 플랫폼 개발자를 완전히 잃고 있습니다.

@oleksandr-yefremov에 대한 자세한 설명 정말 감사합니다. 나는 주제에 대해 조금 읽었고 다음과 같은 흥미로운 의견을 발견했습니다. https://gist.github.com/yamaya/2924292#gistcomment -2738480

LLVM 버전은 XCode에서 사용되는 Swift 버전과 연결되어 있습니다. 지금까지 다음 지원이 적용되었습니다.

Xcode 8.3  --> swift 3.1 --> llvm 4.0.0
Xcode 9.0  --> swift 4.0 --> llvm 4.0.0
Xcode 9.3  --> swift 4.1 --> llvm 5.0.2
Xcode 10.0 --> swift 4.2 --> llvm 6.0.1

swift-5.0-branch 보는 동안 LLVM의 선언된 버전이 7.0.0 임을 알았습니다. https://github.com/apple/swift-llvm/blob/swift-5.0-branch/ CMakeLists.txt#L25 -L33

여기에 더 많은 차단기가 있는지는 모르겠지만 Rust를 사용하여 Bitcode 바이너리를 출력할 수 있을 것 같습니다 🎉

Xcode 10.2에는 Swift 5.0이 포함될 것이며 곧 출시될 것입니다. 그러나 한편 LLVM 8.0은 다음 주에 출시될 예정입니다. Rust는 Apple이 사용하기 전에 업그레이드할 가능성이 높습니다.

Rust가 비트코드를 적절하게 지원하려면 고정된 버전의 LLVM을 사용하는 Rust의 Apple ARM 아키텍처 빌드가 필요합니다(https://github.com/apple/swift-llvm 리포지토리에 있을 수 있음 - Apple은 사용하지 않는 것 같습니다. 릴리스된 LLVM 패키지이지만 자체 분기). 해당 버전의 LLVM은 Apple이 다른 LLVM 버전으로 Xcode의 새로운 최종 버전을 출시할 때만 업데이트됩니다.

Btw, 최신 Rust는 LLVM 6으로 빌드할 수 있으므로 확실히 실행 가능한 것처럼 보입니다. https://github.com/rust-lang/rust/blob/master/src/bootstrap/native.rs#L282
LLVM의 필수 버전(LLVM 6용 버전: https://github.com/rust-lang/rust/issues/55842)을 업데이트하기 위해 문제가 생성되면 사람이 개입해야 합니다.

@vincentisambart Rust는 IIRC 5개월 동안 야간 빌드에 이미 LLVM 8을 사용하고 있습니다.
당신이 스스로를 구축하려는 경우 LLVM (6) 지원 최소한의 버전과는 CI 테스트 것 : https://github.com/rust-lang/rust/blob/706e67b0a0143d651eb03f2fa2c30645899e81ff/src/ci/docker/x86_64-gnu-llvm-6.0 /도커파일

이제 우리는 올바른 일을 하기 위해 Apple에 의존해야 한다고 생각합니다.

나는 잠시 동안 이 라인을 따라 무언가를 쫓고 있었고 (지금은 종료했습니다) 플랫폼 측면에서 Apple이 이것을 하는 것이 합리적이지 않다고 추측하고 있습니다. 그 이유는 다음과 같습니다.

• Swift는 여러 면에서 Rust가 되기를 원하지만(하나는 소유권 선언문 참조) 많이 뒤쳐져 있습니다.
• Apple은 Swift를 주요 플랫폼 언어로 유지해야 하므로 플랫폼에서 다른 큰 언어를 지원하거나 Swift를 다른 환경으로 밀어 넣는 것은 이치에 맞지 않습니다.

Rust는 이미 5개월 동안 IIRC에 야간 빌드에 LLVM 8을 사용하고 있습니다.

그러면 Apple이 LLVM 7 비트코드를 지원하기 시작하더라도 최근 Rust의 공식 빌드에서 생성된 비트코드가 작동하지 않을 수 있습니다. 그렇게 되더라도 다음에 Rust가 생성된 비트코드에서 호환되지 않는 변경이 있는 LLVM 버전으로 이동할 때 중단될 수 있습니다.

LLVM 6은 직접 빌드하고 CI에서 테스트한 경우 지원되는 최소 버전입니다.

그런 다음 Rust의 공식 *-apple-ios 빌드가 LLVM 6(또는 https://github.com/apple/swift-llvm/releases/tag/swift-4.2.2-RELEASE와 같은 더 나은 것)으로 빌드되도록 하면 작동) 비트코드 문제를 해결할 수 있습니다.

Rust는 현재 https://github.com/rust-lang/rust/issues/46819 병합 후 두 개의 LLVM 백엔드(Emscripten 및 표준)와 함께 제공된다고 생각
#46819는 비트코드에 대한 ios LLVM 백엔드를 언급하지만 구현하지 않았습니다.

이것을 완전히 탈선시키는 것은 아니지만 그러한 경우에 C로의 트랜스파일을 가능하게 하는 것이 전반적으로 더 합리적이지 않을까요? Rust가 Apple 측의 비트코드 요구 사항을 최신 상태로 유지할 수 있을 것 같지 않습니다.

실제로 잠재적인 비호환성 소스가 있더라도 Apple에 적합한 LLVM 버전을 포함하는 호환 가능한 이전 버전의 Rust로 컴파일을 시도할 수 있는 테스트의 문이 열립니다.

완전한 크로스 플랫폼 접근 방식에서 이것은 우리가 최신 개선 사항의 이점을 얻고 이전 버전에서 컴파일할 수 있도록 최신 버전의 Rust에서 동일한 소스 코드를 컴파일할 수 있어야 하기 때문에 여전히 확실히 차단됩니다. 특히 Apple 생태계를 위한 비트코드 호환 바이너리를 출력하기 위한 Rust 버전입니다. 그것은 가능하지만 적합하지 않습니다.

적어도 더 많은 사람들이 이것을 테스트하고 우리 모두를 올바른 방향으로 나아가게 할 수 있는 기회가 열리기 때문에 이 일이 일어나는 것을 보고 매우 기쁩니다.

현재 상당히 큰 팀을 위해 크로스 플랫폼 모바일 코드를 작성하기 위한 접근 방식을 결정하려고 하는 사람으로서 말하자면, 비트코드를 생성할 수 없다면 문자 그대로 Rust를 사용할 수 없습니다. 우리 앱 중 하나는 셀 네트워크를 통해 다운로드할 수 있을 만큼 충분히 작은 바이너리를 생성할 수 있도록 비트코드에 의존하고 있으며 이를 주장하는 일부 대규모 고객이 있습니다.

Rust에 대해 내가 본 모든 것을 기반으로 볼 때 Rust가 내가 볼 수 있는 가능성(Kotlin Multiplatform, 크로스 컴파일 Swift, Mono, Dart, C++, React Native) 중 가장 장기적인 장점이 있다고 생각하지만 확실히 비트코드가 필요합니다. 최신 Rust 릴리스를 따라갈 수 없다는 것을 의미하더라도 완벽하게 지원됩니다.

비트 코드가 작동하더라도 Rust는 여전히 watchOS 또는 tvOS를 대상으로 할 수 없습니다.

Rust가 Apple 측의 비트코드 요구 사항을 최신 상태로 유지할 수 있을 것 같지 않습니다.

여기서 문제는 Rust의 LLVM이 너무 새롭기 때문이 아니라 너무 오래 되었다는 것입니다. 여기에 더 나은 호환성 이야기가 있어야 한다는 데 동의합니다.

Rustc가 여러 LLVM을 지원하는 것이 얼마나 실현 가능합니까?

관련: tvOS 및 watchOS(및 시뮬레이터) 대상 지원

이미 여러 LLVM을 사용하고 있습니다. emscripten 대상의 경우 LLVM 6 atm에 있는 emscripten의 LLVM 포크를 사용합니다.

여기서 문제는 Rust의 LLVM이 _너무 새롭기 때문이지 _너무 오래되었다는 것이 아닙니다. 여기에 더 나은 호환성 이야기가 있어야 한다는 데 동의합니다.

문제는 너무 오래되었거나 너무 새롭다는 것이 아니라 Rust가 LLVM 버전과 일치하더라도 모든 iOS 릴리스에서 이것이 다시 중단될 수 있다는 것입니다. Apple(내가 아는 한)은 비트코드와 관련하여 어떤 방식으로도 안정성을 보장하지 않습니다.

문제는 너무 오래되었거나 너무 새롭다는 것이 아니라 Rust가 LLVM 버전과 일치하더라도 모든 iOS 릴리스에서 이것이 다시 중단될 수 있다는 것입니다. Apple(내가 아는 한)은 비트코드와 관련하여 어떤 방식으로도 안정성을 보장하지 않습니다.

실제로 우리는 새로운 iOS 버전이 나올 때 1년에 한 번 주요 Xcode 업데이트를 봅니다. 이러한 일이 발생하면 개발자는 최신 버전의 Xcode로 앱 제출을 시작해야 한다는 분명한 경고를 받기 때문에 거의 놀라운 일이 아닙니다. 나는 이것이 특별히 계획하기 어렵다고 말하지 않을 것이다.

나는 이것이 특별히 계획하기 어렵다고 말하지 않을 것이다.

계획하기 매우 어려운 것으로 변할 수 있는 비트코드에 대한 보장이 전혀 없기 때문입니다. LLVM의 오픈 소스 릴리스로 끝나지 않는 자체 비트코드 형식을 사용하기 위해 한 릴리스에서 다른 릴리스로 결정한다고 상상해 보십시오.

계획하기 매우 어려운 것으로 변할 수 있는 비트코드에 대한 보장이 전혀 없기 때문입니다. LLVM의 오픈 소스 릴리스로 끝나지 않는 자체 비트코드 형식을 사용하기 위해 한 릴리스에서 다른 릴리스로 결정한다고 상상해 보십시오.

Apple이 다른 누구와도 무관하게 획기적인 변화를 일으킬 것이라고 가정한다면, 물론입니다. Bitcode에 대한 계획에 대해 좀 더 명확한 문서를 가지고 있다고 해서 그것이 악의적이거나 그냥 아무 상관이 없다고 가정한다면 그다지 개선되지 않습니다.

그러나 그들은 분명히 Swift를 플랫폼의 중요한 부분으로 만들었으며 자체 팀과 가장 중요한 파트너를 포함하여 수천 명의 개발자가 Swift에 의존하고 있습니다. Swift는 완전 오픈 소스 LLVM을 기반으로 하며 Xcode가 Apple이 허용하는 비트코드를 생성하는 데 사용하는 도구 체인을 포함하여 완전히 공개적으로 개발되고 있습니다.

따라서 아무도 눈치채지 못하거나 돌보지 않고 갑자기 형식을 변경하려면 Swift 및 LLVM 리포지토리를 모두 비공개로 설정해야 하지 않습니까? 그것은 확실히 가능하지만 나에게는 가능성이 높지 않은 것 같습니다.

Rust 팀이 그 위험이 비트코드를 지원하지 않는 좋은 이유라고 결정한다면, 그것은 확실히 그들의 특권입니다. 나는 그것에 대해 조금 슬프지만 다른 사람들에게 어디에서 시간을 보내야 하는지를 말하는 것은 내 자리가 아닙니다.

계획하기 매우 어려운 것으로 변할 수 있는 비트코드에 대한 보장이 전혀 없기 때문입니다. LLVM의 오픈 소스 릴리스로 끝나지 않는 자체 비트코드 형식을 사용하기 위해 한 릴리스에서 다른 릴리스로 결정한다고 상상해 보십시오.

Apple은 6월 초에 Xcode 베타를 출시하고 9월에 최종 버전을 출시합니다. 6-9개월 후에는 이전 Xcode 버전으로 빌드된 앱을 Appstore에 허용하지 않습니다.

그 타임라인에서 비트코드 변경을 준비할 시간은 충분하다고 생각합니다.

Xcode 10.2 베타 3(Swift 5 w/ LLVM 7 포함)으로 방금 테스트했으며 최근 밤에 임베디드 비트코드를 사용하여 Rust와 연결할 수 있습니다. Rust에는 watchOS/tvOS 타겟이 없기 때문에 분명히 이것은 iOS 타겟에서만 작동합니다.

나는 또한 비트코드 호환성을 유지하기 위해 Rust가 모든 Apple 관련 대상에 대해 Apple LLVM 포크를 사용할 수 있어야 한다는 데 동의합니다.

예, 베타 릴리스 기간이 합리적으로 들립니다. Apple이 소스 LLVM 또는 비트코드 형식을 닫을 것이라는 아이디어는 매우 가능성이 낮지만 향후 iOS 릴리스에서 Apple이 비트코드를 요구할 것이라는 생각은 분명히 일어날 것 같습니다. 그리고 Marzipan 프로젝트와 함께 Mac App Store 제출을 위해 비트코드를 요구하기 시작할 수도 있습니다.

제안된 호환성을 보장하지 않는 방식으로 처리하는 것은 분명히 성급하지만 모바일 플랫폼은 결국 Tier 1 플랫폼 이 되어야 한다고 생각

컴파일러 팀에서 공식적으로 승인한 접근 방식이 누군가가 이 작업을 수행하도록 권장하기를 희망하지만 @brson 의 이전 댓글은 주저를 요약한 것 같습니다.

여러 버전의 LLVM 간에 호환성을 성공적으로 유지 관리합니다. Apple과 우리가 너무 멀리 떨어져 있지 않는 한 가능해야 하지만 분할을 넘을 수 없을 정도로 큰 파손의 위험이 항상 있습니다.

아니면 미래에 비트코드가 안정화될 것이고 우리 모두는 이 논쟁이 일어난 것을 잊어버릴 것입니다 🙏

이제 모자를 먹겠습니다 😞

내가 말했다 :

Apple이 소스 LLVM 또는 비트 코드 형식을 닫을 것이라는 생각은 거의 없습니다.

이는 주로 @mitsuhiko가 표현한 불신에 대한 응답

LLVM의 오픈 소스 릴리스로 끝나지 않는 자체 비트코드 형식을 사용하기 위해 한 릴리스에서 다른 릴리스로 결정한다고 상상해 보십시오.

그러나 문제 #48833 을 보면 분명히 선례가 있습니다. @comex는 이전에 다음과 같이 썼습니다.

LLVM 트렁크 이전에 Xcode의 LLVM에 기능이 표시되는 경우가 있었습니다. 예를 들어 전체 arm64 포트가 원래 개발되었을 때, 그 이유는 Apple이 arm64 장치를 출하할 계획이라는 사실을 비밀로 유지하기를 원했기 때문입니다.

그리고 같은 문제에서 @michaeleiselsc 의 이야기:

내가 작업하고 있던 앱은 2016년 12월에 무작위로 다시 시작하여 큰 타격을 받았으며 이는 오픈 소스 LLVM이 2017년 12월에만 수정한 특정 문제로 인해 발생했습니다. 2016년 12월에 오픈 소스 LLVM에서 Apple의 LLVM으로 이전했을 때 문제가 고정되었다

이 아이디어가 Rust와 함께 Apple의 LLVM을 사용한다는 점을 감안할 때 그렇게 나쁘지는 않지만 다양한 구현으로 인해 가끔 고약한 버그가 발생할 위험이 있습니다. 😢. 모든 프로젝트가 짊어질 수 있는 위험은 아닙니다. 이 시점에서 Transpiling이 더 나은 옵션처럼 들리지만, 지금까지는 가능한 모든 것처럼 들리지 않습니다 .

나는 여전히 Apple의 LLVM을 사용하는 것이 지원되어야 한다고 생각하지만, 계속 작동할 것이라는 보장이 없음을 설명하는 문서에 명확한 경고가 있어야 합니다(A Tier 1.5 또는 기타).

코틀린/네이티브. JetBrains는 모바일 플랫폼을 우선 순위로 고려하고 있으며 시간이 오래 걸리고 비트코드 마커일 뿐(아직 전체 비트코드가 아님) 작업을 시작하기에 충분합니다. JetBrains/kotlin-native#1564 및 JetBrains/kotlin-native# 참조 1202(댓글)

@oleksandr-yefremov를 지적해 주셔서 감사합니다! 나는 조금 더 파고와 코 틀린 / 기본 접근 방식 복제 할 수 있었다 golang의를 . 나는 여러분이 비트코드를 방출하지 않고도 비트코드 지원 iOS/tvOS/watchOS 앱에서 녹을 사용할 수 있도록 똑같이 할 수 있어야 한다고 믿습니다.

이제 비트코드가 작동합니까? 시도한 사람이 있습니까?

@volodg 저는 녹슨 초보자입니다. 그러나 나는 이 튜토리얼 을 야간에 최신 러스트( rustc 1.37.0-nightly (088b98730 2019-07-03) )로 실행했지만 작동하지 않았습니다.

마커가 있는거같은데..

$ otool -arch arm64 -l librust.a  | grep bitcode
  sectname __bitcode
...

그러나 iOS 장치용으로 빌드할 때 다음 오류가 발생합니다(시뮬레이터 작동).

ld: '/Users/amrox/Documents/Projects/rust-ios-example/hello-rust/libs/librust.a(rust-e6011ffb55678675.rust.8yq9vjk7-cgu.3.rcgu.o)' does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target. for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

그게 내가 얻은 것입니다.

rustc nightly-2019-09-05 aarch64-apple-ios and rustflags = "-C lto -Z embed-bitcode" staticlib를 clang-1100.0.33.5 (Xcode 11 beta 7) and -fembed-bitcode 앱과 연결하는 데 성공했습니다. 소스 코드는 https://github.com/saturday06/rust-ios-bitcode-test 입니다.

• __cmdline 섹션이 필요한지 알고 계십니까?

2년 후에 나는 이 질문에 답할 수 있습니다. 물리적 장치에 배포하거나 Xcode 아카이브를 생성하는 경우 빈 cmdline은 괜찮습니다. 그러나 App Store 제출의 경우 Apple은 clang 명령줄의 유효성 검사를 수행합니다. 작동하도록 하는 해킹 패치가 포함된 이 PR에 더 긴 설명을 넣었습니다. https://github.com/getditto/rust-bitcode/pull/7

어떻게든 이것을 업스트림하고 싶지만 옵션이 매력적이지 않습니다. iOS를 대상으로 할 때 일부 클랜 옵션을 구성합니까? Apple이 유효성 검사 규칙을 변경할 경우 거짓말을 하는 방법을 정확히 선택할 수 있도록 envvar를 제공합니까? 여기에 합리적인 선택이 있다면 기꺼이 변경하겠습니다.

-Cembed-bitcode=no는 ios 대상에서 작동하지 않습니다. .a 파일에 여전히 비트코드 섹션이 있습니다.
비트코드 없이 빌드하는 방법?