I have a serious issue getting Xcode 7.3 to compile a Project against Mac SDK 10.7 with LLVM (7+) and C++11. The source of the issue seems to be Xcode or the fact that I'm running OS X 10.11. Some colleagues of mine don't have the same issue compiling the same issue with older Xcode Versions (6). Here is the general setup:
The needed Libraries and Headers are linked with CMake. The Include paths of everything got checked multiple times. The created Xcode Project also seems to be ok, we've compared all important settings (C++ dialect, std library , target, defines etc) against systems where the project does compile.
The actual error comes when compiling vecLib source.It seems to be a set of random error messages I would trace back to the lack of c++ std headers.. Here are a few examples:
Explicite specialization of non-template class 'complex'
Redifinition of complex as different kind of symbol
Did anybody run into similar problems when working with newer Xcodes against older SDKs?
EDIT
Here is some more informations. After checking what was behind the redifinition, I found that for some odd reason, the complex definition that was interfering with the forward declaration in the file comes from /usr/include/c++/4.2.1. I think that the header is outdated or at least not compatible with c++11. I checked again what the compiler used and the lib / language (std=c++11 and stdlib=libc++) where correctly set. I have the strange feeling that the source in user/include isn't supposed to be included but I don't know how to fix it.
EDIT 2
I've checked the standard include paths with cpp -v and got the following list:
/usr/local/include
/Applications/XCode/.../XCodeDefault.xtoolchain/usr/bin/../lib/clang/7.3.0/include
/Applications/XCode/.../XCodeDefault.xtoolchain/usr/include
/usr/include
/System/Library/Frameworks
/Library/Frameworks
The definition of complex in the Xcode toolchain (3rd entry) is the correct one, the definition in /usr/include is the one that seems to be used while compiling, leading to the error messages. The definition of complex uses structs.
What is the issue here? Is the issue that Xcode / Clang or what ever decides to go with usr/include instead of the toolchain include? I've checked the project settings and the compiler output and there was no explicit include of this path.
It seems like AppleClang 7+ and libc++ just doesn't support vecLib from OS X SDK 10.7. I had to go back to Xcode 6 to get it to build.
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.
Recently I ran into a CMake problem that can be found in this thread:
Cmake on OSX Yosemite 10.10.3 - GLEW: package 'gl' not found
Eventually it got solved, maybe partly due to my inexperience in XCode and CMake. (I mainly used visual studio to compile projects in the past.)
After the alteration in the linked thread I got warning about my GLEW libs in CMake
(Is this something I should be worried about or is it not important?):
MACOSX_RPATH is not specified for the following targets:
GLEW_MX_shared
GLEW_shared
I simply ignored it and tried to compile my project in XCode with the ALL_BUILD target selected. In the sparky target it said the include files in main could not be found so I added the .h files into the inc folder of my project.
When I compiled again the compiler started complaining again
(I don't know what this error means and how I can fix it.):
ld: library not found for -llib
Googled it for the entire day now and I can't find anything to solve this issue.
It's so frustrating working with XCode as an IDE but I really want to learn more about different platforms and their most popular IDE's so I can make multi platform applications from the start instead of porting it afterwards.
And if it matters I am using OSX Yosemite 10.10.3.
To make my issue easier to understand, I've put a zip of my project on my dropbox.
https://www.dropbox.com/s/xnrh90kuih9ia5a/SPARKY%202.zip?dl=0
Feel free to ask questions if I explained things to briefly and again, thanks to everyone who contributes here. I really learned allot after discovering these forums.
EDIT: Alright I booted up my windows machine, generated a visual studio environment and tried to build it on there. Seems that the same problem also happens here. I looked at the linker attributes/flags and saw a lib.lib file added to the linking process which doesn't look right at all.
When removing the file, the error disappeared and many others arrived! (Which are simply solved by linking the appropriate libs so I wont handle those here.)
I misunderstood the error on my mac and thought it was referring to a random library which I needed to hunt down but actually it's a inconsistency in one of my CMake files.
EDIT2: Now I only have to find out where the lib.lib comes from and how I can ditch the flags from the project so I can generate my environment and build right away!
So moral of the story. Sometimes the solution is right in front of you and still ends up more like looking for a needle in a haystack.
I removed the following from my root CMakeLists.txt file and the random lib.lib library was gone from my generated projects
SET( PROJ_LIBRARIES "lib" )
I thought this added a folder containing libraries but actually what it did was adding another flag for a specific library because this variable was being fed to:
TARGET_LINK_LIBRARIES( ${PROJ_NAME} ${PROJ_LIBRARIES} ${OPENGL_LIBRARIES} ${GLEW_LIBRARIES} )
I'm having trouble linking an Xcode project using the AAF SDK, with Xcode 5.1.1 on MacOS 10.9.5. When I link the main dynamic library, these symbols come up missing:
_StgCreateDocfile
_StgCreateDocfileOnILockBytes
_StgOpenStorage
_StgOpenStorageOnILockBytes
AssertProc
I can't find a definition for them anywhere in the entire source tree for the SDK. The first four appear to be part of Structured Storage on Windows. A Structured Storage library is provided in the SDK and I'm already linking that.
Can anyone tell me of a Mac system library that defines these? Or is there a linker argument that pulls in a library for them? Thanks for any help.
A late answer (!), but in case anyone comes across this... The solution is either:
To use the makefiles with the AAF SDK to generate the AAF dylib,
which works fine. or...
If you use Xcode to build the AAF SDK, ensure the correct
#defines are kept, namely:
_DEBUG OM_DEBUG OM_STACK_TRACE_ON_ASSERT OM_USE_SCHEMASOFT_SS OM_STRUCTURED_STORAGE
Note that DEBUG=1 is absent (it is added by default by Xcode) - if defined, this brings in AssertProc. Define NDEBUG on release builds and omit the debug defines.
The Stg... functions are part of the MS implementation of Structured storage as you stated, but should not be referenced on a Mac, the Schemasoft implementation being used.
Okay I've been searching for hours to try and solve this but nothing has worked. This problem is very similar to other posts, but I none of their solutions work.
So I am writing an OpenGL program using glew and glfw and for some reason I am unable to get the program to compile. The error is on the include statement:
#include <GL/glfw.h>
and the error says 'GL.glfw.h' file not found.
I have followed all the instructions on the
GLFW-2.7.8 Release Notes
web page, which includes making glfw, and then importing the static library libglfw.a into Xcode. The library does show up under Build Phases -> Link Binary with Libraries, but apart from that Xcode doesn't seem to recognize it. For example, under the File Inspector it detects the file type as "Default - data".
The static library is configured for 64-bit architecture, which I am running.
I have tried changing the search paths under Build Settings.
I have the following frameworks included: Cocoa, OpenGL, and IOKit.
Please let me know if there is any more information you need to help me solve this problem and thank you for reading.
It turns out my glew was not importing correctly and so glfw did not work either.
These are the steps I took:
Changed the Base SDK from Latest OSX (10.8) to Current OSX.
After doing this, I "reduced" the error to an Apple Mach-O Linker (Id) error. Next:
Added -lGLEW to Other Linker Flags.
Added /opt/local/include/ to the header search paths
Added /opt/local/lib/ to the library search paths
Here is where I found my answer.
We have multiple development machines, some running Xcode 3.2.5 and others running Xcode 4.2. We have a static library that is referenced by our project. It contains Objective C categories, so we need to use the -force_load flag with the path to the library.
The problem that we are having is that on Xcode 4.2, the library is linked from a different location than the path that we specified in -force_load. This causes duplicate symbol errors since it's trying to link two copies of the same library.
The path Xcode 4.2 links from is:
/Users/USERNAME/Library/Developer/Xcode/DerivedData/PROJECTNAME-ehxeazvigqrpvogkxlkcmdzpisdw/Build/Products/CONFIGURATION-PLATFORM/
whereas the location that Xcode 3.2.5 links from is:
PROJECT_ROOT_OF_STATIC_LIBRARY/build/CONFIGURATION-PLATFORM/
Is there a way to get Xcode 4.2 to use the same locations as Xcode 3.2.5 when linking static libraries so that we can use the force_load linker option? If not, can anyone suggest an alternative solution to get Xcode 3.2.5 and 4.2 to play nicely together?
It sounds to me like you are doing things the hard way.
I've never used -force_load to load static libraries. With the libraries I use, they are all stored as frameworks in a directory on my system which is separate from the project. I then use the XCode standard add frameworks dialogs to bring them into the project and "-ObjC -all_load" to ensure they work and categories are active.
I've successfully move a few projects from XCode 3 to 4 and not had the problem you are mentioning. I suspect that if you can stop using -force_load your problems will go away.