通过Windows cgo-> gcc-> ld进行的DLL链接给出了“（函数）的未定义引用”错误。

Question

我真的更喜欢GLFW而不是Glut，并且想要在Go 1.0.1 64位的Windows 64位环境下使用它的Golang绑定。在Linux下，绑定可以完美地工作。这在原则上是可行的Windows下- GitHub的用户家校会设法来做到这一点，但他是在Win32和他的提示没有解决我的问题呢。但是，我确实基于tdm64-gcc-4.6.1设置了完整且干净的Mingw64。现在这是一件奇怪的事情-使freeglut绑定在64位Windows，64位Go 1.0.1下可以工作-glfw绑定对我来说失败了。我想弄清楚为什么，因为它们本质上都使用相同的cgo功能和技术。注意，我目前有一个自制的，半熟但基本上可以正常工作的替换软件包，该软件包使用LoadLibrary / GetProcAddress调用在Go中公开glfw.dll。这行得通，但我认为硬连接的内置CGO绑定比无数Syscall（），Syscall6（），Syscall9（），Syscall12（）等Go func调用更为可取。如果Win32和Linux gophers可以拥有此功能，为什么我们不Win64呢？到目前为止，这是我的设置：我有一个带有三个补丁的Golang版本，以使lib链接在应用cgo时起作用我已经使用MinGW64成功地将最新的freeglut和GLFW库编译为64位DLL。头文件glut.h，freeglut * .h和glfw.h放在\ MinGW64 \ x86_64-w64-mingw32 \ include \ GL中（在gl.h，gloux.h，glu.h之后）库文件libfreeglut.a和libglfwdll.a放在\ MinGW64 \ x86_64-w64-mingw32 \ lib（libglu32.a，libopengl32.a旁边）中64位dll glfw.dll和freeglut64.dll放在\ windows和\ windows \ system32中（opengl32.dll，glu32.dll旁边）我相信freeglut64.dll和glfw.dll都可以工作-至少在安装DLL之后，它们的大多数示例程序都可以运行。一切都应该准备就绪，对不对？现在首先要进行成功绑定（我不需要），freeglut-当我进入-x github.com/zombiezen/Go-GLUT/glut时，一切都构建良好，我可以成功创建一个glut窗口，在从.go源文件编译的Windows test.exe中显示一个三角形。感谢-x，go get演示了它的构建过程：是的，这是一个很麻烦的工作-但实际上始终是相同的错误，并且在构建过程中相当晚。请注意，如果未定义#define GLFW_DLL，除没有__imp_前缀外，我得到的输出基本上是相同的-静态链接既不鼓励使用Go，也不适合此特定用例。现在，当gcc抱怨“未定义的引用”时，根据我在Google上的搜索，可能有多种原因...找不到DLL不会失败-它们位于适当的位置，对于freeglut64.dll，它可以正常工作找不到.a库肯定是成功的-它们在适当的位置，并且libfreeglut.a可以工作，如果我将-lglfwdll更改为-lblafoobar，则gcc会更早地失败并正确地抱怨“找不到blafoobar”-因此它确实找到了libglfwdll.a。库依赖关系的顺序？我尝试将-lglfwdll作为第一个库（在-lglu32 -lopengl32之前）和最后一个库（在这两个之后），没有区别。Golang glfw绑定有问题吗？别这么认为，它适用于其他人，包括适用于chsc的Windows（32位）TL; DR -在Windows 64位，围棋1.0.1 64位完全修补，CGO成功生成的东西饲料到GCC的两个freeglut和GLFW。然后，GCC高兴地吃掉了那些东西来建立freeglut绑定，但是拒绝了它来建立glfw绑定，所有C.funcs（）都带有“未定义的引用”。libfreeglut和libglfwdll均已正确构建并安装为64位DLL，并且.h / .a libs均已正确定位。可能是什么原因？

Answer 1

最新版本的Go，GLFW和Mingw-w64不再是问题。

Answer 2

我可以想到两种可能性：

1. 这些符号实际上不在库中。您可以使用进行检查nm。确保符号类型是大写字母；如果只有小写代码，则库构建不正确。

2. 您有循环依赖关系。即，库A依赖于库B，而库B又依赖于A。您可以解决此问题，第二次将库添加到命令中，或使用链接器组（请参阅参考资料ld --help）。

请注意，命令行上的库顺序非常重要：链接器按照它们出现的顺序依次读取每个库，搜索当时所需的符号，然后继续。如果符号是由较晚的库首先引用的，则链接器将不会重新访问较早的库以查找定义。这就是循环依赖成为问题的原因。