Как создать исполняемый файл с rustc?

Question

Если компилировать эту простую программу fn main() { println!("Hello"); } с rustc test.rs -o test то я могу запустить его с ./test, но дважды щелкнув его в файловом менеджере дает эту ошибку: Could not display "test". There is no application installed for "shared library" file. Запуск file test, кажется, согласны: test: ELF 64-bit LSB shared object....

Как я могу получить rustc, а также инструменты, которые используют его, такие как груз, для создания исполняемых файлов, а не общих объектов?

Я использую 64-разрядную версию Linux (Ubuntu 14.10).

EDIT: У меня есть posted на Rust forum об этом.

EDIT @: Оказывается, это проблема с исполняемым файлом file.

Answer 1

То, что вы описали не совсем соответствует тому, что я наблюдаю:

$ rustc - -o test <<< 'fn main() { println!("Hello"); }' 
$ ./test 
Hello 
$ file test 
test: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=99e97fcdc41eb2d36c950b8b6794816b05cf854c, not stripped 

Если вы не скажете rustc для создания библиотеки с, например, #![crate_type = "lib"] или --crate-type lib, он выдаст исполняемый файл.

Похоже, что ваш файловый менеджер может быть слишком умным для своего же блага. Он должен просто доверять исполняемому биту и выполнять его.

Answer 2

У меня нет компилятора ржавчины и я не могу найти его документы в Интернете, но я знаю, как делать общий obkect vs исполняемый файл на C, поэтому, возможно, эта информация поможет вам в решении этой проблемы.

Разница - вариант -pie для компоновщика. С программой приветом миром C:

$ gcc test.c -ohello -fPIC -pie 
$ file hello 
hello: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped 

Если мы уберем позиционно-независимые флаги, мы получим исполняемый файл:

$ gcc test.c -ohello 
$ file hello 
hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), not stripped 

Оба генерируемые файлы работают таким же образом из командной строки, но я подозреваю, разница file видит, что делает ваш графический интерфейс. (Опять же, я не на Ubuntu ... Я использую Slackware без файлового менеджера gui, поэтому я не могу подтвердить себя, но надеюсь, что мои догадки помогут вам решить проблему самостоятельно.)

Итак, что я попробую, если бы я был на вашем компьютере, было бы проверить страницу rustc man или rustc --help и посмотреть, есть ли возможность отключить опцию -pie для компоновщика. Он означает «независимый по позиции исполняемый файл», поэтому ищите эти слова в файле справки.

Если вы не указали, попробуйте rustc -v test.rs -o test - или какой бы то ни было флаг verbose в файле справки. Это должно распечатать команду, которую он использует для связи в конце. Вероятно, это будет звонок gcc или ld. Вы можете использовать это, чтобы связать его самостоятельно (вероятно, есть флаг -c или что-то такое, что вы можете передать rustc, чтобы сообщить ему, чтобы его компилировать, не ссылайтесь, что оставит только файл .o, который он генерирует).

Как только у вас есть это, просто скопируйте/вставьте команду окончательной ссылки rustc и вызывайте и удаляйте опцию -pie самостоятельно .... если она есть ... и посмотрите, что произойдет.

Вручную копировать/вставлять не рекомендуется и не будет работать с инструментами, но если вы можете заставить его работать хотя бы один раз, вы можете подтвердить мою догадку и, возможно, задать другой вопрос, чтобы получить больше ржавчины внимание пользователей.

Вы также могли бы быть в состоянии сказать, файловый менеджер, как открыть общие объектные файлы и просто использовать их. Если менеджер обрабатывал их так же, как программы file идентифицирует как исполняемые файлы, как это делает командная строка, все должно работать без изменения процесса сборки. Я не знаю, как это сделать, но, возможно, попросить об обмене стеками ubuntu найдет того, кто это сделает.