I am trying to get some older third-party software to compile on OS X 10.9. I've managed to get rid of most compilation problems by adjusting settings in the Makefiles, which were originally written for gcc probably around 2005. However, I currently don't know how to overcome this error for a C++ source file:
/utility.h:42:10: fatal error: 'ext/slist' file not found
I understand that ext/slist belongs to some version of STL. Has that version been superseded or does it have to be activated in any special way for Apple's version of Clang/LLVM (5.0 for OS X 10.9)?
If at all possible, I would prefer to compile this software with the pre-installed tools and not go through such steps as installing gcc via MacPorts.
BTW, these warnings also persist:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/ext/hash_set:202:2:
warning:
Use of the header is deprecated. Migrate to
[-W#warnings] /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1/ext/hash_map:209:2:
warning:
Use of the header is deprecated. Migrate to
[-W#warnings]
Slist is a singly linked list and was an extention included in libstdc++. Mac OS X has been moving away from libstdc++ toward libc++, which provides a C++11 standard library. C++11 provides a singly linked list under the name std::forward_list in the header <forward_list>.
I believe libstdc++ is still included in the developer tools, so you may also be able to switch your project back to that. If you're using an Xcode project you can select the library in the build settings, or ensure that the program is getting built with -stdlib=libstdc++
Related
Ever since switching to std=c++11 mode (or gnu++11, which seems slightly more stable), CGAL has been exceptionally crash-prone for me on OSX (there might have been more changes made at the same time; it was very chaotic).
We are building with Clang. This very dated FAQ entry suggests that the standard OSX compiler used to have issues with CGAL.
The default compiler on Mac OS X is g++ 4.0 (at least on Tiger and
Leopard). It has some bugs that are unfortunately encountered by some
programs using CGAL when optimizing. We recommend that you use a more
recent version of g++, such as g++ 4.2, which you can get by upgrading
to the latest XCode, or using Fink.
Is this still relevant?
About to try rebuilding CGAL (and header including libraries) without optimizations, but I'd like to know what the official support is for Clang on OSX.
Update
It's looking like user error. A number of APPLE #ifdefs were added during the C++11 upgrade (for unclear reasons), and removing them seems to be fixing many of the crashes.
According to CGAL's website, CLANG is supported.
http://doc.cgal.org/latest/Manual/installation.html#seccompilers
I downloaded the clang for windows binary package from the website. It provides some nice VS/MSBuild integration by allowing to build VS projects using clang instead of MSVC. However, I notice that it still uses the MSVC C Library and also the MSVC linker (link.exe). Also, including any C++ STL headers like string or iostream causes build errors.
My question is: Is it possible to use full clang/llvm toolchain along with some non-Microsoft libraries (like libc++, mingw etc.) to build a native Windows binary? Doing all of this from within VS is a bonus but even from command-line would be fine.
I heavily use the c++0x/c++11 features in my project, particularly code blocks and shared pointers. When I upgraded my OS to 10.8 Mountain Lion (Edit: From 10.7), I was forced to upgrade Xcode. In upgrading Xcode, I lost the ability to compile my c++ project for deployment on 10.6 systems as I get the following error.
clang: error: invalid deployment target for -stdlib=libc++ (requires Mac OS X 10.7 or later)
It appears that Apple is trying to force people to upgrade by not allowing developers to support Snow Leopard. This makes me angry. Arrrggg!!!
What can I do?
EDIT: After several comments back and forth, it should be made clear that 10.6 does not ship with system libc++ libraries. As a result, simply being able to build a libc++ project for 10.6 deployment is not enough. You would also need to include libc++ binaries with your 10.6 distribution or statically link to them. So lets continue with the premise that I am already doing that.
UPDATE 1: This question was originally intended for use with Xcode 4.5.2 (the latest version at the time the question was asked). I have since upgraded to Xcode 4.6.3 and have updated the question and answer to reflect that.
UPDATE 2: I've since upgraded to Xcode 5.0.2. The technique listed in the selected answer below still works as expected.
UPDATE 3: I've since upgraded to Xcode 5.1. The technique listed in the answer below does not yet work for this version!
UPDATE 4: I've since upgraded to Xcode 6.0.1. The technique listed in the selected answer below appears to be working again.
UPDATE 5: I've since upgraded to Xcode 7.1.1. The technique listed in the selected answer below appears to be working again, with one important caveat. You must disable Bitcoding used for AppThinning since the opensource LLVM version doesn't support it (nor should it). So you will need to switch between the open source and Apple LLVM clang in order to compile for both 10.6 and tvOS/watchOS (since Bitcoding is required for those OSes).
Apple has decided to only officially support libc++ on 10.7 or higher. So the version of clang/llvm that ships with Xcode checks to see if the deployment target is set for 10.6 when using libc++, and prevents you from compiling. However, this flag is not included in the open source version of clang/llvm.
Take a look at this thread:
http://permalink.gmane.org/gmane.comp.compilers.clang.devel/17557
So, to compile a project that is using c++11 for 10.6 deployment, you need to give Xcode the open source version. Here is one way of doing it:
Download the open source version of clang from here (use LLVM 3.1 for Xcode 4.5.x; use LLVM 3.2 for Xcode 4.6.x; use LLVM 3.3 for Xcode 5.0.x; use LLVM 3.5.0 for XCode 6.0.1; use LLVM 3.7.0 for XCode 7.1.1):
http://llvm.org/releases/download.html
Make a backup of Xcode's default clang compiler and put it in a safe place (In case you screw up!)
This is located at:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
Replace the default clang compiler with the one you downloaded from [1]
chown the clang binary for root:wheel with sudo chown root:wheel clang from the bin directory listed in [2].
Startup Xcode and compile!
UPDATE #1: This technique does not currently work for Xcode 5.1 or newer, which relies on LLVM 3.4. When I get some more time, I will try and find a solution to post here. But if someone comes up with a solution before me, they should post it as an answer.
UPDATE #2: Unfortunately I can't remember if I ever found a solution for Xcode 5.1, however I can confirm that the technique does still work for Xcode 6.0.1. I haven't tested on versions newer than that, but it could still work.
UPDATE #3: This technique appears to still work with XCode 7.1.1 using LLVM 3.7.0. However, the open source LLVM clang does not support Bitcoding. So you will need to switch between the open source compiler and Apple's compiler in order to develop for both 10.6 and tvOS/watchOS (which require Bitcoding).
P.S.: The Mac OS X binaries for LLVM 3.4 and 3.5.0 are listed as "Clang for Darwin 10.9" at www.llvm.org/releases/download.html rather than as "Clang Binaries for Mac OS X" in previous versions.
While Xcode 4.5.x is the current default version on OS X 10.8, you can have other, older versions of Xcode, such as Xcode 3.2.6 for OS X 10.6, available on 10.8 as long as you have access to their installers. You will need to ensure you install each one to a unique directory. Also, one thing you can't or shouldn't do is to install the Command Line Tools component or installer package of older Xcodes onto your 10.8 system, i.e. not into /usr or /System/Library. You can use the xcodebuild, xcode-select, and xcrun command line tools to access non-default Xcode components. See their man pages for more info. Older versions of Xcode are available to registered users of developer.apple.com
UPDATE: Based on your subsequent comments, I believe I did miss the point of the question and also that you had answered your own question. I think what you are saying is that you upgraded from 10.7 to 10.8, not from 10.6 to 10.8 as I assumed. You also did not make clear in the original question that you were distributing your own version of Apple's libc++ and friends from 10.7 with your own app. Apple does not make it easy in Xcode to do something like that since it has long been Apple's policy to discourage static linking with libs or distributing duplicate libs (which in some cases could violate license terms). There are good reasons for that policy.
The bottom line is that libc++ is only shipped with OS X 10.7 or later systems. There never was Apple support for libc++ in 10.6, so it's misleading to say it was removed. If you want to supply an app that is deployable on 10.6 and later systems and depends on libc++, the safest approach is to build your own clang/llvm and libc++ targeted for OS X 10.6 and use that to build your project. There are various ways to do that, probably the easiest is to use the MacPorts versions and set the deployment target in MacPorts for 10.6. Or build it all from scratch yourself. But modifying the clang compiler within Xcode 4.5 is a bad idea. And copying Apple libraries to one's app is generally a bad idea.
If you have a solution that works for you, great. But I would not recommend it to others.
I am currently starting to work seriously with C++. I've heard about the new features of C++11 and I like them. So I wonder whether I should write my new project according to the new standard. My current toolchain (that comes with XCode, I guess) does not support features like the auto keyword for type inference.
> g++
i686-apple-darwin11-llvm-g++-4.2
So I am looking for an easy and safe way to get a C++11 toolchain to try it out. I cannot risk breaking my old toolchain.
I know where to get binaries of GCC 4.8 for Mountain Lion, but I don't know how to install all the files manually (and would rather have a package manager do this for me). This discussion explains how to install GCC via homebrew, but I am affraid that this will overwrite and break my existing toolchain.
Also, I do not know how to configure a new toolchain in Eclipse after installation so I can use it with Eclipse/CDT.
You can use the homebrew package manager for OSX: Link
Have a look at https://github.com/mxcl/homebrew/wiki/Custom-GCC-and-cross-compilers and more specifically at homebrew dupes which has duplicates (but more recent versions) for software provided by OS X.
For a reasonable C++11 experience you should look for gcc 4.6 or gcc 4.7. When you have installed a recent version of gcc, you can then use it in your Makefiles. Mind you have to compile with -std=c++0x (gcc-4.6) or -std=c++11 (gcc-4.7+).
You can also look here How to enable C++11/C++0x support in Eclipse CDT? if you get syntax errors and warnings for C++11 constructs in Eclipse CDT.
I'm having trouble using libpng with Xcode 4.2 on OS X 10.7.1.
My program fails to launch with the error:
dyld: Library not loaded: /usr/X11/lib/libpng15.15.dylib
and:
Reason: Incompatible library version: glsl_test requires version 20.0.0 or later,
but libpng15.15.dylib provides version 17.0.0
All I'm doing is adding /usr/X11/libpng.dylib to the linked libraries, so where is this 'version 20' requirement coming from? Why isn't Xcode just requiring the version that's available? How do I go about telling my program that it's OK to use version 17?
Without knowing much about the intricacies of Xcode, it sounds like something else in your program requires a later version of the libpng library. This could even be something that is implicitly included by the build environment.
I'd double-check that you have a build environment that is compatible with your intended target. I'd also double-check that you're specifying the inclusion of the library using appropriate syntax (e.g., using -lpng vs. an explicit "/usr/X11/libpng.dylib").