In adding 64 bits support to some iOS code I maintain, I found that the nlist function is not available for the x86_64 architecture (64 bits iOS simulator). Code invoking nlist() works fine for all other archs (armv7, armv7s, arm64 and i386) but will not build successfully for x86_64, where the linker fails to find the symbol in the linked libraries.
It can be reproduced on a template project created with Xcode, by simply adding:
#import <mach-o/nlist.h>
int testnlist()
{
struct nlist nl[2];
bzero(&nl, sizeof(struct nlist) * 2);
return nlist("test", nl);
}
Results in:
Undefined symbols for architecture x86_64:
"_nlist", referenced from:
_testnlist in ViewController.o
ld: symbol(s) not found for architecture x86_64
Tested on Xcode 6.1.1 with iOS SDK: 8.1, building for iPhone 6 simulator.
Looks to me like Apple might have forgotten to include some of the simulator's shared libraries built for x86_64, but I might also be overlooking something stupidly obvious...
you might want to try:
#ifndef N_NLIST_DECLARED
struct nlist
{
union
{
char *n_name;
struct nlist *n_next;
long n_strx;
} n_un;
unsigned char n_type;
char n_other;
short n_desc;
unsigned long n_value;
};
#endif
which I extracted from:
<https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.7-4.6/+/android-4.1.2_r2/lib/gcc/x86_64-linux/4.6.x-google/include-fixed/linux/a.out.h>
in that same header file, you will find lots of other things that
will be 'gotcha's when moving to 64bit code
Related
Define a method in the .mm file
#if defined(__cplusplus)
extern "C"{
#endif
extern void UnitySendMessage(const char* obj, const char* method, const char* msg) __attribute__ ((weak));;
extern NSString* _CreateNSString (const char* string);
#if defined(__cplusplus)
}
#endif
#interface UnityAdapter ()
...
Called in #implementation UnityAdapter()
UnitySendMessage("PottingMobile", "bannerDidLoadAd", "");
I need help solving the following error:
ld: warning: Could not find auto-linked framework 'FBSDKCoreKit'
Undefined symbols for architecture armv7:
"_UnitySendMessage", referenced from:
-[UnityAdapter bannerDidLoadAd] in UnityAdapter.o
ld: symbol(s) not found for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)
when i don't use UnitySendMessage method， everthing is ok.
I want to write a framework for bridging unit and iOS projects. When I use it in a unit packaged project, no problem. When I put the bridging file into my own framework, I will report an error. There is nothing in the framework project. Do I need to integrate unit's lib? If so, how to integrate? Can you give me a website? Thank you.
Unity is currently doing this with their library feature.
You can look at their solution.
If you need a solution now: Have a look at https://github.com/jiulongw/swift-unity. It's all automated and a good starting point, but missing the library feature.
This project shows how to make an actual library: https://github.com/forestlin1212/unity-ios-framework (But for an older Unity version and not automated)
I converted my project from swift 3 to swift 4 and am using the latest version of xcode 9. On building, I get the following error :
Undefined symbols for architecture arm64:
"__T0So22AVCapturePhotoSettingsC12AVFoundation01_abC16SwiftNativeTypesACWP", referenced from:
__T06SpotMi8CameraVCC12capturePhotoyypF in CameraVC.o
"__T012AVFoundation39_AVCapturePhotoSettingsSwiftNativeTypesPAAE016availablePreviewc11PixelFormatG0SaySo8NSNumberCGfg", referenced from:
__T06SpotMi8CameraVCC12capturePhotoyypF in CameraVC.o
ld: symbol(s) not found for architecture arm64
I am out of clues. Any help will be much appreciated.
Cheers!
There is a bug in XCode9. Apple inadvertendly made some functions in AVFoundation private.
Workaround:
Change availablePreviewPhotoPixelFormatTypes to __availablePreviewPhotoPixelFormatTypes in your source.
Same goes for the following:
supportedColorSpaces -> __supportedColorSpaces
supportedFlashModes -> __supportedFlashModes
availableRawPhotoPixelFormatTypes -> __availableRawPhotoPixelFormatTypes
availablePhotoPixelFormatTypes -> __availablePhotoPixelFormatTypes
Then it might compile!
Good Luck!
The app I've been working on uses an external library, pdlib, which has it's own externals (.c files) which I've been importing via the bridging header #import "Uzi.c" and calling in my main Swift file via Uzi.c's setup function Uzi_setup() in my ViewController class. I've had no problem with this until after updating to new public Xcode 8 a few days ago (I had no problem with Xcode 8 Beta 1 over the Summer).
Here are the 7 errors I get, listed under a single "Mach-O Linker Error" umbrella:
Undefined symbols for architecture x86_64:
"_Uzi_bang", referenced from:
_Uzi_setup in ViewController.o
"_Uzi_class", referenced from:
_Uzi_setup in ViewController.o
"_Uzi_float", referenced from:
_Uzi_setup in ViewController.o
"_Uzi_new", referenced from:
_Uzi_setup in ViewController.o
"_Uzi_pause", referenced from:
_Uzi_setup in ViewController.o
"_Uzi_resume", referenced from:
_Uzi_setup in ViewController.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Those undefined symbols are 6 functions and a class declare from Uzi.c. Here's a link to the whole c file: https://github.com/electrickery/pd-miXedSon/blob/master/hammer/Uzi.c
I've tried every solution I've found online for dealing with similar problems, with no solution yet... I tried changing the "Architecture" and "Valid Architecture" settings to only armv7 and armv7s (no arm64) and changed "Build Active Architecture Only" to "No". These step seem to help others in similar situations, but they didn't work for me (and taking away arm64 causes additional errors to appear).
XCode 8 is pretty recent (the public version was released Sept. 13), so there are virtually no other questions about this upgrade causing a similar problem.
Any help would be greatly appreciated!
Solved by #danomatika on GitHub: https://github.com/libpd/libpd/issues/149
"You generally shouldn't include/import an implementation file aka .c, .cpp, .m, etc. This is what is causing the duplicate symbol issue.
This is what the "forward function declaration" in the header file is for: to tell the compiler that a function exists and what data it takes/returns. The compiler then assumes the actual implementation of the function exists in an implementation file. If it can't be found, then you get an "undefined symbol error." If you somehow end up declaring the function twice, aka include both a header with the forward declaration and the implemetaton of the function itself in the .c file, then you get a "duplicate symbol error."
This is all lower-level stuff that is only really an issue since Pd externals are designed around being dynamic libraries, so are not built or provided with headers which include the function declarations. This is why you have to do a little extra work and do it yourself.
Their are two easy fixes for this, both of which involve declaring the required function you want to call from the .c file in a header file.
Simply declare the function in the bridging header:
void uzi_setup();
Create a header, say Externals.h, and declare all of the externals stuff there:
// forward declare setup functions only found in .c implementations
void uzi_setup();
// convenience wrapper function
void externals_setup() {
uzi_setup();
}
Then import the file in your bridging header:
#import "Externals.h"
And in swift, you can now do:
externals_setup()
I'm including the Layar SDK framework into my app (version 8.0) and everything works fine on a device.
However, I can't run the app on a simulator anymore - I don't mind Layar not working (there's no camera after all!) but I do need it to compile for continual integration, automated tests etc (not to mention developing on the train top/from work!)
The linker gives me these errors :
ld: warning: ignoring file /Users/username/Documents/appname/libs/MPOAuth/libMPOAuthMobile.a, missing required architecture i386 in file /Users/username/Documents/appname/libs/MPOAuth/libMPOAuthMobile.a (2 slices)
ld: warning: ignoring file local/LayarSDK/LayarSDK.framework/LayarSDK, missing required architecture i386 in file local/LayarSDK/LayarSDK.framework/LayarSDK (2 slices)
Undefined symbols for architecture i386:
"_OBJC_CLASS_$_LayarSDK", referenced from:
objc-class-ref in MYAppDelegate.o
ld: symbol(s) not found for architecture i386
Checking, the LayarSDK doesn't contain i386, it only contains armv7 and armv7s.
My solution is pretty clumsy - if anyone has a better idea, please let me know!
I compile this file (LayarSimulatorStub.m) into my app :
#if TARGET_IPHONE_SIMULATOR
#import <Foundation/Foundation.h>
#interface LayarSDK : NSObject
#end
#implementation LayarSDK
+ (id)layarSDKWithConsumerKey:(id)a andConsumerSecret:(id)b andDelegate:(id)c { return nil; }
- (id)init { return nil; }
- (id)initWithConsumerKey:(id)a andConsumerSecret:(id)b andDelegate:(id)c { return nil; }
#end
#endif
Now, there is an i386 symbol LayarSDK. It just returns nil from all it's constructors. The app now compiles with Layar disabled.
The conditional compilation means that it's not present for the device architectures so there are no linker errors.
I'm getting the following error when trying to use C's math.h library:
#import <Foundation/Foundation.h>
#import <math.h>
#interface Filter : NSObject {
float cutoff;
float resonance;
float sampleRate;
float *f;
float freq;
float damp;
}
- (float)filter:(float)input;
#end
Can you tell me how I can solve this error? It seems that the min() function cannot be compiled to armv7 architectures.
Undefined symbols for architecture armv7:
"_min", referenced from:
-[Filter init] in Filter.o
ld: symbol(s) not found for architecture armv7
clang: error: linker command failed with exit code 1 (use -v to see invocation)
You are linking against a static library that is compiled for i386 or x86-64, in your specific case I think that you have referenced a library that contains min function but is not compiled for armv7 architecture, take a look at your referenced static library .
On iOS I had to use fmin() instead of min() as alex purposed. Further, i didn't even need to import math.h as Anoop said.