I'm trying to update an iOS project from last year. When I load it into Xcode 5.1.1, I get about 40 of the following warning messages:
warning: /Applications/Xcode
5.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool:
-dynamic not specified, -all_load invalid /Applications/Xcode 5.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool:
-dynamic not specified the following flags are invalid: -ObjC
I even updated to the latest ShareKit and still have the same problem. I've checked the compiler and architecture settings and they look ok.
To fix this, you will need to remove "Other Linker Flags" from the build settings of the static library.
You can read more at:
http://www.cocoanetics.com/2013/02/xcode-4-6-libtool-issues/
Related
I'm building a project (the target is a framework if it's important) for tvOS and getting the error from the linker:
ld: building for tvOS, but linking in object file built for iOS, for architecture arm64
I ran otool -l *.o in OBJECTS_FILE_DIR_normal and figured out one of .o files is actually built for iOS instead of tvOS.
The problem is that there is no corresponding source file (*.mm or *.cpp) for that .o. It is called <ProjectName>_lto.o and I don't see any compiler invocations for that file in the build log. It appears only once in linker command line:
-Xlinker -object_path_lto -Xlinker /Full/path/to/<ProjectName>.build/Debug-appletvos/tvOS.build/Objects-normal/arm64/<ProjectName>_lto.o
LLVM_LTO build settings is not set explicitly, but it defaults to NO. Setting it to NO explicitly doesn't help.
I'm using Xcode 8.3.2 (8E2002).
So my question is: why is this object file created at all and why is it created for wrong target platform?
Not sure if this should be the answer to my own question or the edit, as it doesn't answer the original question "why that _lto.o file is generated at all for wrong arch with LLVM_LTO=NO", but it may help others troubleshoot this issue.
So I decided to try enabling LTO in the project. LLVM_LTO=YES_THIN behaved identically to LLVM_LTO=NO. LLVM_LTO=YES made linker produce tons of warnings like the following:
ld: warning: Linking two modules of different target triples: /path/to/one/of/3rdpary/libs/libproblematic.a(file1.o)' is 'arm64-apple-ios7.0.0' whereas 'ld-temp.o' is 'arm64-apple-tvos9.0.0'
ld: warning: Linking two modules of different target triples: /path/to/one/of/3rdpary/libs/libproblematic.a(file2.o)' is 'arm64-apple-ios7.0.0' whereas 'ld-temp.o' is 'arm64-apple-tvos9.0.0'
But with all those warnings for some weird reason the link succeeded. The interesting thing is that if I run otool -l libproblematic.a, I only see cmd LC_VERSION_MIN_TVOS lines and no cmd LC_VERSION_MIN_IPHONEOS and linker didn't complain on any of the objects from that library that they were built for wrong target platform. Also file1, file2, etc. do not appear in the output of otool -l libproblematic.a.
I just got this interesting error by upgrading to Xcode 8. It worked fine in Xcode 7. However, in Xcode 8 it gives me a linker error:
ld: 2562 duplicate symbols for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Frameworks I'm using:
Frameworks search path:
$(PROJECT_DIR)/My\ App
Linker Flags: (Obj-C)
$(inherited)
I'm not using pods. I've just copied over the frameworks to the project directory.
Xcode recommended to use warning flags and set GCC_NO_COMMON_BLOCKS to YES.
Setting it back to NO solved the problem!
I have an Xcode cocoa touch framework project that links to various static libraries in the "Other linker flags" option. The project can compile successfully.
However, after I add the "all_load" or "force_load" flag into the "other linker flags" field, I received numerous errors for undefined symbols for architecture arm64 or armv7.
I tried the "File" command on all the static libraries for which I'm linking against, and all of them include architectures armv7 and arm64.
I have no idea how I should go about investigating this issue...any help is greatly appreciated.
EDIT 1:
I've just upgraded my app to run on the new iPhone5 simulator, however when I try to build it for my iPhone 4S device, I get this Apple Mach-O Liner error.
ld: file is universal (3 slices) but does not contain a(n) armv7s
slice: /Users/Darren/Documents/Dev stuff/My
App/GoogleAdMobAdsSDKiOS-5.0.5/libGoogleAdMobAds.a for architecture
armv7s clang: error: linker command failed with exit code 1 (use -v to
see invocation)
Can someone shed some light on what this error it and how to fix it?
I am using adWhirl with AdMob.
Thanks
EDIT ---
I am also getting this error in another project for the file libfacebook_ios_sdk.a
The same answer as I gave in this thread:
If you want to remove the support for any architecture, try this:
Project -> Build Settings -> remove the architecture from "valid architectures"
You can use this as a temporary solution until the library has been updated. You have to remove the flag from your own project.
iPhone5's cpu is A6(armv7s).
The existing Admob sdk does not support it.
We have to wait for admob to update the sdk.
Update to Admob 6.2.0 or later.
See this post: http://googleadsdeveloper.blogspot.com/2012/09/migrating-to-admob-v62-for-ios.html.
Also, include the AdSupport framework and remove the -all_load flag.
You've got to use the -ObjC flag however.
This works for me, finally!!
Try this:
This article copy an armv7 lib code as an armv7s and build into the original lib. so xcode will see that lib has an armv7s code/arch
http://www.galloway.me.uk/2012/09/hacking-up-an-armv7s-library/
Starting from some point in the past xCode 4 in complaining about linker problems:
ld: warning: building for MacOSX, but linking against dylib built for
iOS:
/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk/System/Library/Frameworks//CoreGraphics.framework/CoreGraphics
I have checked everything but still nothing suspicious in the config and it compiles and runs.
The only thing that I see it is double slashes before CoreGraphics.framework, why I do not know. Tried remove and add again library on "Build phases" that did not help.
Sometimes it's easier to debug Xcode problems by looking at the build log for the command lines it's using.
If you're building from the command line, you can get that message if you don't specify -miphoneos-version-min=
This compiles:
(where conftest.c just contains int main() {})
/Applications/Xcode5.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch i386 --sysroot /Applications/Xcode5.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk --sysroot /Applications/Xcode5.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.0.sdk -miphoneos-version-min=6.0 conftest.c
And this gives the error:
/Applications/Xcode5.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -arch i386 --sysroot /Applications/Xcode5.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk --sysroot /Applications/Xcode5.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk conftest.c
ld: building for MacOSX, but linking against dylib built for iOS Simulator file '/Applications/Xcode5.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.0.sdk/usr/lib/libSystem.dylib' for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Check your Framework Search Paths for your Main target and your test Target.
I had a lot of crap in mine.
had old project written in XCode 4 and just started to use Unit Tests in XCode 5.
Here's the minimum I have to get my test project to run
Project Navigator > click on project at top >
Targets > Build Settings > Framework Search Paths
TARGET:my_project
$(inherited)
"$(SRCROOT)"
"$(SRCROOT)/my_project"
TEST:my_projectTests
"$(SDKROOT)/Developer/Library/Frameworks" <<XCTest.framework is here
"$(DEVELOPER_LIBRARY_DIR)/Frameworks"
"$(SRCROOT)/.."
"$(SRCROOT)" << Documents/my_project
"$(SRCROOT)/my_project" << Documents/my_project/my_project
where directory structure is
Documents/my_project
my_project.xcodeproj
/my_project
Note: If you drag a framework into XCode. XCode 5 has bad habit of hardcoding the path
/Users/gbxc/Documents/my_project
should be
"$(SRCROOT)" << Documents/my_project
"$(SRCROOT)/my_project" << Documents/my_project/my_project
so if you moved your project might get problems
Best way to check whats correct is to create a new single view project that runs tests ok.
Run the Test action
By default it fails but at least testing is running
then compare the Framework Search Paths.
If you're using Carthage and compiling a Mac app, search on your project's Framework Search Paths you might find something like $(PROJECT_DIR)/Carthage/Build/iOS.
Removing that fixed my issue.
This issue is due to include a wrong framework version in Xcode. The project is built for Mac OS X, but it uses iOS version's framework.