I have a development Mac running 10.5. This causes my apps to not work in 10.4 (Google "_nsdefaultrunloopmode tiger"). I read the solution is to install the 10.4 SDK and compile against that. I have it installed (at least I have /Developer/SDKs/MacOSX10.4u.sdk)
Now I can't find a way to actually use that - I'm doing two things:
1) Compiling a library (SDL) using Makefiles
2) Compiling the program using Eclipse
I can't find a way to specify the SDK version in either of these two scenarios. Documentation doesn't seem to mention how to do it, so I'm thinking I'm overlooking something obvious. Any help?
If you look at the commands issued by Xcode for a build with the 10.4 SDK selected you will see that gcc/g++ flags include:
-isysroot /Developer/SDKs/MacOSX10.4u.sdk
and
-mmacosx-version-min=10.4
Related
I am trying to build an AR app with ARKit, trying to run these open-source ARKit project and Plugins on github:
https://github.com/augmentedrealityplugin/shapeDetection
https://github.com/ShawnMa16/AR-Drawing
However I have this problem
I have tried the solutions:
Set 'Yes' in Build Libraries for Distribution
installing the Xcode Toolchain
delete and add the framework again in Embedded Frameworks
But it cannot help, is there any solutions to my problem, so I can at least try and run these project and Plugins on GitHub?
Swift obtained ABI compatibility in v5.0. But only gained module compatibility in v5.1. So, frameworks compiled with a version before 5.1 are toolchain specific. This is what what the compatibility error you’re receiving refers to.
Pre 5.1, you need to compile both your application and the library with the same version of the Swift compiler. With 5.1 and beyond, preferably, use the latest toolchain for both, but that is optional as long as they are at least compiled with 5.1 or greater. Existing binary distributions of the library compiled pre v5.1 will not work with the latest version of Xcode.
This means you’ll need to compile the library from source, upgrading the Xcode project settings to at least 5.1, and possibly the source code, as necessary.
See this post for more details: https://swift.org/blog/abi-stability-and-more/
I try to follow this guide:
http://code.google.com/p/iphone-dev/wiki/Building
it wants me to build LLVM from source, but I already have one installed in Ubuntu using apt-get, why they want me to compile from source? can I use the one provided by Ubuntu community? if not, how will they coexist? should I uninstall apt-installed llvm first?
The guide you're looking at is several years out of date, and will most likely not work. (In fact, there are a ton of frustrated comments suggesting that it hasn't worked since at least 2011, as the Mac OS X 10.4u SDK is no longer available for download.)
The only supported platform for iOS development is Mac OS X. I would strongly recommend that you use that platform if you want to do iOS development, as basically all tutorials you will find online will assume that's what you're using.
That all being said, if the instructions were otherwise correct, you would still need to build LLVM separately from the version provided by Ubuntu, as iOS devices use ARM CPUs, and the distribution's LLVM will only compile binaries for your system (probably either x86 or x86-64).
I'd like to use the excellent stringencoders library in an iOS application. It's a fairly typical c library, with a configure script generated by autoconf and a makefile.
What I'd like to do is compile arm7 and i386 versions on Mac OSX and then use lipo to make a fat binary.
I'm having trouble figuring out how to persuade the build tools to create my platform-specific binaries. There's a few articles out there and even a few scripts but most of them are targeted at XCode 4.2 and don't work with 4.3.
It looks like it should be possible to create a fairly generic build script that can play nicely with configure and make but I'm at a loss as to where to even start.
Have you successfully done anything like this? I'd love some pointers!
BTW: 'import all the sourcecode into your project' is NOT a viable solution. That way lies madness.
Thanks.
I've ported a handful of open source C libraries to iOS (see iOS Ports). I've found the most reliable way to port a library is to build a new Xcode project with a build target for a static iOS Library. It is important to note that Apple will not allow your iOS Application to contain dynamic libraries if you plan to distribute your app on the iTunes App store, so you will be unable to use FAT libraries.
These are the steps I usually follow when porting libraries to iOS which usually built with the GNU Autotools:
Run ./configure with appropriate flags on OS X.
Verify that the library builds correctly on OS X using make.
Create a new Xcode project using the iOS Static Library template.
Add the config.h from the previous configure run to the Xcode project.
Read the automake file (Makefile.am), and add the referenced sources in the automaker targets to the Xcode target for the static library.
Copy the CPP flags (i.e. -DHAVE_CONFIG_H) from the automake file to the build settings in Xcode.
Compile in Xcode and start running down errors (usually by adding missing header include paths or missing source files).
The directory structure I usually use is the following:
project/
project/ported-project.xcodeproj
project/project-x.x.x.tar.gz
project/project-x.x.x
project/project -> project-x.x.x
I know this is not exactly what you asked for in your question, however it is rough outline of the steps I've used for years for porting libraries. The benefit of creating an actual Xcode to compile the ported library is that it makes it easier to integrate the library into multiple Xcode iOS applications.
If you need clarification or more detailed instructions, let me know and I"ll try to write up more extensive instructions and update my answer.
Is it plausible to add the source files (i.e. .c files) to your project directly?
Objective C is a superset of C so i am surprised that the code did not work directly out of the box in XCode 4. Are you missing out something there ? just suggesting
Generate your project files using gyp: http://code.google.com/p/gyp/
I use it to share libraries between win/osx/ios and linux (pi).
This is my first question here.
I am having trouble setting up Eclipse in Mac Os X 10.6 for compiling Fortran codes. I need to use Eclipse to write a mixed code using both C++ and Fortran. I am using Eclipse Helios Service Release 2. The problem starts with Apple's default compiler GCC 4.2 which doesn't have Fortran enabled. I installed GCC 4.6 given here and have managed to get it working in Terminal. But still Eclipse and Xcode both use the 4.2 and I can't find a way to change the settings. Can you help me with this problem? I prefer not to the delete the default GCC 4.2. I just want to get eclipse to use 4.6.
Thank you.
So I solved this problem by using NetBeans instead of Eclipse. I simply set up a second compiler profile directed to /usr/local/bin where GCC 4.6 is installed if you use the package provided by HPC. It automatically detected everything it needs and everything is looking good.
I am new to Xcode and MonoTouch, so please bear with me.
Is it possible to develop MonoTouch applications with Xcode instead of with MonoDevelop? I have read the MonoTouch Xcode tutorial but unfortunately the process described does not seem to work with the latest MonoTouch version (I get a "No SDK in directory" error, there is also no resource rules file in the root SDK directory). Finally, where am I supposed to put the directives to the MonoTouch compiler?
I have downloaded the trial version of MonoTouch.
Thanks in advance.
Its technically possible, but not in the supported MonoTouch workflow, so you'd be somewhat on your own. What you'd need to do is look at the output of a MonoTouch build with "-v -v -v" in the Extra Arguments field to see how we invoke the AOT compiler. You'll also need to look at the main.m generated by -keeptemp and adapt that in to your Xcode workflow. Lastly you would not be able to use the linker unless you maintained a parallel monotouch project which compiled and linked, and then you did a secondary build step to update your Xcode project.
Xcode does not support third-party plug-ins or environments.