So, as part of my effort to learn Swift, I got my hands on the open source "Adventure" project (found HERE) made available by Apple.
Embarrassingly, I didn't go too far before I ran into my first predicament. When I tried to compile the project, I got the following error:
'UIApplicationMain' attribute cannot be used in a module that contains top-level code'
Specifically, the error is found in the AppDelegate.swift file and the attribute comes immediately after the import UIKit declaration as follows:
import UIKit
#UIApplicationMain
class AppDelegate: NSObject, UIApplicationDelegate {
var window: UIWindow?
....
// a number of functions that I won't list here...
....
}
I did some research on this but understandably(?) there doesn't seem to be much information regarding this issue. I wonder if anyone has run into the same issue.
(By the way, I am using Xcode6-beta5)
EDIT 1 --------------
Now with a fresh install of Beta6, I get the following errors after compile:
Undefined symbols for architecture x86_64:
"TFSs15_arrayForceCastU___FGSaQ__GSaQ0", referenced from:
__TFC9Adventure13HeroCharacter20animationDidCompletefS0_FOS_14AnimationStateT_ in HeroCharacter.o
__TFC9Adventure13HeroCharacter14fireProjectilefS0_FT_T_ in HeroCharacter.o
__TFC9Adventure4Cave15applyCaveDamagefS0_FTSd10projectileCSo6SKNode_T_ in Cave.o
__TFC9Adventure4Cave12performDeathfS0_FT_T_ in Cave.o
__TFFC9Adventure4Cave16loadSharedAssetsFMS0_FT_T_U_FT_T_ in Cave.o
__TFC9Adventure6Goblin20animationDidCompletefS0_FOS_14AnimationStateT_ in Goblin.o
__TFFC9Adventure6Goblin16loadSharedAssetsFMS0_FT_T_U_FT_T_ in Goblin.o
...
"__TFSsoi1aUSs17_RawOptionSetType_USs21BitwiseOperationsTypeSs9Equatable__FTQ_Q__Q_", referenced from:
__TFC9Adventure21LayeredCharacterScene14handleKeyEventfS0_FTCSo7NSEvent7keyDownSb_T_ in LayeredCharacterSceneOSXEvents.o
"__TFVSC6CGSizeCfMS_FT5widthSd6heightSd_S_", referenced from:
__TFFC9Adventure6Archer16loadSharedAssetsFMS0_FT_T_U_FT_T_ in Archer.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1
I'm not even going to try to guess what these errors mean.
Apparently the Adventure project doesn't compile correctly in Xcode6-Beta5. However, Xcode6-Beta6 compiles and runs it just fine.
As for the error encountered after upgrading to Beta6, the way to fix that is to delete the derived data for the project. To do that, open the Organizer ("Window" menu -> "Organizer"), select the "Adventure" project on the left side of the window, then click the "Delete" button associated with the project's derived data (should be the top one on the far right).
For me, It seems there was another file called main.swift which was conflicting with my AppDelegate. I deleted it and the issue went away.
I now have the same question with above title but have not found the right answer yet. I got the error:
/Users/nle/Library/Developer/Xcode/DerivedData/TestMoboSDK-Client-cgodalyxmwqzynaxfbbewrooymnq/Build/Intermediates/TestMoboSDK-Client.build/Debug-iphonesimulator/TestMoboSDK-Client.build/Objects-normal/x86_64/MoboSDK.o
/Users/nle/Library/Developer/Xcode/DerivedData/TestMoboSDK-Client-cgodalyxmwqzynaxfbbewrooymnq/Build/Products/Debug-iphonesimulator/libMoboSDK.a(MoboSDK.o)
duplicate symbol _OBJC_METACLASS_$_MoboSDK in:
/Users/nle/Library/Developer/Xcode/DerivedData/TestMoboSDK-Client-cgodalyxmwqzynaxfbbewrooymnq/Build/Intermediates/TestMoboSDK-Client.build/Debug-iphonesimulator/TestMoboSDK-Client.build/Objects-normal/x86_64/MoboSDK.o
/Users/nle/Library/Developer/Xcode/DerivedData/TestMoboSDK-Client-cgodalyxmwqzynaxfbbewrooymnq/Build/Products/Debug-iphonesimulator/libMoboSDK.a(MoboSDK.o)
ld: 75 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Any help is appreciated.
Finally I find out the reason of this error cause I added -ObjC to the Other Linker Flags. After remove this value then I can build my project successfully, but I don't know why. Can anyone explain this?
For me, changing 'No Common Blocks' from Yes to No ( under Targets->Build Settings->Apple LLVM - Code Generation ) fixed the problem.
Stupid one, but make sure you haven't #imported a .m file by mistake somewhere
75 duplicate symbols for architecture x86_64
Means that you have loaded same functions twice.
As the issue disappear after removing -ObjC from Other Linker Flags,
this means that this option result that functions loads twice:
from Technical Q&A
This flag causes the linker to load every object file in the library
that defines an Objective-C class or category. While this option will
typically result in a larger executable (due to additional object code
loaded into the application), it will allow the successful creation of
effective Objective-C static libraries that contain categories on
existing classes.
https://developer.apple.com/library/content/qa/qa1490/_index.html
In my case, I just created a header file to define constant strings like this:
NSString *const AppDescriptionString = #"Healthy is the best way to keep fit";
I solved this scenario by using static:
static NSString *const AppDescriptionString = #"Healthy is the best way to keep fit";
Happens also when you declare const variables with same name in different class:
in file Message.m
const int kMessageLength = 36;
#implementation Message
#end
in file Chat.m
const int kMessageLength = 20;
#implementation Chat
#end
I have same problem.
In Xcode 7.2 in path Project Target > Build Setting > No Common Blocks, i change it to NO.
I found the accepted answer touches on the problem but didn't help me solve it, hopefully this answer will help with this very frustrating issue.
duplicate symbol _OBJC_IVAR_$_BLoginViewController._hud in:
17 duplicate symbols for architecture x86_64
"Means that you have loaded same functions twice. As the issue disappear after removing -ObjC from Other Linker Flags, this means that this option result that functions loads twice:"
In layman's terms this means we have two files in our project with exactly the same name. Maybe you are combining one project into another one? Have a look at the errors above the "duplicate symbols" error to see which folder is duplicated, in my case it was BLoginViewController.
For example, in the image below you can see I have two BImageViewControllers, for me this is what was causing the issue.
As soon as I deleted one then the issue vanished :)
This occurred on me when I accepted "recommended settings" pop-up on a project that I develop two years ago in Objective-C.
The problem was that when you accepted the "recommended settings" update, Xcode automatically changed or added some build settings, including GCC_NO_COMMON_BLOCKS = YES;.
This made the build failed with the duplicate symbol error in my updated project. So I changed No Common Block to NO in my build settings and the error was gone.
I experienced this issue after installing Cocoapods. Now happens everytime I update some pods. Solution I've found:
Go to terminal:
1) pod deintegrate
2) pod install
Also, check the item "Always Embed Swift Libraries" in your Build Settings. It should be "faded" indicating it is using the default configuration. If its set to a manual YES, hit delete over it to revert it to the default configuration. This stopped the behavior.
Fastest way to find the duplicate is:
Go to Targets
Go to Build Phases
Go to Compile Sources
Delete duplicate files.
Go to Targets
Select Build Settings
Search for "No Common Blocks", select it to NO.
It worked for me
Following steps solved the issue for me.
Go to Build Phases in Target settings.
Go to “Link Binary With Libraries”.
Check if any of the libraries exist twice.
Build again.
Remove -ObjC from Other Linker Flags or
Please check you imported any .m file instead of .h by mistake.
Update answer for 2021, Xcode 12.X:
pod deintegrate
pod install
Hope this helps!
My situation with some legacy project opened in Xcode 7.3 was:
duplicate symbol _SomeEnumState in:
followed with list of two unrelated files.o, then this was repeated couple of times, then finally:
ld: 8 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
What solved it for me was changing enum declaration from:
enum SomeEnumState {
SomeEnumStateActive = 0,
SomeEnumStateUsed = 1,
SomeEnumStateHidden = 2
} SomeEnumState;
to this:
typedef NS_ENUM(NSUInteger, SomeEnumState) {
SomeEnumStateActive = 0,
SomeEnumStateUsed = 1,
SomeEnumStateHidden = 2
};
If somebody has explanation for this, please enlighten me.
Defining same variable under #implementation in more than one class also can cause this problem.
In my case, there were two file by same name in the location
Targets > Build Phases > Compile Sources and delete any duplicate files.
For me during the Xcode8 recommended project settings update "No Common Blocks" to YES which causes this issue.
My problem was that I had 5 duplicate symbols for architecture x86_64. After reading this post and their answers, I try with the common solution about change GCC_NO_COMMON_BLOCKS = YES to NO
But, instead of working for me, I went from 5 duplicates to 1 duplicate...
So, I paid attention to that last error, and I realized what was my problem, and it was an "incompatibility" with these packages (I had both in package.json):
rn-fetch-blob
react-native-blob-util
The message was clear about it, and I remove rn-fetch-blob because I have not idea why it was in my project, but, I only used with jest and delete it, it wasn't a problem.
So, after removing that package, and run yarn again, problem solved... And without changing the GCC_NO_COMMON_BLOCKS
Today , I got the same error . The error's key word is duplicate. I fix it by:
1. Remove the duplicate file at Build Phases-->Compile Sources
2. If you can not remove it at Build Phases, you need find the file at your project and remove the reference by DELETE :
3. Add the file to your project again
4. Add the file's .m to your Build Phases-->Compile Sources again
5. Build your project, the error will disappear
Another silly mistake that will cause this error is repeated files. I accidentally copied some files twice. First I went to Targets -> Build Phases -> Compile sources. There I noticed some files on that list twice and their locations.
Make sure you haven't imported a .m file by accident, you might want to delete your derived data in the Projects Window and then build and run again.
I got the same error when I added a pod repository
pod 'SWRevealViewController'
for an already added source code (SWRevealViewController) from gitHub. So, the error will be fixed by either removing the source code or pod repository.
Case # 2:
The 2nd time, this error appeared when I declare a constant in .h file.
NSString * const SomeConstant = #"SomeValue";
#interface AppDelegate : UIResponder <UIApplicationDelegate> {
...
...
None of above solutions works for me, I just fixed it myself.
I got duplicate symbol of my core data model which I make it myself, but
in my .xcdatamodeld inspector, I choose Class Definition of Codegen property, I guess that's what's wrong with. Then I choose Manual/None,it got fixed.
Hope this can be helpful for you!
For anyone else who is having this issue, I didn't see my resolution in any of these answers.
After having a .pbxproj merge conflict which was manually addressed (albeit poorly), there were duplicate references to individual class files in the .pbxproj. Deleting those from the Project > Build Phases > Compile Sources fixed everything for me.
Hope this helps someone down the line.
Similar to Juice007, I had declared and initialized a C type variable in two different .m files (that weren't imported!)
BOOL myVar = NO;
however, this method of declaring and initializing a variable, even in .m, even in #implementation grants it global scope. Your options are:
Declare it as static, to limit the scope to class:
static BOOL myVar = NO;
Remove the initialization (which will make the two classes share the global var):
BOOL myVar;
-(void) init{
myVar = NO;
}
Declare it as a property:
#property BOOL myVar;
Declare it as a proper iVar in the #interface
#interface myClass(){
BOOL myVar;
}
#end
In my case I had two main() methods defined in my project and removing one solved the issue.
The answers above didn't work for me. Here's how I got around it:
1) in finder, delete the entire Pods folder and Podfile.lock file
2) close the xcode project
3) run pod install in the terminal
4) open the xcode project, run the clean build command
Worked for me after that.
Because I haven't seen this answer:
Uninstall and reinstall your podfiles! Remove or uninstall library previously added : cocoapods
I've run into this issue over 3 times building my app and every time this is what fixes it. :)
I've just had this error as well. Found that the problem was variables declared with global scope, with the same names, were being repeated throughout the files being compiled into the program. Once changing the global variables to local scope to the pseudo-main function the error was resolved.
I have create a bunch of .o files (via gcc -c $file.c $someotherops -o $file.o). Now I want to link them into a static library.
I'm not exactly sure wether I am supposed to use ld or gcc for this. In the ld manual, it is said that I'm not supposed to use it directly. However, I cannot figure out the gcc parameters to create a static library.
I tried ld *.o -static -o libfoo.a but it complains about a lot of missing symbols (I think all from libc). I don't understand why it complains because it is supposed to be a static library. I thought it would check for the symbols once I link that static library to some other thing.
Another thing: I use /Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/ld here (my target is iOS). It complains with the warning ld: warning: using ld_classic. What is this about?
Then I thought, maybe it needs to have the dynamic libraries specified. So I added -lc to link against libc. But it complains with can't locate file for: -lc. I added -L/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.0.sdk/usr/lib and there is a libc.dylib.
Any ideas?
About the -lc error: It got away after I specified -arch armv6. Then it complained about a wrong libcache.dylib (which must be linked from libc.dylib I guess because it didn't specified it). Adding -L.../usr/lib/system helped.
Now, for each single .o file, I get the warning ld: warning: CPU_SUBTYPE_ARM_ALL subtype is deprecated. What is this about?
And I still have a bunch of missing symbols, esp:
Undefined symbols for architecture armv6:
"start", referenced from:
-u command line option
(maybe you meant: _PyThread_start_new_thread)
"___udivsi3", referenced from:
_get_len_of_range in bltinmodule.o
_quorem in dtoa.o
_array_resize in arraymodule.o
_newarrayobject in arraymodule.o
_array_fromfile in arraymodule.o
_get_len_of_range in rangeobject.o
_inplace_divrem1 in longobject.o
...
"___unorddf2", referenced from:
_builtin_round in bltinmodule.o
...
I checked some of those symbols, e.g. ___udivsi3 in get_len_of_range. This function uses C arithmetic only, no external call. So this seems to be translated to use some external functions like ___udivsi3. But what libraries is this in?
-lgcc_s.1 fixed most of the ___udivsi3 and related missing symbols. The start symbol is still missing. What does -u command line option mean?
From here, I got the feeling that maybe ld isn't the right tool after all. There, a simple call to aris used. And this seem to make more sense. I will check if that does work and transform this into an answer then.
While playing more around, ar throw some warnings at me when building a fat static library. It gave me the hint to use libtool instead. That is what I'm doing now, i.e. libtool -static -o libfoo.a *.o. Also I switched the compiler to /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clangbut not sure if that matters.
Now, at compiling some test application which links to this static library, I get these warnings:
ld: warning: PIE disabled. Absolute addressing (perhaps -mdynamic-no-pic) not allowed in code signed PIE, but used in __PyBuiltin_Init from /Users/az/Programmierung/python-embedded/libpython.a(bltinmodule.o). To fix this warning, don't compile with -mdynamic-no-pic or link with -Wl,-no_pie
ld: warning: 32-bit absolute address out of range (0x1001B70C4 max is 4GB): from _usedpools + 0x00000004 (0x001B70CC) to 0x1001B70C4
ld: warning: 32-bit absolute address out of range (0x1001B70C4 max is 4GB): from _usedpools + 0x00000000 (0x001B70CC) to 0x1001B70C4
What are they about? I don't use -mdynamic-no-pic. I also don't really see in _PyBuiltin_Init how I use absolute addressing there.
Also, what are these absolute addresses out of range about? Edit: These were some really huge allocations. I just removed this code for now (this was WITH_PYMALLOC, if anyone is interested in these specific Python internals).
When I start it on my iPhone, I get the abort:
dyld: vm_protect(0x00001000, 0x00173000, false, 0x07) failed, result=2 for segment __TEXT in /var/mobile/Applications/C15D9525-E7DC-4463-B05B-D39C9CA24319/...
When I use -no_pie for linking, it doesn't even link. It fails with:
Illegal text-relocation to ___stderrp in /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS5.1.sdk/usr/lib/libSystem.dylib from _read_object in /Users/az/Programmierung/python-embedded/libpython.a(marshal.o) for architecture armv7
I solved the PIE disabled, Absolute addressing error. I had a -static in my command line Clang. Once I removed that, the warning got away, as well as the dyld/vm_protect error. It was the first time it actually run some code.
Until I hit another strange error about integer comparison. Whereby this looks more like a bug in their Clang build.
It all works now. Basically, the answer is:
Just compile every *.c file as usual to *.o files. The only real difference is the different GCC/Clang, the -arch armv7, the different SDK / include dirs.
Use libtool -static -o libfoo.a *.o to build the static library.
That's it. The other problems in my question were just wrongly headed tries.
If anyone gets here by searching for the dyld: vm_protect(...) runtime error but you are using XCode, the -static flag mentioned in the OP is likely the issue.
Get rid of it by switching "Enable linking with shared libraries" to "Yes" (the default) in the LLVM compiler language settings. (This removes GCC_LINK_WITH_DYNAMIC_LIBRARIES = NO from the project file).