Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Metal backend: exported `.pte` does not load outside a process that already has PyTorch's libomp (embedded AOTI object links `/opt/llvm-openmp/lib/libomp.dylib`)

Đang mở
  • Có gì không ổn?
#22,955 1 bình luận 0 reaction 2 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@metascroy đang làm issue này rồi.

Từ ngày 21/9/2026.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
cpp, macos, python
Lĩnh vực
build-system, embedded-iot, machine-learning, mobile-dev

Hướng nghiên cứu

Start with metal_backend.cpp around line 352 and the MetalBackend.codesign_so path, then inspect run_metal_test.sh's existing library-reference rewrite. Reproduce export and loading outside executor_runner, and determine whether the accepted fix should remove unused dependencies or reject unsupported ones at export time. Done means the chosen behavior is verified for an app without PyTorch's libomp.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

module: metal triaged
Summary

A Metal .pte loads under executor_runner built by run_metal_test.sh, but fails in an application that links the ExecuTorch runtime on its own:

E executorch:metal_backend.cpp:352] Failed to load shared library: dlopen(.../<hash>_so_blob<pid>.so, 0x0005):
  Library not loaded: /opt/llvm-openmp/lib/libomp.dylib
E executorch:method.cpp:132] Init failed for backend MetalBackend: 0x22
Cause

On macOS inductor's _get_openmp_args always adds -lomp. The libomp it resolves is the one bundled in the PyTorch wheel (torch/lib/libomp.dylib), whose LC_ID_DYLIB is the absolute path /opt/llvm-openmp/lib/libomp.dylib, and that path is recorded as a dependency of the AOTI object embedded in the .pte. The path exists on no end-user machine.

It goes unnoticed in-tree because run_metal_test.sh already rewrites the same reference in executor_runner to @rpath/libomp.dylib with an rpath into torch/lib. The runner therefore loads PyTorch's libomp first, and dyld then satisfies the model's dependency by install name. An app that ships its own libomp (or none) has no image with that install name loaded, so dlopen fails.

The dependency is not used: nm -u on the embedded object shows no omp / kmp symbol for a Metal-delegated MobileNet, as expected for a graph that runs on the GPU.

Possible directions
  • Link the AOTI object with -Wl,-dead_strip_dylibs for the Metal backend, so dylibs the object does not reference are dropped and libomp stays only if a model really needs it. Inductor has no option for extra link flags today; we do it from outside by pointing torch._inductor.config.cpp.cxx at a wrapper compiler that appends the flag on link steps. The resulting object links only libc++ and libSystem and loads in a process with no libomp at all.
  • Independently, a check next to MetalBackend.codesign_so that the compiled object has no dependency outside /usr/lib and /System would turn this from a load-time surprise on someone else's machine into an export-time error.

Happy to send a PR for the check if that direction sounds right; the link-flag part probably belongs in inductor.

Ngôn ngữ chính
Python
Star
5k
Fork
1.2k
Merge trung bình
2 ngày 5 giờ
Pull request đã merge (30 ngày)
491

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của pytorch/executorch

Tất cả issue của pytorch/executorch

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.