ld error in Xcode 7 beta 5: "building for OS X, but linking in object file built for (unknown)"

I figured out my issue.

Anyone having issues with the static openssl library as provided by the author of Receigen should see my gist which fixes his script to build the libraries properly for Xcode 7.

https://gist.github.com/dtrotzjr/0410c80faed1033fa312

Got a very similar error in XCode 7.1:

ld: building for iOS simulator, but linking against dylib built for OSX, file '/usr/lib/libc++.dylib' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Still looking around for the cause and/or a fix...

In Xcode 7, the linker enforces that all files linked together were built for the same platform. You control the platform via -mmacosx-version-min=XX or -miphoneos-version-min=XX compiler options.

You can see which platform an object file was built for by running “otool -lv” on the .a (or .o) file. and look for LC_VERSION. You should see LC_VERSION_MIN_IPHONEOS, LC_VERSION_MIN_MACOSX, LC_VERSION_MIN_WATCHOS, or LC_VERSION_MIN_TVOS.

Besides now longer being able to mix OSX intel binaries and simulator binaries, this means going forward, you need to build different libraries for the iOS, watchOS, and tvOS simulators.

That error sounds link the linker is finding the host (OSX) libc++.dylib instead of the simulator one. If you add -t to "Other Linker Flags" the linker will print out the full path to each file as it is processed. See which libc++.dylib it is finding and then look at the -L search paths on the command line. You probably have a stray -L (library search path) pointing to a dir with an OSX libc++.dylib in it.

Huh, thought that the i386 symbols in the host dylib would have worked for the simulator. The linker also specified ios_simulator_min and the simulator SDK, so I was hoping that the linker would know where to look... Doesn't make too much sense in retrospect.

Oddly enough, the linker command had no -L flags, but ld was indeed finding /usr/lib/libc++.dylib instead of the simulator one. Adding the iPhoneSimulator.sdk /usr/lib and /usr/lib/system manually got the build past that error. Thank you for your help! Now it's time to play "find the broken cmake file"...

hi vomako,

just installed the GM version and I have the same issue with the chilkat universal libs.

do you have a solution?

Hi ,

I am using the chilkat libs ( http://www.chilkatsoft.com/downloads_ios.asp) and I am encountering the same error like other persons here.

I am developing for iOS only , but receive the following error:

ld: in /Users/.../lib/libchilkatIos.a(CkoCrypt2.o), building for iOS simulator, but linking in object file built for OSX, for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

I am using the following script at the BUILD PHASES / RUN SCRIPT section at Xcode 7 to create one universal lib ( that worked fine at xcode 6.4 ) :

cd lib

/usr/bin/libtool -static i386/libchilkatIos.a x86_64/libchilkatIos.a armv7s/libchilkatIos.a armv7/libchilkatIos.a arm64/libchilkatIos.a -o libchilkatIos.a

cd ..

Can somone help, please ? It´s really urgent !

best regards

Jan

Note: xcode 7 final version from App store with the same problem like GM version

nickfromcupertino,

I have exactly the same issue with building static version of the Boost library for iPhone and than trying to use it in my app.

It appears that otool and lipo are contradicting eachother, I have a boost library and here is what I get for :

machina:lib dtsvetanova$ otool -lv libboost_atomic.a | grep LC_VERSION

cmd LC_VERSION_MIN_MACOSX

On the other hand lipo returns me the following:

machina:lib dtsvetanova$ xcrun -sdk iphoneos lipo -info libboost_atomic.a

Architectures in the fat file: libboost_atomic.a are: armv7 armv7s armv4t i386 x86_64

So it seems to me that I have a fat file build for iPhone, yet the linker doesn't like it.

Today I Update XCode 7.1 ,

And got a very similar error:

ld: in XXXX.a, building for iOS simulator, but linking in object file built for OSX, for architecture x86_64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

Still looking around for the cause and/or a fix...

Basically since Xcode 7.1 they have replaced the linker command with a new version:

macbookproloreto:~ admin$ cd /Applications/Xcode.app/Contents/Developer/usr/bin/
macbookproloreto:bin admin$ ls -l ld*
lrwxr-xr-x  1 root  wheel        6 25 Nov 16:31 ld -> ld-old
-rwxr-xr-x  1 root  wheel    17840 29 Ott 22:36 ld-new
-rwxr-x--x  1 root  wheel  1861488 25 Nov 16:30 ld-old
macbookproloreto:bin admin$ ./ld-old -v
@(#)PROGRAM:ld  PROJECT:ld64-253.3
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS)
macbookproloreto:bin admin$ ./ld-new -v
@(#)PROGRAM:ld  PROJECT:ld64-253.6
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS)
LTO support using: Apple LLVM 7.0.0 (clang-700.1.76)
macbookproloreto:bin admin$

And the combination of the ld version ld64-253.3 and Xcode 7.1 causes the error:

ld: in /MyLibrary/SDK/SpotifySDK/Spotify.a(SPTAlbum.o), building for tvOS, but linking in object file built for iOS, for architecture arm64

clang: error: linker command failed with exit code 1 (use -v to see invocation)

The last version of ld that worked to link iOS libraries against tvOS build was ld64-253.3.2

macbookproloreto:bin admin$ ./ld_old -v
@(#)PROGRAM:ld PROJECT:ld64-253.3.2 configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS) LTO support using: Apple LLVM 7.0.0 (clang-700.1.76)

This was shipped with

XCode Version 7.1 beta (7B60)

iOS9.0

Using Xcode 7.1 Beta and ld64-253.3.2 is the only option to build for AppleTVKit a iOS built libray. The DMG is this one

11667b8f7d4167c791789f29a44bb375916f93e6 Xcode_7.1_beta.dmg

But it is not available anymore on Apple Developers.