We just wrapped up a game in SFML for Mac and submitted it to the Mac store. We are using SFML 2.0. We're using a standard SFML project in Xcode with the link script that copies over the required frameworks. The game works great on all computers from Mac OSX 10.6-10.9. Trouble is, when we submit to the App Store, we get an email back saying the following:
Malformed Framework - The framework bundle
(Shibashiba.app/Contents/Frameworks/freetype.framework) must contain a
symbolic link 'freetype' -> 'Versions/Current/freetype'. Refer to the
Anatomy of Framework Bundles for more information.
If I go into the Archived application, the freetype.framework folder is in Contents/Frameworks and it has a symbolic link that points to Versions/Current/freetype, so I'm at a loss as to what this error means. Could it be some kind of permissions error? Could the freetype distro included with 2.0 be messed up in some way? Any help would be appreciated. This is our last hurdle to shipping!
I think I figured it out! Basically, the compiled freetype.framework included with SFML is linked incorrectly.
If you look in the folder using Finder, the links look correct, but if you compare it to sndfile.framework, it is different. For example:
sndfile.framework
sndfile -> Versions/Current/sndfile
Versions
A
sndfile
Current -> A
versus
freetype.framework
freetype -> Versions/A/freetype
Versions
A
freetype
Current -> A
You can see above that freetype points DIRECTLY to the "A" version of freetype, whereas in the correct "Anatomy", it should point to Current, which in turn points to the current version.
I changed the symlink and Apple accepted the corrected binary:
cd /Library/Frameworks/freetype.framework
ln -fns Versions/Current/freetype freetype
Related
I am working on a project that uses Adobe's DNG SDK 1.6 library, and it is supposed to work on Windows and MacOS.
The library has instructions on how to build it for both platforms, but I had to figure out an error that came up on Windows with Visual Studio. I am not very experienced with big C++ projects so it was not trivial but I got it working. Most of my own code will be done in C# .Net Core, calling the native libraries using a wrapper class with P/Invoke.
Now for Mac that's a different story, I have a MacOS 11 VM, installed Xcode 12.5.1 and followed the steps provided, as expected, it does not work. Bare in mind this is my first time touching Xcode and MacOS.
The project I am trying to build is dng_validate, and it depends on two libraries built by these projects: XMPFiles64 and XMPCore64.
The library projects build without any hiccups, each one of them creating a ".a" file in the folder: dng_sdk_1_6/xmp/toolkit/public/libraries/macintosh/intel_64_libcpp/Debug, they are named libXMPFilesStaticDebug.a and libXMPCoreStaticDebug.a respectively.
When I try to build the dng_validate project, I get the following error:
Library not found for -lXMPFilesStaticDebug
Because of the the error starting with an "l" instead of "lib", under both libraries project settings, I changed the "Executable Prefix" setting to "l" instead of "lib". Rebuilt both of them and made sure the file names changed as expected. But the error persists when trying to build the main project.
Under dng_validate's project settings, there is a setting called "Library Search Paths" and it does point to the proper aforementioned folder using a relative path. I even changed it to an absolute path to see if that would make it work.
I am really lost here, does anyone have an idea of what might be causing it?
Well... After asking on other forums and almost hiring a freelancer to fix this for me, I tried another shot in the dark of renaming the library files and it worked.
I changed the extensions of libXMPFilesStaticDebug.a and libXMPCoreStaticDebug.a from ".a" to ".dylib" and it just compiled and blew my mind with it.
I want to use the libcurl in my XCode project on Mac. But I find there three lib curl dynamic libraries.
Namely, they are libcurl.dylib / libcurl.3.dylib / libcurl.4.dylib.
I find there are a lot of other libraries on Mac which also have the multiple version, in the same way as libcurl.
So what's the difference with those versions library, and which one should I use?
Isn't each one a soft link to the more specific version? Example libXXX -> libXXX.2 -> libXXX.2.3. If you always want the latest libXXX then you link to libXXX. But if you need a specific version you link to that specific version.
As you update OS X or Xcode, these libraries and their soft links get updated but you don't need to change which library reference you have.
Run a terminal window and do ls -l /usr/lib for lots of examples of this.
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.
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 looking for an Xcode project file that will let me trivially build a dynamic framework for libpng to embed in a Mac OS X application bundle. I found this project for libpng 1.2.8, but I need something reasonably current. I can make the project file myself, but I'd rather not reinvent the wheel if I don't have to. Does this already exist, and if so, where?
Check out the KyngChaos UnixImageIO framework. It includes libpng.
If you download the libpng framework code from http://www.libpng.org/pub/png/libpng.html it contains an xcode project that builds the framework.