c++ - ___sincos_stret undefined symbol when linking

Question

Like previously referred here, ___sincos_stret can not be found when compiling a project that uses this symbol using the Xcode5 command line tools.

In the above referenced thread a solution is posted for IOS targets (passing -miphoneos-version-min=5.0 to the compiler), is there a solution for desktop (x64) targets?

It for example happens for me when trying to compile polycode.

Edit 2:

Strangely, after compiling the libraries referenced in the previous error manually, the error now happens to be located in lto.o, which is an internal llvm header itself...

undef: ___sincos_stret
Undefined symbols for architecture x86_64:
  "___sincos_stret", referenced from:
      _mdct_init in lto.o
      _dradfg in lto.o

I'm running OSX 10.9 DP with Xcode 5. This is the link step.

Answer 1

stret is Apple-speak for "returns a structure". ___sincos_stret is an LLVM optimisation — if you write code that calls sin(n) and then cos(n) and uses both results then the compiler will make one call to the structure-returning sincos method, receiving a structure with both things in it. It's faster to work out both at once rather than individually if the operand is the same.

On a superficial browsing I can't see a sin or cos in initInterTab2D but I expect something is being inlined.

While poking around I tried:

cd /Applications/Xcode.app/Contents/Developer/Platforms 
grep -lr ___sincos_stret *

Via that and using nm on likely results, I found the ___sincos_stret function is exposed in both iOS since 7.0 and OS X since 10.9 as part of their libsystem_m.dylibs. E.g. if your Xcode is installed in the default place, try:

nm /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS7.0.sdk/usr/lib/system/libsystem_m.dylib | grep sincos

And/or:

nm /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/system/libsystem_m.dylib | grep sincos

You'll see the symbol in either of those. So the correct solution would be to set an older deployment target in Xcode, or do the equivalent in your makefile.