Xcode 6 introduces Mach-O linker errors building for simulator

Unity Engine
,
1

After successfully building for a physical device, I’m unable to build for the simulator, getting Mach-O Linker errors. The Internet speaks of both clearing project DerivedData and setting target architectures, both of which fail for me.

I am using Unity 4.5.5p5. Building to a clean project folder, Xcode’s architecture settings for the project are:

Architectures - i386
Base SDK - iPhoneSimulator (SDK not found)
Supported Platforms - iphonesimulator
Valid Architectures - i386 x86_64

I can change the Base SDK to iOS 8.1 which changes the Valid Architectures to arm64 arm7 arm7s but I still get the linker errors.

If I change the Valid Architectures to only arm7 or arm7s it still fails.

I can also change the Architectures to Standard Architectures:

Architectures - Standard Architectures (armv7 arm64)
Base SDK - iPhoneSimulator (SDK not found)
Supported Platforms - iOS
Valid Architectures - armv7

It’s the same whether I have Unity’s target set to iOS6 or iOS8.1. With Xcode 5 and Unity 4.5.2, I could just build for the simulator and it’d work. How do I fix this?

2

In addition, a blank Unity project (one scene, a capsule and a light) has the same Mach-O errors, so it’s not caused by a plugin.

Errors look like this (default build settings, so 386 target):

3

are you building with Simulator SDK selected in PlayerSettings ?

  • simulator builds have its own share of issues, but this looks like you are building with Device SDK selected
4

Yep, using Simulator SDK.

5

Just try to run your project in old xcode version. I think in that your builded project will work.

6

I’m having exactly the same issue with 4.5.5p5. Building and running to a hardware iPhone works fine; trying to build towards the simulator fails with the list of linker errors I’ve pasted below. Looks like the project is missing a link to a pretty basic system lib.

This is obviously an issue with the project built by Unity, rather than an issue with XCode - I upgraded Unity to 4.5.5p5 today, and everything was happy until I did that.

Undefined symbols for architecture i386:

“_closedir$UNIX2003”, referenced from:
_find_in_dir in libiPhone-lib.a(mono-io-portability.o)
_mono_portability_find_file in libiPhone-lib.a(mono-io-portability.o)
_g_dir_rewind in libiPhone-lib.a(libeglib_la-gdir-unix.o)
_g_dir_close in libiPhone-lib.a(libeglib_la-gdir-unix.o)
“_fdopen$UNIX2003”, referenced from:
_try_addr2line in libiPhone-lib.a(profiler.o)
_mono_disassemble_code in libiPhone-lib.a(helpers.o)
_mono_compile_assembly in libiPhone-lib.a(aot-compiler.o)
“_fopen$UNIX2003”, referenced from:
_GetLogicalDriveStrings in libiPhone-lib.a(io.o)
_GetDriveType in libiPhone-lib.a(io.o)
_mono_main in libiPhone-lib.a(driver.o)
_mono_profiler_install_simple in libiPhone-lib.a(profiler.o)
_load_profile_files in libiPhone-lib.a(aot-compiler.o)
_mono_compile_assembly in libiPhone-lib.a(aot-compiler.o)
_mono_xdebug_init in libiPhone-lib.a(aot-compiler.o)
…

“_fputs$UNIX2003”, referenced from:
_mini_regression in libiPhone-lib.a(driver.o)
_mono_print_thread_dump_internal in libiPhone-lib.a(mini-exceptions.o)
_asm_writer_emit_bytes in libiPhone-lib.a(image-writer.o)
“_fwrite$UNIX2003”, referenced from:
_ipc_connect in libiPhone-lib.a(attach.o)
_receiver_thread in libiPhone-lib.a(attach.o)
_emit_marshal_safehandle in libiPhone-lib.a(marshal.o)
_emit_marshal_handleref in libiPhone-lib.a(marshal.o)
_parse_debug_options in libiPhone-lib.a(driver.o)
_mini_regression in libiPhone-lib.a(driver.o)
_mini_usage_jitdeveloper in libiPhone-lib.a(driver.o)
…

“_mktime$UNIX2003”, referenced from:
_ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData in libiPhone-lib.a(icall.o)

“_nanosleep$UNIX2003”, referenced from:
__wapi_handle_spin in libiPhone-lib.a(handles.o)
_SleepEx in libiPhone-lib.a(wthreads.o)
__wapi_handle_spin in libiPhone-lib.a(events.o)
__wapi_handle_spin in libiPhone-lib.a(processes.o)
_collection_thread in libiPhone-lib.a(collection.o)
__wapi_handle_spin in libiPhone-lib.a(shared.o)
_pthread_mutex_timedlock in libiPhone-lib.a(mono-mutex.o)
…

“_opendir$INODE64$UNIX2003”, referenced from:
_mono_portability_find_file in libiPhone-lib.a(mono-io-portability.o)
_g_dir_open in libiPhone-lib.a(libeglib_la-gdir-unix.o)
_g_dir_rewind in libiPhone-lib.a(libeglib_la-gdir-unix.o)
“_readdir$INODE64”, referenced from:
_find_in_dir in libiPhone-lib.a(mono-io-portability.o)
_g_dir_read_name in libiPhone-lib.a(libeglib_la-gdir-unix.o)
“_recv$UNIX2003”, referenced from:
_recv_length in libiPhone-lib.a(debugger-agent.o)
“_send$UNIX2003”, referenced from:
__wapi_send in libiPhone-lib.a(sockets.o)
_wapi_sendfile in libiPhone-lib.a(sockets.o)
_transport_handshake in libiPhone-lib.a(debugger-agent.o)
_transport_send in libiPhone-lib.a(debugger-agent.o)
“_setenv$UNIX2003”, referenced from:
_g_setenv in libiPhone-lib.a(libeglib_la-gmisc-unix.o)
“_sigaltstack$UNIX2003”, referenced from:
_mono_setup_altstack in libiPhone-lib.a(mini-exceptions.o)
_mono_free_altstack in libiPhone-lib.a(mini-exceptions.o)
“_sleep$UNIX2003”, referenced from:
_GC_sleep in libiPhone-lib.a(pthread_support.o)
“_strerror$UNIX2003”, referenced from:
_errno_to_WSA in libiPhone-lib.a(error.o)
_g_strerror in libiPhone-lib.a(libeglib_la-gstr.o)
_mono_assembly_load_reference in libiPhone-lib.a(assembly.o)
_ipc_connect in libiPhone-lib.a(attach.o)
_mono_image_strerror in libiPhone-lib.a(image.o)
_ves_icall_System_Security_Cryptography_RNGCryptoServiceProvider_RngGetBytes in libiPhone-lib.a(rand.o)
_g_dir_open in libiPhone-lib.a(libeglib_la-gdir-unix.o)
…

“_strftime$UNIX2003”, referenced from:
_ves_icall_System_CurrentSystemTimeZone_GetTimeZoneData in libiPhone-lib.a(icall.o)
“_system$UNIX2003”, referenced from:
_mono_disassemble_code in libiPhone-lib.a(helpers.o)
_compile_asm in libiPhone-lib.a(aot-compiler.o)
_mono_draw_graph in libiPhone-lib.a(graph.o)
“_unsetenv$UNIX2003”, referenced from:
_g_unsetenv in libiPhone-lib.a(libeglib_la-gmisc-unix.o)
“_waitpid$UNIX2003”, referenced from:
_waitfor_pid in libiPhone-lib.a(processes.o)
_process_wait in libiPhone-lib.a(processes.o)
_g_spawn_command_line_sync in libiPhone-lib.a(libeglib_la-gspawn.o)
_g_spawn_async_with_pipes in libiPhone-lib.a(libeglib_la-gspawn.o)
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)

7

I’ll give that a try, but there’s a more serious issue here. No project from Unity will build for simulator, making XCode 6 unusable (even if XCode 5 works). Looks like I need to try some uninstall/reinstall voodoo and hope I get lucky. :wink:

8

Don’t revert XCode, revert Unity. I walked back through the patches, and once I hit 4.5.5p2, the bug went away. 4.5.5p3 introduced the invalid project settings (whatever they are) that are causing the error.

1 Like
9

I generated my project settings from the p2 and p5 builds (using xcodebuild -ShowBuildSettings), and did a diff - there are no differences between the two project settings. The p5 build has the link errors, which implies that the problem is with the libraries being included with the Unity release, starting at 4.5.5p3.

10

I encounter the same issue just now.
So I end up trying all the simulators.
Yes, I’m using Simulator SDK when exporting from Unity.
The Simulator that have this problem is iPad Air, iPhone 6 & 6+, iPhone 5s.

On another note, is it normal that the xCode project spewing out the depreciating warnings?

11

Same problems here.
4.5.5p5 won’t build without above errors.
But previous versions don’t include 8.0 and 8.1 IOS SDK.

12

I read that now unity solve this bug and in new release of unity there is no bug found in exported project.
I have check this thing with Unity4.5.5 and XCode version 6.1.

You can try this also.

13

Yes, 4.5.5 doesn’t have this bug, because it starts in 4.5.5p3. The problem is, I want iOS 8 support, which only starts in 4.5.5p5. Reverting to 4.5.5 doesn’t help.

14

Many thanks to kineticabstract, who presumably was searching the web for support on his issue. 4.5.5p3 would build (although introduced a crazy bug where some builds of exactly the same code wouldn’t animate sprites!).

Looks like Unity need to fix this, ASAP. Not least because soon we’ll have to have arm64 support for apps.

15

I can confirm this on my project too. I moved from 4.5.5f1 to 4.5.5p5 in order to have all of the iPhone 6 and 6+ splash screen and icon sizes to smooth things out for submission and to be as up-to-date as possible, since Apple seems to like that. I tried to build for the Simulator so I could take screenshots at all sizes for iTunesConnect (and I’ve just remembered I have to Photoshop out the ‘Development Build’ watermark that Unity insists on putting in the corner on projects built for Simulator - there’s an hour or two of my time wasted, grrr…). Anyway, I got the same 20 errors other users in this thread have reported. I worked and worked at this, including libraries manually, doing fresh builds to new folders, etc. Same thing every time. Reverted back to 4.5.5p2, as suggested above - and those troubles went away. I was able to build to Simulator, take screenshots and everything.

If you need to build for Simulator in iOS - stay away from 4.5.5 patches 3 through 5 for now. That’s my experience, at least.

– Anthony

16

At recent I have following configuration working environment, Unity version 4.5.5p3 and xCode version 6.1.
Then I export xCode project and there is no issues at all.
One thing I want mention that project created in same unity version not any previous version.

17

Has anyone tried with 4.6.1 to see if this is still a problem?

18

Any progress on this? I am currently using unity 4.5.5p5 with xCode 6.1 and I can’t build for any simulator :frowning:

19

Using unity 4.6.1 and xCode 6.1 and I have the same problem… :frowning: 201 Mach-O linker errors
I just can run it on physical devices, even changing target to “iOs”, not “iphoneos”

20

The bug is marked fixed in the Unity bug tracker for 4.6.1. Works fine for me on 4.6.2 and xCode 6.1.1 (after running into issues with 4.5.5p5). Maybe you forgot to ‘replace’ your project when building? If you just do a cmd-B build, it will not regenerate the project and probably wouldn’t work.

Doesn’t help folks who can only take patch updates… but seemed worth mentioning.