I have a code base which compiles fine in all other NEON compilers, ndk-build, RVDS, etc, but under Xcode I get the error "bad instruction" for every NEON instruction I call. It basically seems like NEON is not detected.
I am attempting to build a static library, I went to New Project, selected Cocoa Touch Static Library, then added my existing files.
Everything I'm reading indicates that NEON should be already enabled. I removed all references to armv6, and am targeting iOS 5.1
Also the code in question is all contained as routines defined in ".s" files -- pure assembly. I am not using the intrinsics method calls.
It seems like the compiler is barfing on the whole file...
Unknown pseudo-op: .cpu
It lists all of the other settings, like .fpu, etc
Here are my current settings:
(source: wasteonline.net)
(source: wasteonline.net)
(source: wasteonline.net)
After the as tool I mentioned in my last answer turned out to be choking on my syntax as well, I realized there must be something else going on.
I followed the guidelines on the bottom of this post http://www.shervinemami.info/armAssembly.html#template
The changes I needed to make were:
converted my instructions to all lower case
use the naming directives to be compatible with mach-o (solved linker problems)
Try to use GCC4.2. I solved a very similar problem switching to the old, good GCC.
In Build Settings -> Compiler for C/C++/Objective-C, select GCC
Actually, if you check the LLVM ARM status page, you'll see that it cannot yet parse .S files.
Related
I have a "fat" framework built for iOS, which is being used in a debugging tool built for macOS. Previously I was linking this framework statically, which worked, even though XCode complains about it being built for the simulator (since the architecture is the same). But now, newer versions of the library are dynamic, so that route doesn't work, as the tool is a command line application, which doesn't support embedding frameworks.
I could turn it into an application bundle, it seems, in order to solve that, but I'm not sure what this entails (creating a new project?). I can certainly figure it out but ..
In the meantime, I thought I'd load the library dynamically using dlopen() etc and retrieve the classes/methods I need (I already have some code for this which at least compiles). However, that call fails with the following message:
no suitable image found. Did find:
/<path to library file>: mach-o, but built for simulator (not macOS)
Since linking statically is only a warning and actually works, is there a way to make dlopen work as well?
Recompiling the framework itself is not an option for me in this situation.
Are you considering editing the binary of the dylib framework? If so in the Macho-O header you could try changing LC_VERSION_MIN_IPHONEOS to LC_VERSION_MIN_MACOSX.Probably it won't be enough,but it's a simple change for a quick test. Here's a screenshot comparison of those load commands in MachOView
Also covered the other way round here
I'm trying to compile a dependent libraries from the source code and I've got this error:
/Applications/Xcode.app/Contents/Developer/Platforms/AppleTVOS.platform/Developer/SDKs/AppleTVOS9.0.sdk/usr/include/unistd.h:446:8:
note: 'fork' has been explicitly marked unavailable here pid_t
fork(void) __WATCHOS_PROHIBITED __TVOS_PROHIBITED;
Is there any way to resolve this issue?
The thing is that I don't actually even need this functionality. When I compile this code for iOS and run it under tvOS then it works.
But I can not submit the application because it contains code compiled for iOS.
What would be the good trick to substitute there a dummy fork() function so it compiles OK (believing that it is not actually used by my specific use-cases).
I don't believe there is a way round this. You cannot create processes under iOS and tvOS is 90% iOS, so the same restriction applies.
You'll have to conditionally compile-out that section of code for iOS/tvOS.
I am trying to get some a medium-to-large sized code base that is, frankly, well written with a high degree of portability.
I decided to package it as a loadable bundle (plugin) and piggy-backed off of one of the template app projects and followed some tutorials about adding a target for loadable bundles within an app.
Also, this loadable bundle depends on a custom framework which I built for iOS and added it as a dependent for the loadable bundle. ie. The plugin links to a framework wrapper for a static lib.
The custom framework built successfully. Granted I have not yet verified that it works. The idea is to test the integrated functionality.
My build settings are largely defaults with the exception of some preprocessor defines.
Because I don't really understand the code base yet, I am literally adding one file-at-a-time to the plugin target and building cleanly every 3-4 files added.
The build completes successfully but with many, many warnings as follows, with paths to intermediate build results...etc.:
"file was built for unsupported file format with a series of hex characters () which is not the architecture being linked (armv7s)". When I converted the hex chars to ascii it just showed "#1 /Users/my-username/? ".
When I do a 'file' on any .o in the intermediate build results, I get "ASCII c program text, with very long lines"
What am I doing wrong? What does that mean?
Thank you so much for your time.
The short answer is this:
If you get this message, then your project settings are messed up.
If you are linking your app against custom frameworks, make sure they are built as fat binaries
You will need to know very clearly the meanings of active architecture and how it is used and whether or not you want to only build the active architecture for your app, or all of the possible architectures.
If you are, like me, inheriting a slew of portable code that depended heavily on gcc and its extensions, expect to make changes around builtin* attributes and to make heavy use of __clang to make available macros that used to be defined through the GNUC et al.
Also, you will need to use the -E for clang to debug/understand the preprocessing and the file inclusion. That said, don't forget to take it out because effectively what will happen is that your .o will just contain text and the build may succeed, but the linker will give you the odd message subject of this question.
Finally, do understand that Xcode, like any piece of complex software, is buggy. Sometimes, it will keep settings that you get rid off. In my case, I included custom frameworks which I built after placing them in a local dir. Then I deleted them from the project and opted to trash when prompted. The build kept failing because the linker for some reason was looking for the local directory. You would have to edit the *.pbxproj and manually remove them.
I'm trying to work with ZXing and OpenCV in the same project. You wouldn't think this would be this rare of thing to do, but I guess it is. I am having some serious compatibility issues between the two. I can only get one imported without the other.
I start with OpenCV and everything works fine. Program runs as expected. Then I add ZXing, and I get about 27 compiler errors. There is a stackoverflow question that address this here. So I change my C++ compiler settings to match what this question suggests, and it fixes the ZXing problems, but then opens up a whole new set of errors. These errors are related to OpenCV now(see below).
EDIT:
It seems that depending on the C++ compiler, its a one-or-the-other type deal. In fact, if you change the c++ standard library from libc++ to libstdc++ you will get one to work and not the other. No way I can see to get both at the same time
I have found a solution to my question. This applies best to anyone using zxing and opencv in the same project.
Go to the project settings -> Target -> search for c++
a. Switch c++ Language Dialect to Compiler Default
b. Switch C++ Standard Library to libc++
Go to the ZXingWidget.xcodeproj -> ZXingWidget -> search for C++
a. Switch c++ Language Dialect to Compiler Default
b. Switch C++ Standard Library to libc++
There will be a compiler error saying that ZXing can't compile to libc++ because it's currently set to support iOS 4.3. Go into ZXing widget again, and change the deployment target to be 5.0 (sorry all of you trying to still support < 5)
This fixed my problem. Basically what was happening is that zxing and open cv were compiling on different versions of c++, which was causing some strange issues
Edit: For reference, I was using ZXing 2.1 and OpenCV 2.4.3 (Newest versions at the time of the question)
Actually, I use your solution but a little different. At step2,I change both to Complier Default, because if I use your suggestion,the error still there.So I checked the setting in ZXingWidget.xcodeproj and found that it set both Complier Default, so I changed my project setting the same as ZXingWidget.xcodeproj.
But thanks to your hint and helped me a lot!
I have a code base which under Xcode get the error "bad instruction" for every NEON instruction I call. It basically seems like NEON is not detected.
I am attempting to build a static library, I went to New Project, selected Cocoa Touch Static Library, then added my existing files.
Everything I'm reading indicates that NEON should be already enabled. I removed all references to armv6, and am targeting iOS 5.1
Also the code in question is all contained as routines defined in ".s" files -- pure assembly. I am not using the intrinsic method calls.
this is the error which I get whenever I try to run the code:
unknown directive .fpu neon
Command /Applications/Xcode.app/Contents/Developer/Toolchains/
XcodeDefault.xctoolchain /usr/bin/clang failed with exit code 1
also when I delete .fpu neon command from my code, it compiles and I get the .o file but then it fails to link as I still am not able to use the programs defined in the code file.
Try the answer on my similar question https://stackoverflow.com/a/10507325/571778
Sort answer, in my case, was I was porting assembly from another compiler. A few points:
Xcode requires all lower case instructions
The pseudo-ops are different (try http://www.shervinemami.info/armAssembly.html#template)
you must start your assembly function names with "_", because that's how the linker finds them (in C, call "foo()", but in ASM name your function "_foo")