I used "-no_pie" for LDFLAGS , but prompt: "ld: warning: -no_pie ignored for arm64".
then I use otool to check the binary ,there is no PIE flag with V7 and V7S cpusubtype,but still in ARM64,is the ld don't support -no_pie for ARM64?
This came up for me on an older ObjC project when I upped the Deployment Target from 9.0 to 10.0. It only occurred when I archived the project or when I ran it on a physical device. To removed the warning, I set the Build Setting 'Generate Position-Dependent Executable' to 'No'. It was previously set to 'Yes'.
Related
Trying for several days to build my flutter project in iOs (flutter build IPA) and I always seem to receive the same errors :
"_objc_msgSend$setIOSHasWarnedLocationServicesOff:", referenced from:
+[LocationAuthorization run:onCancel:] in TSLocationManager(LocationAuthorization.o)
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
There are a lot of them so I won't be putting all of them here but they're all related to _objc_msgSend$ and TSLocationManager.
I tried to add "-lc++" to Other Linker Flags in Build Settings (Runner Target)., related to this issue https://github.com/facebookarchive/pop/issues/25 but it still failing with more than 100 _objc_msgSend$ issues. I have frankly tried so many things and I'm quite out of clues.
Something I remarked is that when I build from Xcode (Product -» Build), it builds fine when I choose the Destination Device iPhone SE 3rd GEN, but I get the errors when the destination device into my physical device (which is plugged into my Mac).
When I hit flutter build IPA, it always fails.
^_^
First you can update your xcode to version14.0 above.
And the real reason is Apple Clang new optimization scheme._objc_msgSend stup support is not support on xcode13.
If you don't want upgrade your xcode version . You can follow next steps to change your private framework.
I guess you compiled a framework in xcode14 and then used it in xcode13
hh , now i saw you reply , make sure my answer
i'm using Xcode 13.4.1 and it's not having ARCHS_VALID as a build setting #editix –
Bertrand Gélinas
22 hours ago
By default, the clang in Xcode 14 will generate target files that cannot be understood by earlier native linkers.
In the future, it will be recommended to use Xcode14 and above for application package.
If you have private framework build by Xcode14.
Just add -fno-objc-msgsend-selector-stubs to your framework project target build settings other c flags, and build again, replace new framework to your other xcode project
or in your framework project chaneg your podspec file add xcconfig other c flags -fno-objc-msgsend-selector-stubs
or your own script build framework , you can before call xcodebuild command add a change , like thisxcodebuild -project xxx.xcodeproj build OTHER_CFLAGS="-fno-objc-msgsend-selector-stubs "
click on your target > build settings > VALID_ARCHS > and add the following :
arm64 arm64e armv7 armv7s x86_64
in case you didn't find the VALID_ARCHS do the following:
1- Click on the plus sign under the Build Settings.
2- Choose "Add user-defined settings" and it will add NEW_SETTING to you.
3- Rename the "NEW_SETTING" to "VALID_ARCHS" and add the following builds:
arm64 arm64e armv7 armv7s x86_64
if nothing fixed your issue please follow this you may find working answer:
Undefined symbols for architecture arm64
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.
This is the warning message appears when I compile my WatchKit 2 app
ignoring file
/Applications/Xcode.app/Contents/Developer/Platforms/WatchSimulator.platform/Developer/SDKs/WatchSimulator3.1.sdk/System/Library/Frameworks//WatchKit.framework/WatchKit,
file was built for i386 which is not the architecture being linked
(x86_64):
/Applications/Xcode.app/Contents/Developer/Platforms/WatchSimulator.platform/Developer/SDKs/WatchSimulator3.1.sdk/System/Library/Frameworks//WatchKit.framework/WatchKitld:
warning: ignoring file
/Applications/Xcode.app/Contents/Developer/Platforms/WatchSimulator.platform/Developer/SDKs/WatchSimulator3.1.sdk/System/Library/Frameworks//Foundation.framework/Foundation,
file was built for i386 which is not the architecture being linked
(x86_64):
/Applications/Xcode.app/Contents/Developer/Platforms/WatchSimulator.platform/Developer/SDKs/WatchSimulator3.1.sdk/System/Library/Frameworks//Foundation.framework/Foundation
And, finally, it failed to compile
ld: entry point (_main) undefined. for architecture x86_64
Architecture allowance in build setting is : i386 and x86_64.
However, if I force architecture to x86_64 only (which I dont want to apply for my project forever). There is another error
ld: illegal text-relocation to 'non_lazy_ptr' in
And I added OTHER_CFLAGS = $(inherited) -read_only_relocs suppress as recommended from some answers in stackoverflow.
But Xcode kept the same error message.
Edited: oh, my another mistake. This should be OTHER_LDFLAGS =... something.
Could any one give me any ideal how to overcome this.
Many thanks,
I figured out the problem.
Because I mistakenly set my WatchKit extension's architecture for WatchSimulator be i386 x86_64. Xcode automatically selected x86_64.
However, Watch Simulator SDK does not support x86_64. Because all current watch OS is built only for 32-bit architecture.
After I removed x86_64 from the architecture setting, Xcode builds my target with i386 architecture.
Then the warning and error disappeared.
Many thanks,
I built a small game using SDL2, SDL2_ttf, and SDL2_mixer. I ported it to Xcode and was able to run it with the iOS simulator just fine. I successfully built all of the SDL2 libraries with the target set to "iOS Device" and imported them into the Frameworks directory of my project. However, when I tried to archive the project with the target set to "iOS Device" I get the following error:
ld: entry point (_main) undefined. for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Is this issue casued b7 the SDL libraries I'm trying to link to or is it something else entirely?
I bet the SDL lib doesn't contain a valid armv7 slice but your app is being built for arm7 and arm64.
Check the SDL build settings and make sure that the 'valid architectures` include armv7
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/