I have 3rd party static library compiled for i386 and armv7 architectures (without armv6). Is there a way to link Monotouch project with armv7 library? Monotouch adds '-arch armv6' parameter to gcc and I don't know how to change it.
The current release of monotouch supports all existing iPhones and thus compiles for armv6 since it runs everywhere.
The next major release will support targeting armv7 specific binaries.
Related
What's different between the "GNU MCU Eclipse ARM
Embedded GCC " and "GNU ARM Embedded toolchain"? I'm new in Linux world and I need to programming STM32F4DISCOVERY board. And I can't understand what toolchain need is .
I would take a look at this article if you're curious about getting started with toolchains. It's from Nordic, not ST Micro, but it's very helpful to understand how the toolchain, makefile, and IDE all work together.
https://devzone.nordicsemi.com/tutorials/b/getting-started/posts/development-with-gcc-and-eclipse
I believe the brief answer to your question is that:
GNU MCU Eclipse ARM Embedded GCC is a family of extensions to the Eclipse IDE to develop code for ARM devices
GNU ARM Embedded toolchain is from ARM, and it's purely the compiler, linker, etc. needed to make a command line call to compile a C file and generate a binary for an ARM processor
If you're just looking to crank something out on your STM32, I would look to see if they have an IDE for your board/ application, as they're usually pre-bundled with the toolchain and an SDK.
GNU MCU Eclipse ARM Embedded GCC is based on the GNU ARM Embedded toolchain. From the README:
Compared to the ARM distribution, the build procedure is more or less the same and there should be no functional differences.
The only addition affects newlib, which was extended with printf()/scanf() support for long long and C99 formats (--enable-newlib-io-long-long and --enable-newlib-io-c99-formats).
The Docker images used to create the GNU MCU Eclipse ARM Embedded GCC release are also available on the project page, should you ever need it (probably not).
You should be fine with either of them installed along with the rest of the GNU MCU Eclipse suite.
At the moment, we are trying to integrate the latest libspotify release 12.1.51 eabi-armv7.
This library has been developed for a soft-float kernel running on ARM7.
We are using a more recent hard-float kernel on our platform, requiring a hard-float version of the libspotify for ARMv7.
The hard-float release offered by spotify is for ARM6, so we can’t use it.
Any idea on how to get this?
ARMv6HF libraries should work just out of the box on ARMv7HF systems.
It will not take use of some instructions that's available on the v7 CPU but apart from that it should work just fine.
I created a new project and set the compiler to LLVM GCC 4.2, iOS deployment target to 4.2 but I still can't launch it on an iPhone 3G with 4.2.1 on it. It works fine in the simulator and on an iPhone 4, but when I run it on an iPhone 3G with 4.2.1 it simple "finishes" right after I start it, without any console output.
Does anyone have a clue what's wrong?
These are the valid architectures:
You need to add armv6 architecture to the Valid Architectures.
See this answer:
Can't run app on iPhone 4.2.1 with Xcode 4.3.1 and IOS
Valid Architectures is of no use. You need to change Architectures to armv6 armv7, and Build Active Architectures to NO.
In your project settings,
click on TARGET,
There should be a item called Required device capabilities. set that to armv6
it worked on me
finds the item require the plist and removes the restriction to only ARMv7
Changing the Architectures to armv6 armv7 worked for me, I didn't need the Required Device Capabilities at all.
Here is the situation: I've built a native library for re-distribution in other apps. Because we're using ARMv7 NEON, we ship two versions of the library: One for most devices and a "fallback" limited capability version for ARMv5/ARMv6. So far so good and this has worked well.
However, for some reason a newly created app running on a Nexus S with Android 4.0.3 is picking up the wrong (armeabi rather than armeabi-v7a) version of the library.
If we dig into the device filesystem, we find that /data/app/my_app.apk contains the correct versions of the library. However, when Android extracts it to /data/data/my_app, we find that /data/data/my_app/lib/my_lib.so is the armeabi version. But, strangely, /data/data/my_other_app/lib/my_lib.so is the correct armeabi-v7a version.
So the questions are:
1) WTF??
2) How does Android decide which eabi to extract from the APK?
Yes, this is known bug in ICS - it chooses wrong library.
Read about it here:
http://www.moodstocks.com/2012/03/20/ice-cream-sandwich-why-native-code-support-sucks/
https://groups.google.com/d/msg/android-ndk/N8FLjvM81pg/2rYeClQZcckJ
I'm trying to bind to an objective-c library with the btouch tool. Should I be binding to a library (lib.a file) built for the iPhone or for the iOS simulator? And what is the difference if any?
Also, does it make a difference if I bind to a debug build vs. release?
Using the iPhone or the Sim version of the .a file really matters when you actually build and run. The sim version of the library is built for the intel x86 architecture and the iOS device version is built for armv6/arvm7 so it is important to link against the version of the static lib that matches what your are targeting. You can make one big library that has both the sim and iOS device .a linked together. If you lookup on Google there will be some walk throughs on how to link the two together.