Как стать автором
Обновить

Комментарии 11

А чем не устраивает

rustup target add x86_64-unknown-linux-gnu
cargo build --release --target x86_64-unknown-linux-gnu

?
Мне казалось, что как раз кросс-компиляция в Rust делается просто, я на Linux спокойно собираю под другие платформы

А на маке уже не так просто, да и попробуйте так собрать проект, который зависит от Rocksdb, например, или ему нужен openssl.

или ему нужен openssl

а в чем проблема собрать openssl под нужную архитектуру? ./Configure VC-WIN64A и вот это всё. Rocksdb собирается cmake - тоже нет никаких проблем подсунуть ему нужный тулчейн. Или можно даже не собирать, а скачать уже готовые бинарники.

Ну конечно то можно руками, можно руками и binutils собирать и gcc и libc, и потом cmake, а потом еще snappy, zstd, bzip2, заодно еще убедиться, что Perl нужной версии. Ну в потом это все в Шелл скрипт запихнуть.
Только нифига все это надо, если можно воспользоваться уже готовым инструментом, который плюс ко всему еще обеспечивает повторяемость сборки. Можно при помощи fake.lock файла зафиксировать версии всех пакетов и тогда скрипт всегда будет работать и выдавать одинаковый результат.

На маке эти все зависимости можно поставить через macport или brew и уже потом делать кросскомпиляцию.

Понял, спасибо. Не знал, что Rust на macOS не так работает, как на Linux. Для меня еще один аргумент против перехода на Мак.

Это и на Линуксе так просто не работает, попробуйте без дополнительных пакетов собирать что-то под aarch64, или riscv. Так как минимум, линкер нужен.
А вот чтобы взять его, нужны внешние зависимости.

Кстати, такую проблему решили в Zig, у них есть универсальный линкер, который почти под любую libc работает. Так что в простых случаях проще всего воспользоваться вот такой штукой.
https://github.com/rust-cross/cargo-zigbuild

Но Nix это нечто большее, чем простые случаи и это универсальное решение, которые к тому же единообразно работает на Маке и Линуксе.

Учитывая что ваша конструкция и так уже подразумевает наличие докера, просто запускаем линукс в нём.

Неа, не подразумевает, моя конструкция в итоге создает архив, который потом через docker load загружается, а может, например, копироваться с помощью skopeo.

Окей, ну да запустили мы Линукс в докере, молодцы, а дальше если нам нужна другая процессорная архитектура, ну например, хост у нас x86_64, а нам нужен aarch64 таргет, то уупс. Или запускать докер внутри qemu транслятора а это минус 90 процентов производительности, или внутри Докера опять же настраивать кросс-компиляцию.

Так а если нам все равно ее настраивать, нафига нам лишний слой?

Кстати говоря, этот оверлей прекрасно будет работать и с C++ или C проектами.

Это для оправдания тега C++ ?!)

Там как бы очень большая часть работы оверлея была посвящена починке сборки некоторых С++ библиотек.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории