简体   繁体   English

Visual Studio 2015 / Linux扩展与Cygwin一起产生“ collect2:错误:ld返回1退出状态”

[英]Visual Studio 2015/Linux extension produces a “collect2 : error : ld returned 1 exit status” with Cygwin

I am currently trying the Linux Extension of Visual Studio 2015. 我目前正在尝试Visual Studio 2015的Linux扩展

I plan to have several target machines using various distribs. 我计划使用不同的分发服务器来配置几台目标计算机。 So far, my testing machine is a Windows 7 with an up-to-date Cygwin with all needed packages ( openssh , g++ , gdb ...) installed. 到目前为止,我的测试机器是装有最新Cygwin的Windows 7,并安装了所有必需的软件包( opensshg++gdb ...)。

The test I'm conducting consists in a very simple C++ "Hello world" file, and the VS projects settings are the default ones. 我正在进行的测试包含一个非常简单的C ++“ Hello world”文件,而VS项目设置是默认设置。

Everything runs well but the linkage: 一切运行良好,但链接:

  • architecture is recognized by Visual Studio Visual Studio可以识别体系结构
  • source files are copied properly to the target machine by the VS extension VS扩展名将源文件正确复制到目标计算机
  • they do compile using g++ 他们确实使用g ++进行编译
  • but the process ends up with a "collect2 : error : ld returned 1 exit status" 但是该过程最终显示为"collect2 : error : ld returned 1 exit status"

I tried to compile this file on the remote platform, using g++. 我尝试使用g ++在远程平台上编译此文件。 No problem, an executable is produced and it works. 没问题,可执行文件已生成并且可以运行。

I absolutely don't get it. 我绝对不明白。 Any idea? 任何想法?


Details if needed: 如有需要,请提供详细信息:

  • My C++ source file: 我的C ++源文件:

      #include <cstdio> int main() { printf("hello from SandboxLinux!\\n"); return 0; } 
  • My project settings (remote settings and linker settings, in which I see nothing special): 我的项目设置(远程设置和链接器设置,在其中看不到什么特别之处):

项目设定 链接器设置

  • My Visual Studio build log: 我的Visual Studio构建日志:

在此处输入图片说明

  • On the remote machine: 在远程计算机上:
    • main.cpp has been properly copied main.cpp已正确复制
    • .o file is properly produced .o文件正确生成
    • .exe (" .out ") is not .exe (“ .out ”)不是
    • project root, obj and bin directories follow: 项目根目录, objbin目录如下:

在此处输入图片说明 在此处输入图片说明 在此处输入图片说明

  • When using g++ directly on the remote machine: 在远程计算机上直接使用g++
    • g++ main.cpp terminates silently and produces an a.exe that works. g++ main.cpp静默终止,并生成一个可以正常运行的a.exe
    • Using g++ -v does not show anything relevant 使用g++ -v不会显示任何相关信息

Ok, found it! 好,找到了! Default VS/Linux project options are not suitable for Cygwin: 默认VS / Linux项目选项不适用于Cygwin:

When switching the VS project build output from "minimal" (the default) to "normal" I could notice there was a problem with the generated ld command line: 当将VS项目构建输出从“最小”(默认)切换为“正常”时,我会注意到生成的ld命令行存在问题:

在此处输入图片说明

1>       Link:
1>         Linking objects
1>         Invoking ld
1>         g++ -o "/home/xxxxx/projects/xxxxxx/bin/x86/Release/xxxxx.out" -Wl,--no-undefined -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack /home/xxxxx/projects/xxxxx/obj/x86/Release/main.o
1>         /bin/ld: unrecognized option '-z'
1>         /bin/ld: use the --help option for usage information
1>         collect2: error: ld returned 1 exit status

The -z option is not implemented on Cygwin and won't be . -z选项未在Cygwin上实现因此不会实现 So it has to be removed from the VS linker options where it is used by default: 因此,必须从默认使用它的VS链接器选项中将其删除:

Before: 之前: 在此处输入图片说明

After: 后: 在此处输入图片说明 ( Note 1 : the third one has to be manually set to blank as both proposed options use -z ) 注1 :由于两个建议的选项都使用-z因此第三个选项必须手动设置为空白)
( Note 2 : all other differences between these two screenshots are not tied to this problem. The first is my release configuration, kept by default, where the second is my debug configuration, that uses verbose and print-map.) 注2 :这两个屏幕截图之间的所有其他差异均与该问题无关。第一个是我的release配置,默认情况下保留,第二个是我的debug配置,使用详细和打印映射。)

Now everything runs well: 现在一切运行良好: 在此处输入图片说明

The program is properly built, it works, and the link with GDB works fine too in debug mode. 该程序已正确构建,可以运行,并且在调试模式下与GDB的链接也可以正常工作。

Caveat: this -z thing might be an issue when switching from Cygwin to standard Linux platforms later on. 注意:在以后从Cygwin切换到标准Linux平台时, -z可能是个问题。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM