如果我使用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)。
编辑:我posted就此问题Rust forum。
编辑@:事实证明这是file
可执行文件的问题。
答案 0 :(得分:2)
你所描述的与我观察到的并不完全一致:
$ 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
,它会产生一个可执行文件。
听起来你的文件管理员可能因为自己的利益而过于聪明。它应该只是信任可执行位并执行它。
答案 1 :(得分:2)
我没有防锈编译器,也无法在互联网上找到它的文档,但我知道如何在C中使用共享obkect和可执行文件,所以这些信息可能会帮助你解决它
不同之处在于链接器的-pie选项。有一个hello world 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
看到的差异正在改变GUI的功能。 (再一次,我不在Ubuntu上......我在没有gui文件管理器的情况下使用Slackware,所以我无法证实自己,但我希望我的猜测可以帮助你自己完成解决问题。)
所以,如果我在你的计算机上,那么我接下来会尝试检查rustc手册页或rustc --help
并查看是否可以选择关闭{{1}链接器的选项。它代表&#34;位置无关的可执行文件&#34;,所以也在帮助文件中查找这些单词。
如果没有提及,请尝试-pie
- 或者帮助文件中的详细标记。这应该打印出最后用于链接的命令。它可能是对rustc -v test.rs -o test
或gcc
的来电。您可以使用它自己链接它(可能是一个标记ld
或者您可以传递给-c
的东西,告诉它只编译,不要链接,这将只留下它生成的rustc
文件。)
完成后,只需复制/粘贴调用的最终链接命令.o
并自行删除rustc
选项....如果存在...并查看会发生什么。
手动复制/粘贴并不是很有趣,并且不会使用工具,但是如果你能让它至少工作一次,你可以确认我的预感并且可能会问一个措辞不同的问题让更多的铁锈用户&#39;注意。
您也可以告诉文件管理器如何打开共享对象文件并使用它们。如果管理器将它们与程序-pie
标识为可执行文件相同,就像命令行那样,一切都应该工作而不改变构建过程。我不知道如何做到这一点,但也许在ubuntu堆栈交换上询问会找到一个人。