Xcode 11.4 : Building for iOS Simulator but the linked library was built for Mac OS + iOS

Question

robby28 OP

Created Mar ’20

Replies 23

Boosts 0

Views 46k

Participants 15

In Xode 11.4, I encounter a failure in my project.

When running my project, it was successfull in Xcode 11.3. Now in Xcode 11.4 I get the failure message:

Target Integrity: Building for ios simulator but the linked library ' my_library.a ' was built for may OS + ios.

The library " my_library.a is pointed to architecture: x86_64 and arm64 and never changed

I can run the Project on my device, but it is not running in the simulator.

Please help me what to do in Xcode 11.4. Do I have to change settings in Xcode 11.4.

regards, Robert

Answered by DTS Engineer in 412062022

Having x86_64 code is not sufficient to distinguish if a binary is intended for the iOS Simulator, a macOS app, or a Mac Catalyst app. Combing built binaries across different destinations (which includes the simulator vs. device binaries) is not a supported combination -- there is no Apple platform where ARM code and x86_64 code in the same binary is a correct configuration.

If this is your library, you should have your app build it from source as a dependency of your Xcode project, either through an Xcode target or through Swift Package Manager, so that the right platform information is included based on the build target.

If this is your library but you have a specific reason for it to be pre-compiled, please build it as an XCFramework. XCFrameworks correctly separate out binaries that have the right architectures for the different platforms you target. In addition to instructions on how to build such a XCFramework linked earlier, we have a WWDC talk illustrating it.

If this library is from a framework vendor (either as source or a pre-compiled binary), or you integrate a vendor's library into your app with a third party dependency manager, please consult with the library vendor or dependency manager for support.

Boost

Answer 1

lifjoy OP

Apr ’20

@robby28: Bosian's solution worked for me. My code also needed to only include references to the framework when not building for simulator, like so:

#if ! TARGET_IPHONE_SIMULATOR
#import <myDeviceOnlyFramework>
#endif

That should prevent linking failure errors.

0

Answer 2

ccamargo OP

Apr ’20

I totally support you! Not even a note in the Release Notes of Xcode 11.4. I'm struggling with a similar problem for days now and the only thing that I have to support my need for recompilation of a third-party lib is a forum's answer. That's not good. This kind of disruption is not helpful for anyone.

0

Answer 3

vade OP

Apr ’20

@ccmargo - totally concur. Its beyond me why this is now a critical error.
I cant even strip a universal library down to its x86_64 arch in a script file phase, it errors prior to hitting the script. This is a huge disruption to developers who rely on 3rd party tooling.
Why does Apple constantly have to re-invent the wheel?

2

Answer 4

cdissauer OP

May ’20

We encountered the same problem. This is what I found out:

When a static library is added to the Xcode project (through Build Phases -> Link Binary With Libraries -> Add Other), Xcode automatically adds the relative path to that .a file to its file reference entry.

Prior to Xcode 11.4, this path was apparently removed during build, and replaced by the evaluated path generated from the current build settings, i.e. the actual configuration (Debug/Release) and the actual platform (iphoneos or iphonesimulator).

Starting from Xcode 11.4 however, this is apparently not happening anymore, and the build system is always using the explicit path set when the library was added.

By manually editing the project.pbxproj file for the iOS project, I removed the "path" attribute from the respective entries, e.g. changed from

  A15F487B16C934CE00D6F824 /* libmurl_engine.a */ = {
    isa = PBXFileReference;
    lastKnownFileType = archive.ar;
    name = libmurl_engine.a;
    path = "ios/Release-iphoneos/libmurl_engine.a";
    sourceTree = "";
  };

to

  A15F487B16C934CE00D6F824 /* libmurl_engine.a */ = {
    isa = PBXFileReference;
    lastKnownFileType = archive.ar;
    name = libmurl_engine.a;
    sourceTree = "";
  };

After this change, I was able to compile the project for both the actual iOS target as well as the simulator.

Hope that helps.

2

Answer 5

dimka70007 OP

Jul ’20

wtf? guys. i have precompiled sdk framework since 2017 year. It worked fine till xcode 11.4 updating. Why had apple broken backward compatibility for long time working precompiled Objective C frameworks? Why had they broken compatibility between precompiled swift frameworks also? What they will break next? Mac OS ?

1

Answer 6

dimka70007 OP

Jul ’20

Ah sorry guys. This was my mistake when using git lfs with cocoapods. Xcode 11.5 successfully completed compilation after properly resolving packages using git lfs.
But the problem with recompiling the swift sdk framework after each new xcode release still persists.

0

Answer 7

abrakadabra OP

Jul ’20

I was facing this error with OpenEdgeSDK when trying to build app in simulator, on Xcode 11.6. Wasnt facing the error in Xcode 11.3.
I tried exclusion of '***.a' but it didn't work. Changing shared workspace build system from New Build System to Legacy worked for me.

1

Answer 8

ePirat OP

Sep ’20

@edford How is this supposed to be handled when building a static library that contains assembly objects, assembled by yasm or nasm, which have no way to set the needed options indicating what exact target/version it's building for?

2