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.
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'm building a C++11 program that works on osX, but the build for android fails with "error: 'round' is not a member of 'std'".
This is a known problem, associated with the gnustl standard library (https://code.google.com/p/android/issues/detail?id=54418), and the current best workaround seems to be to link against LLVM libc++.
How to do so is documented here for Android Studio or cmake, but I cannot find any documentation for how to do the same with bazel, if it is possible.
A partial answer:
if just building an android static library, the command line call has to specify crosstool_top. This can be set to a specific toolchain using something like --crosstool_top=#androidndk//:toolchain-libcpp.
Options can be found in external/androidndk/BUILD in the directory generated by bazel.
However, if building the library as part of an android application, the crosstool would be inferred. I don't know whether the same approach works, or if not what the answer would be.
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 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'm using Qt Creator under Mac osx, but "Follow symbol under cursor" option, to allow me to jump for class and methods' definitions, does not really work... it only works for local symbols. neither does "Switch between method declaration/definition"
Any ideas?
Thanks much for any thought.
Lior
First off, which version of Qt Creator are you using?
There is a Qt Creator 1.3 release candidate final release (1.3) out now that you might want to try: http://qt.nokia.com/developer/qt-creator-1.3-preview Qt Website Download Section :)
Hope that helps!
As #badcat said, ensure that you have the most recent version.
Other than that, when you have problems following a "symbol under cursor" it could mean 1 of 2 things.
1) I would check that you have your project appropriately constructed so that it has all the include and source files that it needs.
2) This is more rare, but check that you have function definitions in header files and that they are included properly by your source files. As opposed to what you may ask? We have a project here where, instead of include files, functions are defined in .cc files, and extern statements are used so that other files have access to them. (It's legacy code) In such a case, Qt Creator doesn't know how to find anything because files are only aware of each other while linking and have no other way to see each other.