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.
Related
The issue is about linking x86_64 macOS executables statically against libavcodec, libavdevice, etc, which have some object files built against freestanding as they use YASM which isn't able to embed the macOS "tag" in the binary (see Building for macOS, but linking in object file built for free standing for detailed information on that issue).
Everything works fine under Xcode 11.6 - the following messages are here, but they are warnings.
With the Xcode 12 update they become an error.
How to make them warnings again ? I could not find anything relevant in the ld man page.
ld: in ffmpeg/lib/libavcodec.a(aacencdsp.o), building for macOS, but linking in object file built for free standing, for architecture x86_64
There is no option I have found to revert the error to a warning. Apple has been warning us about this issue for a few releases of XCode now and the warning has become an error.
Until NASM is modified, or we can use some other assembler, the only option that allows me to build and link against the libav libraries in my application is to disable assembly when compiling ffmpeg.
./configure --disable-asm
This works my my case, as the performance of the non-assembly code path is acceptable in my desktop authoring tool. The server-based renderer still uses the assembly code path as it is linux based.
You may have to configure any libaries that you are including in your ffmpeg build to also disable assembly.
Once again, this is an acceptable solution for my case, as the non-assembly code paths are fast enough for my use case.
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.
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.
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).
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.