I'm looking for some advice on calling C# methods from Objective-C on the iPhone. I've read the instructions at http://www.mono-project.com/Embedding_Mono along with numerous stackoverflow threads, but I'm still having problems. I can get everything to work on the simulator, but not on a device. At first, the call to mono_jit_init() failed with an assertion in one of the trampoline functions. Eventually I discovered that I had to do the following before calling mono_jit_init():
const char *path = [[[NSBundle mainBundle] bundlePath] UTF8String];
setenv("MONO_PATH", path, 1);
mono_jit_set_aot_only(YES);
Unfortunately, now I get the following error:
Failed to load AOT module '/private/var/mobile/Applications/DD55C2F7-A692-4E68-B4DB-927690F9F3F2/DummyTest.app/mscorlib.dll.dylib' in aot-only mode.
Here's what I've done so far:
Run mtouch as follows:
/Developer/MonoTouch/usr/bin/mtouch --xcode=dummy --fat DummyLib.dll
Note: This did not generate a main.m files as described in the documentation.
Copied the resulting DummyLib.dll, mscorlib.dll and DummyLib.dll.7.s files into my xcode project.
Added the following line to the "Header Search Paths" line in my xcode project configuration
/Developer/MonoTouch/SDKs/MonoTouch.iphoneos.sdk/usr/include
Added the following lines to the "Other C Flags" line in my xcode project configuration
-D_THREAD_SAFE
-DNS_BLOCK_ASSERTIONS=1 -D_THREAD_SAFE
Added the following line to the "Other Linker Flags" line in my xcode project configuration
-L/Developer/MonoTouch/SDKs/MonoTouch.iphoneos.sdk/usr/lib -lmono-2.0 -lpthread -liconv
Compiled and run my xcode project.
I'm sure I must be doing something wrong or I've missed a step somewhere, because other people claim to have this working. Does anybody have any idea what I've done wrong?
Related
I have a framework written in obj-c and swift.
Now i try to run a related unit test target, but I get this error:
2014-07-10 07:45:54.064 xctest[4908:303] The test bundle at /Users/steve/Temporary/Build/Products/Debug/SOGraphDB-Mac Tests.xctest could not be loaded because an unanticipated error occurred: Error Domain=NSCocoaErrorDomain Code=3587 "The bundle “SOGraphDB-Mac Tests” couldn’t be loaded because it is damaged or missing necessary resources." (dlopen_preflight(/Users/steve/Temporary/Build/Products/Debug/SOGraphDB-Mac Tests.xctest/Contents/MacOS/SOGraphDB-Mac Tests): Library not loaded: #rpath/libswiftAppKit.dylib
Referenced from: /Users/steve/Temporary/Build/Products/Debug/SOGraphDB.framework/Versions/A/SOGraphDB
Reason: image not found) UserInfo=0x10011c640 {NSLocalizedFailureReason=The bundle is damaged or missing necessary resources., NSLocalizedRecoverySuggestion=Try reinstalling the bundle., NSFilePath=/Users/steve/Temporary/Build/Products/Debug/SOGraphDB-Mac Tests.xctest/Contents/MacOS/SOGraphDB-Mac Tests, NSDebugDescription=dlopen_preflight(/Users/steve/Temporary/Build/Products/Debug/SOGraphDB-Mac Tests.xctest/Contents/MacOS/SOGraphDB-Mac Tests): Library not loaded: #rpath/libswiftAppKit.dylib
Referenced from: /Users/steve/Temporary/Build/Products/Debug/SOGraphDB.framework/Versions/A/SOGraphDB
Reason: image not found, NSBundlePath=/Users/steve/Temporary/Build/Products/Debug/SOGraphDB-Mac Tests.xctest, NSLocalizedDescription=The bundle “SOGraphDB-Mac Tests” couldn’t be loaded because it is damaged or missing necessary resources.}
Any idea what the root cause can be?
The error seems realated to "Library not loaded: #rpath/libswiftAppKit.dylib"
Both (framework and test bundle) compile without any error or warning (in Beta2)
I had a similar problem, though mine was an iOS test target, linking to a Swift framework, that failed to run on Xcode 6 GM. The test target had run successfully on an early beta of Xcode 6, but the final version reported the runtime error: Library not loaded: #rpath/libswiftCore.dylib
I noticed that a newer project did not have the failure, so I compared the build settings and test code. I was able to resolve the problem with three steps:
The test target needs the "Embedded Target Contains Swift Code" setting to be YES. This tells the linker to add the Swift runtime libraries to the executable.
The test target needs an explicit value for the "Runpath Search Paths" build setting. This tells the loader where to find the Swift runtime libaries. I copied the following setting from a fresh new test target:
LD_RUNPATH_SEARCH_PATHS = $(inherited) #executable_path/../Frameworks #loader_path/../Frameworks
The test cases need to explicitly import any modules that are used by the linked framework. In my project, the framework used UIKit but the test cases only used my framework. When I added an explicit import UIKit to the test cases, the link problem went away.
Since I keep running into this issue whenever I mess with build settings, here's the cleanest answer I can provide as of Xcode 8b5:
If unit tests don't run on iOS, make sure you have:
Runpath Search Paths: #loader_path/Frameworks
If unit tests don't run on macOS, make sure you have:
Runpath Search Paths: #loader_path/../Frameworks
This will show up as LD_RUNPATH_SEARCH_PATHS in your pbxproj file. You can also add $(inherited) to make sure project-wide paths are added as well, but those are probably empty.
Lastly, I didn't need the executable_path/... settings, doesn't make a difference for me whether they're there or not for unit tests.
I had the same problem.
Ended up copying libswiftAppKit.dylib out of the Xcode application directory (I am using beta 3), into a directory that I could reference (not part of an application bundle), then adding the library to the "Link binary with libraries" setting for the test bundle. My tests then started working.
FYI, the path for the dylib was at '/Applications/Xcode6-Beta3.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx/libswiftAppKit.dylib'
Probably not a good final solution, but it works for the interim.
My solution was to add a single file to my test target, AppKitTests.swift (or AppKitSpec.swift in my case), and all the file contains is:
// While I don't know why, The.framework is built linked to libswiftAppKit.
// Frameworks do not embed the Swift libraries themselves, it's up to the host
// app to include the necessary libraries. So here we are, including AppKit on
// behalf of The.framework so that the tests can run.
import AppKit
Oh, I also added AppKit to the test target's set of frameworks.
I had this occur to me in Beta 4 and it turned out that I had done it to myself without realizing it.
I had a Framework project called Fnord. My FnordTests target contained a couple of unit test classes that had import Fnord at the top of each file. For some reason Xcode was complaining about those imports and so I commented them out. This is when I started getting the same symptoms while trying to run my unit tests.
I noticed that the settings for my FnordTests target were such that the target would be linked with Fnord.framework, and I realized that it might not be able to do that with the aforementioned import Fnord statements diked-out.
So I put them back in, and everything went back to normal. Curiously, Xcode no longer showed those import statements as being problematic, but this is beta so I can forgive that.
I hope this helps someone.
I ran into the same issue, adding
import AppKit
in the Swift file fixed it
I added ShareKit framework to try and here is the error running it in Simulator:
duplicate symbol _LFHRReadStreamClientCallBack in
.../Xcode/DerivedData/....build/Objects-normal/i386/LFHTTPRequest-8C6F35228BA446B9.o
and
.../Xcode/DerivedData/....build/Objects-normal/i386/LFHTTPRequest-8ACF920D803FDCA6.o
for architecture i386
I looked at previous posts Build Error - missing required architecture i386 in file and tried to edit project.pbxproj commenting FRAMEWORK_SEARCH_PATHS lines out as well as looking for .framework files accidently added to my project but with no luck.
What else can I try?
You've included LFHTTPRequest in your project twice. It's possible that another library (such as sharekit) included it for you, doublecheck the files sharekit includes and remove one copy of LFHTTPRequest and things should compile.
This can also happen if you move coredata-generated classes into a group, like "Models" and then regenerate the NSManagedObjectModel subclasses. The generated files will be placed in the project root and added into the build twice.
I got the same error when working with TessBaseAPI. I had two c++ files and both had the following declaration:
namespace tesseract {
class TessBaseAPI;
};
tesseract::TessBaseAPI *tesseract1;
uint32_t *pixels;
The I read the full error message. I got a line there:
duplicate symbol _tesseract1 in
And later, which files contains the duplicate also included (the file name).
So, I changed the instance name as follows:
namespace tesseract {
class TessBaseAPI;
};
tesseract::TessBaseAPI *tesseractNew;
uint32_t *pixelsNew;
That solved my problem.
I've recently downloaded Xcode 4 and now two of my projects that were working perfectly fine before have started giving me errors. Both errors are effectively to do with linking options, but I can't figure out how to change these options and get rid of the errors.
The first problem is with a project written in C++ using the SDL_ttf and SDL_image frameworks. The project builds correctly, but when I try to run, it gives me the following warnings on the console:
warning: Unable to read symbols for #executable_path/../Frameworks/SDL_ttf.framework/Versions/A/SDL_ttf (file not found).
warning: Unable to read symbols from "SDL_ttf" (not yet mapped into memory).
warning: Unable to read symbols for #executable_path/../Frameworks/SDL_image.framework/Versions/A/SDL_image (file not found).
warning: Unable to read symbols from "SDL_image" (not yet mapped into memory).
Since the files are not being found, the executable cannot load any images making it exit straight away when I try to load images. I think the issue here is that the frameworks are not in the directory above the executable, they are in /Library/Framework/ which worked fine before in Xcode 3.2. How do I resolve this?
The second problem comes when compiling an application I wrote for iOS. Along with giving me a bunch of warnings about depracated code on iOS 5, which I will deal with later, it fails to build due to a linker error which I have no clue how to resolve, it says:
ld: library not found for -lz.1.2.3
Command /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/clang failed with exit code 1
I can answer the second question.
-lz.1.2.3
should be
-lz
You might have accidentally added the zlib.1.2.3.dylib to the project's "link binary with libraries" build phase. You should use the standard zlib without any version in its filename, or simply add -lz to the Other Linker Flags under Build Settings and not add zlib in the "link binary with libraries" build phase.
As for the missing frameworks my best guess is that it has to do with the relative path, ie if you can get rid of the /../ part and instead provide an absolute path that might resolve the issue.
I downloaded OpenFeint version 2.3.1, unzipped and placed the OpenFeint folder inside right underneath my project in Xcode, and checked "recursively create groups if needed" (the instructions said to use groups and not a folder reference).
I renamed my AppViewController and AppDelegate .m files to .mm. I followed the rest of the instructions and compiled and ran, the app works fine.
Inside AppViewController.mm I do:
#import "OpeinFeint.h"
and compile, which gives me the errors:
#error: "OpenFeint requires Objective-C++. In Xcode, you can enable this by changing your file's extension to .mm".
#error: syntax error before 'OfNotificationCategory'
#error: syntax error before 'OfNotificationCategory'
and the location of the errors takes me to the OpenFeint files.
I did add -ObjC to Other Linker Flags and check Call C++ Default Ctors/Dtors in Objective-C.
Any advice? Thanks!
The linker flag should be -lobjc, not -ObjC.
I ran into this error when building my code with CLANG:
In file included from /Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.0.sdk/System/Library/Frameworks/UIKit.framework/Headers/UIKit.h:31,
from /Users/waspfish/Documents/NanaimoStudio/Projects/iPhoneMonk/Projects/IdeaOrganizer/IdeaOrganizer_Prefix.pch:13,
from :1:
/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.0.sdk/System/Library/Frameworks/UIKit.framework/Headers/UILocalizedIndexedCollation.h:13: error: syntax error before ‘AT_NAME’ token
/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.0.sdk/System/Library/Frameworks/UIKit.framework/Headers/UILocalizedIndexedCollation.h:21: error: syntax error before ‘}’ token
/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator3.0.sdk/System/Library/Frameworks/UIKit.framework/Headers/UILocalizedIndexedCollation.h:23: fatal error: method definition not in #implementation context
compilation terminated.
{standard input}:32:FATAL:.abort detected. Assembly stopping.
I ended up having to exclude the UILocalizedIndexedCollation.h from UIKit.h and everything built fine. Any idea what could have caused the problem? I can't imagine Apple is shipping a defective header file.
The problem comes from SDK 3.0 which now use gcc 4.2 but scan-build still use /usr/bin/gcc. So you need to tell scan-build to use /usr/bin/gcc-4.2 instead.
scan-build --use-cc=/usr/bin/gcc-4.2 xcodebuild -configuration Debug
Et voila!
Apple’s engineer had confirmed that they had a bug in UIKit framework:
We do have a simple workaround for this UIKit bug. In UILocalizedIndexedCollation.h change this:
UIKIT_EXTERN #interface UILocalizedIndexedCollation : NSObject
to
UIKIT_EXTERN_CLASS #interface UILocalizedIndexedCollation : NSObject
Denis2342
Usually when I see something like this I clean the build and restart Xcode, then things were fine. With GCC 4.2 sometimes a bad pch could cuase hiccups like this, but clang uses a totoally different pch implementation. You may want t completely delete the build dir while Xcode is not running.
Technically clang is not supported for iPhone development, but I use it for simulator compiles , and I do not see the compile errors you are seeing, so (at least for me) it works. One thing sticks out in my head, you refer to editing your UIKit.h. I understand what you did that, but tweaking system headers is big no-no. Is there a chance you have done that for other reasons, because if you are not running stock headers there any number of reasons this could be happening.