我正在将一个大型（约 1M LOC）项目从 Window/Visual Studio 环境移植到其他平台，第一个平台恰好是 Mac OS X。
最初该项目被配置为 Visual Studio 解决方案，并且项目，但现在我正在使用（优秀的）Premake (http://industriousone.com/premake)为多个平台（VS、XCode、GMake）生成项目文件。
我配置、移植和构建了前几个项目，没有任何重大问题，但是在移植数学库后，我遇到了这个奇怪的链接错误，我无法解决：从 math.h 使用的任何函数都会无法链接（导致无法解析的符号）。
作为参考，我使用 Premake v4.2.1 为 XCode v3.2.1 生成项目，该项目正在使用 gcc v4.2 为 x86_64 架构构建。 （所有这些都在 64 位 Snow Leopard 上）我试图说服 gcc 通过添加 -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 来链接和构建针对“已知”SDK 的所有内容到构建命令行。
现在在正常情况下，添加 -lm 应该可以解决这个问题，但是在 Darwin 中，这些数学库包含在 libSystem 中，据我所知，它由 gcc/ld 隐式链接。
我尝试从 XCode 中创建一个虚拟项目，该项目只是运行：
float f = log2(2.0)+log2f(3.f)+log1p(1.1)+log1pf(1.2f)+sin(8.0);
std::cout << f << std::endl;
正如预期的那样，这个构建得很好。但是，如果我将相同的内容放入 Premake 生成的项目内的代码中，所有这些数学函数最终都无法解析。
现在将“本机”XCode 项目的链接命令与我生成的 XCode 项目进行比较，它们看起来非常相同（除了我生成的项目也链接其他库）。
“本机”项目：
/Developer/usr/bin/g++-4.2 -arch x86_64 -dynamiclib -isysroot /Developer/SDKs/MacOSX10.6.sdk -Lsomepath -Fsomepath -filelist somefile -install_name somename -mmacosx-version-min=10.6 -single_module -compatibility_version 1 -current_version 1 -o somename
生成的项目：
/Developer/usr/bin/g++-4.2 -arch x86_64 -dynamiclib -Lsomepath -Fsomepath -filelist somefile -install_name somename -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 somelib.a somelib2.a somelib.dylib somelib2.dylib -single_module -compatibility_version 1 -current_version 1 -o somename
任何有关如何继续的帮助或提示将不胜感激。是否有任何 gcc 标志或其他工具可以帮助我解决此问题？
I'm in the process of porting a large'ish (~1M LOC) project from a Window/Visual Studio environment to other platforms, the first of which happens to be Mac OS X.
Originally the project was configured as Visual Studio solutions and projects, but now I'm using (the excellent) Premake (http://industriousone.com/premake) to generate project files for multiple platforms (VS, XCode, GMake).
I configured, ported and built the first few projects without any significant problems, but having ported the math lib, I ran into this weird linking error that I haven't been able to resolve: Any functions used from math.h will fail to link (causing unresolved symbols).
For reference, I'm using Premake v4.2.1 to generate projects for XCode v3.2.1, which is building using gcc v4.2 for the x86_64 architecture. (All this on 64-bit Snow Leopard) I've tried to persuade gcc to link and build everything against a 'known' SDK by adding -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 to the build command line.
Now under normal circumstances, adding -lm should take care of this, however in Darwin, those math libs are included in libSystem, which, as far as I can tell, gets implicitly linked by gcc/ld.
I've tried creating a dummy project from within XCode which just runs:
float f = log2(2.0)+log2f(3.f)+log1p(1.1)+log1pf(1.2f)+sin(8.0);
std::cout << f << std::endl;
and as expected, this builds just fine. However, if I put the same thing in the code inside the Premake generated project, all those math functions end up unresolved.
Now comparing the linking command from the 'native' XCode project with my generated XCode project, they seem pretty identical (except that my generated project links other libs as well).
'Native' project:
/Developer/usr/bin/g++-4.2 -arch x86_64 -dynamiclib -isysroot /Developer/SDKs/MacOSX10.6.sdk -Lsomepath -Fsomepath -filelist somefile -install_name somename -mmacosx-version-min=10.6 -single_module -compatibility_version 1 -current_version 1 -o somename
Generated project:
/Developer/usr/bin/g++-4.2 -arch x86_64 -dynamiclib -Lsomepath -Fsomepath -filelist somefile -install_name somename -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 somelib.a somelib2.a somelib.dylib somelib2.dylib -single_module -compatibility_version 1 -current_version 1 -o somename
Any help or hints about how to proceed would be most appreciated. Are there any gcc flags or other tools that can help me resolve this?
发布评论
评论（1）
我终于设法解决/解决这个问题。
按预期替换
通过
所有链接。
我会接受 cmath 解决方案可能是我应该首先编写的代码这一事实，尽管我很乐意接受关于为什么我的 C 方法如此惨败的进一步意见。
I finally managed to resolve/work-around this.
By replacing
with
everything links as expected.
I'll accept the fact that the cmath solution is probably the code I should have written in the first place, although I'd happily accept further opinions about why my C approach failed so miserably.