typedef in separate header file - objective-c

I have a defines.h file with following code
typedef enum AnswerType : NSUInteger {
kAnswerTypeNotResponded = 0,
kAnswerTypeYes = 1,
kAnswerTypeNo = 2,
kAnswerTypeComplain = 3
} AnswerType;
When I import this file in several other files - I get an error
ld: 13 duplicate symbols for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I need AnswerType be visible in many places. What is the best variant to implement it?

Your enum looks fine. However, I guess there should be another problem.
One of the major reason for occurrence of this issue is that you might have a file listed in build phases more then once. So you need to make sure that files are listed in build phases only once.
Here are the steps you can follow:
Check Build phases in Target settings.
Check if any file exists twice.
If file exist twice delete one. If not delete file in the bottom which is the latest one.
Build again.
Original source of answer

Just follow below steps and your issue is solved.
1. Go to Build Setting
2. Search for No Common Blocks and
3. Set it NO
4. Build again
5. You will not get this error again.

Related

I have opened .xcworkspace and when run application am getting clang: error: linker command failed with exit code 1 (use -v to see invocation)

duplicate symbol _GTMNSDictionaryURLArgumentsExportToSuppressLibToolWarning in:
/Users/Varshana/Library/Developer/Xcode/DerivedData/Lodore-axtsfmjdyxbqyccujoquacrynsxv/Build/Products/Debug-iphonesimulator/GoogleToolboxForMac/libGoogleToolboxForMac.a(GTMNSDictionary+URLArguments.o)
/Users/Varshana/Documents/Lodore final stage/GoogleSignInDependencies.framework/GoogleSignInDependencies(GTMNSDictionary+URLArguments_aec9c2446af4c2ac5a7380b418b337ea.o)
duplicate symbol _kGTMOAuth2WebViewKey in:
/Users/Varshana/Library/Developer/Xcode/DerivedData/Lodore-axtsfmjdyxbqyccujoquacrynsxv/Build/Products/Debug-iphonesimulator/GTMOAuth2/libGTMOAuth2.a(GTMOAuth2Authentication.o)
/Users/Varshana/Documents/Lodore final stage/GoogleSignInDependencies.framework/GoogleSignInDependencies(GTMOAuth2Authentication_ad53759ab562393658e6c193e56628dd.o)
duplicate symbol _kGTMOAuth2ErrorRequestKey in:
/Users/Varshana/Library/Developer/Xcode/DerivedData/Lodore-axtsfmjdyxbqyccujoquacrynsxv/Build/Products/Debug-iphonesimulator/GTMOAuth2/libGTMOAuth2.a(GTMOAuth2Authentication.o)
/Users/Varshana/Documents/Lodore final stage/GoogleSignInDependencies.framework/GoogleSignInDependencies(GTMOAuth2Authentication_ad53759ab562393658e6c193e56628dd.o)
don't worry, just xcode bug. try clean and build and it will work, or better, go to xcode->preferences->location->Derived Data. delete all files inside derived data and then restart xcode. clean and build the project and then it will work perfectly
ps: updated for cleaning
Cmd + Shift + Alt + K
To check the exact error for this issue check following:
Select issue navigator > Click on error will show logs for error > In that select All Messages tab.
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

duplicate symbol _OBJC_CLASS_$_Reachability in:

duplicate symbol _OBJC_CLASS_$_Reachability in:
XYZMobileApp/Build/Intermediates/XYZMobileApp.build/Debug-iphonesimulator/XYZMobileApp.build/Objects-normal/x86_64/Reachability.o
XYZMobileApp/BusinessLogic/Library/XtifyLib/XtifyPush.embeddedframework/XtifyPush.framework/XtifyPush(Reachability.o)
I am getting this error:
duplicate symbol _OBJC_CLASS_$_Reachability in:
and
clang: error: linker command failed with exit code 1 (use -v to see invocation)
you have used Reachablity class two times in your code.
One is included in the framework XtifyPush.framework and other you have included in the bundle.
Remove the one you are adding to remove the duplicacy.
Make sure that you did not include the Reachability.m -> implementation file instead of Reachability.h-> header file.
And also make sure you didn't include Reachability in you your unit test target this can also cause issues.
I renamed Reachability class as well as filename in library to "MyReachability". Xcode asked me to unlock the file as it was under pod. I unlocked it and after building i got few errors in my framework that Reachability class not found. I renamed the class references there as well to MyReachability and it worked fine. Hope this helps.

Apple Mach-O Linker Error: Duplicate Symbols. I renamed my project and this happened

I've been reading up on various linker errors on Stack Overflow for awhile now, and each seem to be a bit different. I'm hoping you might have insight into the one I'm getting.
I've got the following... (issue only exists in simulator. It's fine on device.)
Apple Mach-O Linker Error
ld: 192 duplicate symbols for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
There are 2 errors for every file...
duplicate symbol _CATEGORIES in:
/Users/me/Library/Developer/Xcode/DerivedData/Roto_Forum-ahulcvyneocizdcbjsdtiqgknlhk/Build/Intermediates/Roto Forum.build/Debug-iphonesimulator/Roto Forum.build/Objects-normal/x86_64/FFFMainBodyViewController.o
/Users/me/Library/Developer/Xcode/DerivedData/Roto_Forum-ahulcvyneocizdcbjsdtiqgknlhk/Build/Intermediates/Roto Forum.build/Debug-iphonesimulator/Roto Forum.build/Objects-normal/x86_64/Item.o
duplicate symbol _POINTS in:
/Users/me/Library/Developer/Xcode/DerivedData/Roto_Forum-ahulcvyneocizdcbjsdtiqgknlhk/Build/Intermediates/Roto Forum.build/Debug-iphonesimulator/Roto Forum.build/Objects-normal/x86_64/FFFMainBodyViewController.o
/Users/me/Library/Developer/Xcode/DerivedData/Roto_Forum-ahulcvyneocizdcbjsdtiqgknlhk/Build/Intermediates/Roto Forum.build/Debug-iphonesimulator/Roto Forum.build/Objects-normal/x86_64/Item.o
That's 2 of the 192 errors. If I look at my Compile Sources under the Build Phases of my Target, FFFMainBodyViewController.m is the first file. Item.m is the second. And for each and every file down the list, in order, I get a 2 duplicate errors like the ones seen above.
This all started I believe when I renamed my project, and therefore the target name in my Podfile also changed.
I've tried various things. Deleting Derived Data, Cleans, deleting the red libPods.a file from my framework, etc.
How might I solve this issue?

Error when compiling nettle-2.7.1

When I try to compile nettle-2.7.1, I get the following:
root#tcx2270-19:~/nettle-2.7.1# make
make: Warning: Can't find aes-decrypt-internal.o.d': No such file or directory
make: Fatal error in reader: Makefile, line 594: Read of include fileaes-decrypt-internal.o.d' failed
Has anyone seen this issue? Thanks.
I also had the exact same problem. It has nothing to do with gmp. The ./configure script generates a broken Makefile. After doing some analyzation of the generated Makefile I figured out a solution.
On the very bottom of the generated Makefile search for the line that looks like the following:
DEP_FILES = $(SOURCES:.c=.$(OBJEXT).d) $(SOURCES:.c=.p$(OBJEXT).d) asm.d
You can fix the build by changing it to the following line:
DEP_FILES = $(SOURCES:.c=.c.$(OBJEXT).d) $(SOURCES:.c=.c.p$(OBJEXT).d) asm.d
Additionally, we have to fix the Makefiles in all sub-directories.
For ./tools/Makefile, on the very bottom, find the line that looks like:
include $(SOURCES:.c=.$(OBJEXT).d)
and change it to
include $(SOURCES:.c=.c.$(OBJEXT).d)
Furthermore, you need to add the following two build-targets:
../libnettle.a:
$(MAKE) -C .. libnettle.a
../libhogweed.a:
$(MAKE) -C .. libhogweed.a
For ./testsuite/Makefile, on the very bottom, find the line that looks like this:
DEP_FILES = $(SOURCES:.c=.$(OBJEXT).d) $(CXX_SOURCES:.cxx=.$(OBJEXT).d)
and change it to:
DEP_FILES = $(SOURCES:.c=.c.$(OBJEXT).d) $(CXX_SOURCES:.cxx=.cxx.$(OBJEXT).d)
Finally, in ./examples/Makefile, again on the very bottom, search for the line that looks like:
include $(SOURCES:.c=.$(OBJEXT).d)
and change it to
include $(SOURCES:.c=.c.$(OBJEXT).d)
Phew, at least for me, that makes the build work. Of course, this is an ugly solution but it gets the job done. A better solution would be to fix the configure-script but I did not have the time to do it yet. It is also worth noting that nettle 3.0 does not have this issue. Too bad gnutls does not work with that newer version.
UPDATE: I created a patch which does all the above fixes in the Makefile.in files. As a result, you don't have to fix them yourselfs. Optimally, just unpack the source, apply the patch and proceed the way you normally would by continuing with the ./configure.
Get it from here: http://pastebin.com/36M5LHK3

Code does not compile for extra large implementation file

The compiler exits by throwing following error.
/var/folders/2t/jkh9ngsn6f9bnmz8l0mz0zm80000gs/T/xsdLocal20-ZhAiH9.s:1895977:branch out of range
clang: error: assembler command failed with exit code 1 (use -v to see invocation)
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang failed with exit code 1
The file has 98341 number of lines.
using compiler Apple LLVM 3.1
The code builds for simulator but not for iOS device
Save the original file.
Comment out out #implementation after another, til the file compiles properly. Npw you know the class that is giving you the problem.
Then take the very biggest method, adding '#if 0' around the code, and at the top before the '#if 0', return a proper value - YES, NO, nil, whatever so the file will compile.
Compile. Do you still get the problem? Then comment out the next largest method, or just do the methods sequentially, or use a binary search technique (ie comment out one half of the methods, then the other half, to drill down on the culprit.
Once you find the problem method, you will need to refactor it into two or more methods, which probably can be private to the class, so your public interface does not change.