SFML Mac Portability

[Ceylo]

As for running apps.. I've created an empty sfml project from the supplied templates and for me it doesn't work. I had to throw out all references to sfml libs and add the frameworks for it to compile. I've also added freetype (the version that ships with 10.8 ) to the project but it still keeps asking to install XQuartz when running the app. Not sure what's going on there 

Console.app shows the following output:

/Users/test/Library/Developer/Xcode/DerivedData/test-evmgfzadndoehnbskpupqrhdfnbb/Build/Products/Debug/test.app/Contents/MacOS/test requires X11, launching com.apple.X11redirect.

Putting freetype in your project is not enough.
As you can see with the otool output, your app depends on freetype from the X11 directory :

Code: [Select]

/usr/X11/lib/libfreetype.6.dylib (compatibility version 14.0.0, current version 14.2.0)
Which is most probably why the OS tells you to install XQuartz. What you have to do is copying the freetype dylib, changing its install name so that it's relative to the application, and relink you application against the modified freetype dylib.

To change the install name, you can use the install_name_tool command in Terminal.

[Hiura]

Good to know – I'll probably be able to implement that functionality directly in the templates.

(However I've not yet decided if I'll ship or not freetype with SFML. I still need to think about this.)

[capz]

I'll try that later, but what I'm wondering right now is why linking to the default libfreetype still prompts for an install of XQuartz. A subset of X11 libs appear to be shipping with the OS, and since SFML only requires freetype, it seems a little odd that it's asking for more. Maybe I'm missing something here

[Bocaj]

So maybe, if SFML needs all of Xquartz, it would be necessary to make an installer for the application that installs both the application and Xquartz?

[Hiura]

Would be hard to do I think. Moreover, you can't do this if you want to sell your app on the AppStore.

It's – at lease it should be – way more easier to ship freetype inside an application bundle instead.

[capz]

I did some googling today and stumbled upon a website with a bunch of unix libs turned into os x frameworks. Just wanted to share it for reference. it appears to have a fairly up to date version of freetype and developer info. I'd look into it more if only i had some more time on my hands. May just save a few hours of work on sorting out this issue 

http://www.kyngchaos.com/software/frameworks

[Hiura]

Thanks for the link. 

[eigen]

Which is most probably why the OS tells you to install XQuartz. What you have to do is copying the freetype dylib, changing its install name so that it's relative to the application, and relink you application against the modified freetype dylib.

To change the install name, you can use the install_name_tool command in Terminal.

So, what exactly do I have to do to get it to work? I'm not sure about the 'changing its install name' part of the comment. How exactly do I do that ... I'm not really familiar with such things. More step-by-step approach would be great.

All I want to do is try the game out on co-workers mac. This shouldn't be so difficult

[Ceylo]

The point is your app depends on the sfml-graphics framework, that depends on freetype. And sfml-graphics.framework has hardcoded the path where it should find freetype (ie. in the X11 directory).

If A is your application and B is your dependency:
The install name of B is where A (that is linked against B) should look to find B. When linking an application, the linker gathers the install name of the dependencies and hardcode them in the application.

Thus there are two possibilities:
- either modify the freetype dylib so that it provides a new relative install name, and relink sfml-graphics.framework. When relinking, the sfml-graphics framework will hardcode the new install name. That way, the sfml-graphics will no more look for freetype in the X11 directory.
- or just modify the path of the freetype dependency in the sfml-graphics framework.

I'll stick with the second solution as it's more straightforward. First, make a copy of sfml-graphics.framework. In a Terminal, go IN this copy, then...

Code: [Select]

lsshould give this:

Code: [Select]

Resources Versions sfml-graphics

Code: [Select]

otool -L sfml-graphics should give this:

Code: [Select]

sfml-graphics:
@executable_path/../Frameworks/sfml-graphics.framework/Versions/2.0.0/sfml-graphics (compatibility version 2.0.0, current version 2.0.0)
@executable_path/../Frameworks/sfml-window.framework/Versions/2.0.0/sfml-window (compatibility version 2.0.0, current version 2.0.0)
@executable_path/../Frameworks/sfml-system.framework/Versions/2.0.0/sfml-system (compatibility version 2.0.0, current version 2.0.0)
/usr/X11/lib/libfreetype.6.dylib (compatibility version 14.0.0, current version 14.2.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 833.25.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1138.47.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 153.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)
Now type:

Code: [Select]

install_name_tool -change /usr/X11/lib/libfreetype.6.dylib @executable_path/../Frameworks/libfreetype.dylib sfml-graphicsand

Code: [Select]

otool -L sfml-graphicsshould now give

Code: [Select]

sfml-graphics:
@executable_path/../Frameworks/sfml-graphics.framework/Versions/2.0.0/sfml-graphics (compatibility version 2.0.0, current version 2.0.0)
@executable_path/../Frameworks/sfml-window.framework/Versions/2.0.0/sfml-window (compatibility version 2.0.0, current version 2.0.0)
@executable_path/../Frameworks/sfml-system.framework/Versions/2.0.0/sfml-system (compatibility version 2.0.0, current version 2.0.0)
@executable_path/../Frameworks/libfreetype.dylib (compatibility version 14.0.0, current version 14.2.0)
/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 833.25.0)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1138.47.0)
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit (compatibility version 1.0.0, current version 275.0.0)
/System/Library/Frameworks/Carbon.framework/Versions/A/Carbon (compatibility version 2.0.0, current version 153.0.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)
Now your sfml-graphics framework does not depend on any library from the X11 directory. However, I noticed you had manually linked your application against freetype when adding the library to your Xcode project, which implies that your app depends on freetype from the X11 directory. You should not link your app against freetype unless it directly depends on it.

Thus:
- remove any reference to freetype in your Xcode project
- relink your app
- replace sfml-graphics.framework that is inside your app with the modified version
- copy libfreetype.dylib in your app next to sfml-graphics.framework

[eigen]

Thanks for clearing that up.

I can't try this until I get to work tomorrow but will this also work with the sfml-graphics.dylib file? Because I'm using the latest version (pretty much) and have to build it myself. And that produces the dylib files, not the framework ones.

[Ceylo]

Even if you build SFML yourself you can choose to build frameworks instead of dylibs. But yes it'll also work with dylibs.

[eigen]

Thanks, it seems to be working now

[Hiura]

I've summed up this issue here. Let me know if I've missed something.