I have install g++-4.5, as I'm interested in the C++0x stuff (done by sudo port install gcc45). Now I've made sure it's my default compiler (using gcc_select) and all of my Makefile projects do just fine compiling with 4.5.
Now I'm starting a project in xCode 4. How do I get the same C++0x features from within xCode, a.k.a. tell xCode to use g++-4.5?
These two bloggers describe hacking together an Xcode plugin to use one's own build of clang. I imagine you could use the same thing but substitute gcc 4.5's path.
http://belkadan.com/blog/2011/07/Using-Clang-from-SVN-in-Xcode/
http://shapeof.com/archives/2010/01/using_the_latest_llvm_with_xcode.html
I've been meaning to try, and found your question in my research.
Related
I have a peculiar setup, but necessary out of business decisions outside of my control.
I am running macOS 12 on Apple Silicon, have Xcode 9.2, am able to compile and link, by specifying the actual compilers inside the Xcode package, and specifying a more up to date version of ar and ranlib to CMake (the Xcode 9.2 versions give runtime errors on newer systems), basically like this:
-DCMAKE_C_COMPILER=/Applications/Xcode_10.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
-DCMAKE_CXX_COMPILER=/Applications/Xcode_10.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-DCMAKE_OSX_SYSROOT=/Applications/Xcode_10.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
-DCMAKE_OSX_ARCHITECTURES=x86_64
-DCMAKE_AR=/usr/bin/ar
-DCMAKE_RANLIB=/usr/bin/ranlib
These options work and let e.g. Xcode 10.1 tools be usable and we can build our software on newer OS versions, but in the XCode 9.2 case, we fail in linking OpenGL:
ld: can't map file, errno=22 file '/Applications/Xcode_9.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenGL.framework' for architecture x86_64
Due to the commandline option passed to Clang:
/Applications/Xcode_9.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenGL.framework
Which seems to think that it is a file, while it's a framework (directory). Changing this manually to
-framework OpenGL
makes everything work as expected. But that's not what CMake provides.
The question now is: how do I make CMake use this option instead of just passing the OpenGL framework directory path to Clang (with as little change to our CMake files as possible). We currently link any targets using OpenGL using the imported targets provided by find_package(OpenGL REQUIRED):
target_link_libraries(... PRIVATE OpenGL::GL)
And ideally I'd like to keep this the same as there's many of these in our solution.
UPDATE: I hit an additional snag, which seems to be that things like Qt5's cmake scripts are also adding the OpenGL framework directories outside of my OpenGL::GL usage. So perhaps a better approach would be to find a functional ar/ranlib on M1 that can handle what Xcode 9.2's ar/ranlib can handle.
If you want to link specifically with -framework OpenGL, you should change your target_link_libraries line to look like this instead:
target_link_libraries(${PROJECT_NAME} LINK_PUBLIC "-framework OpenGL")
I believe this removes the need for find_package(OpenGL) as well.
I want to force Xcode to use a custom compiler ('clang-llvm' build from the src) so I can use the clang plugin. My Xcode version is 7.3.1.
People say it is possible with custom toolchains. I didn't make a research on them because easier solution worked well for me:
It is also possible to run frontend plugins directly by setting appropriate "build settings" of Xcode. (Several ways to do this, you can set them on the command line for instance: xcodebuild build FOO=bla.) Here are a few build settings that I found useful to inject C flags:
OTHER_CFLAGS, OTHER_CPLUSPLUSFLAGS or to replace the compiler(s) and linker(s):
CC, CPLUSPLUS, LD, LDPLUSPLUS, LIBTOOL
The same approach works to control the "analyze" action: CLANG_ANALYZER_EXEC, CLANG_ANALYZER_OTHER_FLAGS
Disclaimer: some of those build settings are undocumented (afaik). Use at your own risk.
(Taken from [cfe-dev] Compile/refactor iOS Xcode projects)
For me it was enough to define the following User-Defined Settings in Build Settings of Xcode projects:
CC=my-c-compiler
CXX=my-cxx-compiler
LIBTOOL=my-linker-for-static-libraries
If you use CMake, the way to inject your compiler automatically is to use
set_target_properties(your-target PROPERTIES XCODE_ATTRIBUTE_CC "${YOUR_CC}")
set_target_properties(your-target PROPERTIES XCODE_ATTRIBUTE_CXX "${YOUR_CXX}")
Couple of years ago I've written an article that addresses exactly the problem you describe: Creating and using Clang plugin with Xcode
To enable custom clang you need to actually patch internals of Xcode.app itself, it is technically doable but:
it will break when you update Xcode
it will work correctly on your machine
the version of a plugin and your compiler should match, i.e.
they should be compiled using the same tree
So in general it doesn't really scale, so be careful :)
There's a somewhat obscure feature of Xcode where it supports "alternative toolchains". For example, Swift.org provides installable toolchains for Swift built from current sources.
Unfortunately, while Apple's documentation describes how to install and use such alternative toolchains, it doesn't describe how to create them. There are scripts in the Swift source base which build a toolchain and you can look at them to figure out how it's done. They are in https://github.com/apple/swift/tree/master/utils. Start at build-toolchain, which calls build-script and go from there.
Method 1: Change the User Defined settings
Under the project or target Build Settings add the User Defined settings for
CC=/path/to/cc
CXX=/path/to/c++
This is useful if you have a single compiler or linker you want to call, or if you want to call out to a trampoline that decides what to call on the fly.
Method 2: Create a complete custom toolchain via plugin
Using Clang LLVM 1.0.xcplugin as a template (found in the Xcode.app plugins folder), you can modify the plist to point at your own alternative compiler and linker.
This OLLVM on iOS tutorial walks through it.
From project setting go to build setting with target selected. then select All beside the Basic from the top bar. then under build option you can see the compiler option.
Refer below screenshot,
Update :
I think you should refer Using C and C++ in an iOS App with Objective-C++ and this tutorial.
I am recently working on cross compile a library to arm7 architecture on a OSX machine(10.9). I got some instructions online saying I must reset all the compilers and preprocessors to the ones that hides inside XCode. I assume there must be some difference between the ones in Xcode and the ones installed in command line tools.
I did a gcc --version to both ones and I saw the description is different. Beside this one, is there any other difference on those two. Is there any reference on this topic talking about the two different gcc.
Thanks
depends: both could be different.
/usr/bin/gcc
could be either installed with an old Xcode or a custom installer, the version will say if it has been patched by apple.
The one in the Xcode's bundle is the current one for that version of Xcode, and changes with basically every Xcode update, and will get used for xcodebuild command, if xcode-select has that version selected, you can install the Xcode one from inside of the Xcode preferences.
I am currently writing c++ code and compiling using Xcode. I was wondering: How can I find out which c++ compiler is Xcode 5 using?
I would like to know that to make sure that the program I am writing is compilable on other computers that don't necessarily use the same compiler.
Thanks in advance!
You can also check your target's build settings to see what the current setting is. However, Xcode 5 only uses the LLVM 5.0 compiler. GCC is no longer used.
https://developer.apple.com/technologies/tools/features.html
I can't stand XCode, but really love OpenFrameworks, and I know it works on Linux+Win32 so I don't see why it should be XCode dependent. If I need to have XCode installed that's fine, I just don't want to use it at all.
Xcode internally uses gcc/llvm. in fact from the command line you can cd into a directory that contains an openFrameworks project and just type xcodebuild. but this won't allow you to edit the project file and add new source code, etc.
the Linux makefiles could be adapted to work on OSX as well. they already contain a lot of the information necessary about finding the correct source files, library paths etc. however Linux allows us to install many more components as shared system libraries, while on OSX we link most of the libs statically, so a number of extra library paths would need to be added. probably the biggest gotcha is that everything has to be compiled 32 bit, which means passing -arch i386 everywhere, so you can't just install dependant libs using Homebrew or MacPorts. we are in the process of transitioning to 64 bit but there are still some QuickTime calls that require us to stick with 32 bit, mainly around accessing legacy video capture devices that a lot of us still use for computer vision.
like #cdelacroix points out, we only maintain Xcode project files on OSX. this is mainly due to the lack of a decent alternative. there is a version of Code::Blocks for OSX but it is not very well supported, has some issues with native gui rendering and tends to lag behind the other platforms. Xcode is also the easiest way to install a toolchain on OSX so for most users installing Xcode is necessary.
if you do get a makefile based build system working, and would be interested in maintaining it medium to long term, please consider contributing it to the GitHub repository, it would be gladly accepted.
As of March 2013, openFrameworks has official makefile support for compiling the library itself. However, at the time of this writing, the changes haven't yet been merged into the stable release. You'll need to clone the Git repository and switch to the development branch.
git clone https://github.com/openframeworks/openFrameworks
cd openFrameworks && git checkout develop
cd libs/openFrameworksCompiled/project
make
As far as I can tell, we still need to use the unofficial solutions for compiling apps against the library.
You need Xcode, or at least a set of compilers (more information is available here), but otherwise, no, you can edit/work with the code in whatever editor or environment you want.
Here's a link to a makefile which will compile an OpenFrameworks application on OsX:
https://gist.github.com/labe-me/1190981
Place the makefile in the apps' directory and run make. Tested on OsX 10.6, but haven't tried with addons yet.
As #mipadi said, there is no requirement to actually use Xcode, you can do pretty much everything you do in Xcode with make or cake or any of your build system of choice. All you have to do is find the right set of command line options to pass to the usual tools (compiler, linker, strip, etc.), and sometimes the easier way is to... look in the Xcode build window how it is doing stuff (expand the lines with the small button on the right of each line).
For example you can link with your framework of choice with ld -framework Framework -FPathToFramework foo.o or your dynamic library with ld -lLib -LPathToDylib foo.o. You might have to learn about #rpath, #loader_path and install_name_tool to ship a self-contained packaged application.
As for OpenFrameworks, the "requirement" for Xcode is that the authors decided to maintain only Xcode project files. I just looked at how they do it, they ship source code and Xcode project files that build static libraries, so it will be even more simple for you (although you will need to link the library dependencies by hand). You will have to choose between compiling everything from source in your build system (if you want more customization power without touching Xcode), or just produce the 2 static libraries (openFrameworks.a and openFrameworksDebug.a) with Xcode once, then use them in your build system (recommended until you really need continuous customization).