SFML community forums

Help => General => Topic started by: Bocaj on June 05, 2012, 10:47:02 pm

Title: SFML Mac Portability
Post by: Bocaj on June 05, 2012, 10:47:02 pm

I was reading the tutorial to install SFML 2.0, and it said that it is necessary to have X11 installed on your computer in order to develop SFML.  I heard that in the next release of OS X, X11 will be removed.  Does this mean that all Mac users who have versions after Lion will have to install XQuartz before being able to open SFML applications?  Or, because they are just using SFML programs, not developing them, they don't need XQuartz to run SFML?

Title: Re: SFML Mac Portability
Post by: Hiura on June 05, 2012, 11:51:33 pm

I can't tell yet. We'll see when 10.8 comes out if the removal of X11 is only a rumor or not. Then I'll think of a solution.

SFML only use freetype from X11. Maybe I'll also provide a freetype framework like the sndfile framework.

Title: Re: SFML Mac Portability
Post by: Bocaj on June 06, 2012, 03:02:44 am

OK, so if X11 is removed in OS X Mountain Lion, it is still possible that the downloader of the application will not have to download anything besides the .app package?

Title: Re: SFML Mac Portability
Post by: Hiura on June 06, 2012, 08:45:21 am

As I said I don't know yet. freetype will probably - but not certainly - be shipped with SFML. We'll figure out what to do later when 10.8 is released.

Title: Re: SFML Mac Portability
Post by: capz on June 08, 2012, 04:21:36 am

What apple is shipping as X11 is actually a repackaging of the open-source (though mostly developed by apple engineers) XQuartz.

Edit:

I should really read these things twice..
Anyways, I'm not sure if you needed to install X11 in the past in order to run SFML apps since I installed it by default, but if so, then the user would (once, identical to how you install java on 10.7) get a one-click install via software update. It's quick and painless :)

Should be the same as with X11, so if you didn't need to install that in the past to run SFML apps, then you shouldn't have to install XQuartz.

Also, vanilla SFML 2 works just fine on 10.8 ;)

Title: Re: SFML Mac Portability
Post by: Hiura on June 08, 2012, 09:41:55 am

Quote

then the user would get a one-click install via software update. It's quick and painless

Yes, that's why I'm not 100% sure I'll make a package for freetype.

Quote

Also, vanilla SFML 2 works just fine on 10.8

Good to hear!  :)
One quick question : did you upgrade from 10.7 to install 10.8 or did you make a fresh installation ?
If X11/XQuartz is no longer shipped by Apple but you did an upgrade then you might have kept freetype library from Lion. Maybe.

Title: Re: SFML Mac Portability
Post by: capz on June 08, 2012, 03:03:02 pm

I did indeed upgrade. I'll do a clean install for testing purposes later today, and build SFML on that.

Will report back asap  :)

Title: Re: SFML Mac Portability
Post by: capz on June 08, 2012, 06:33:23 pm

Edit: made this a separate post as to trigger the topic reply notification :)

So I've done a 100% clean install inside of VMWare (which is allowed now, so thanks apple!) and the results are in!

When you attempt to run an SFML 2.0 app, you are indeed presented with an option to install XQuartz.
Clicking it will open a browser, pointing at xquartz.macosforge.com (http://xquartz.macosforge.com), from which you'll have to download the disk image containing the XQuartz installer. So not a one-click as I thought before.

Everything works as expected after installing XQuartz though.

As for compiling SFML from source:
XQuartz includes a TON of libs, including freetype 2.4.9 + patches. More specifically:

Quote

* freetype 2.4.9
      * CVE-2012-1126
      * CVE-2012-1127
      * CVE-2012-1128
      * CVE-2012-1129
      * CVE-2012-1130
      * CVE-2012-1131
      * CVE-2012-1132
      * CVE-2012-1133
      * CVE-2012-1134
      * CVE-2012-1135
      * CVE-2012-1136
      * CVE-2012-1137
      * CVE-2012-1138
      * CVE-2012-1139
      * CVE-2012-1140
      * CVE-2012-1141
      * CVE-2012-1142
      * CVE-2012-1143
      * CVE-2012-1144

Configuring & Compiling SFML from source works as expected from that point onward. Kind of; the make install only worked properly when CMAKE_OSX_DEPLOYMENT_TARGET was set manually (I set it to 10.8, was blank initially)

So the freetype situation is a non-issue ;)

For me though.. I was hoping to get an SFML project into the app store, but now I'm not so sure if that will be possible with the dependency on an XQuartz install. Might need to review the submission guidelines

Title: Re: SFML Mac Portability
Post by: Bocaj on June 09, 2012, 12:36:09 am

Would it be possible to ship freetype with SFML so the user doesn't have to download XQuartz to run it?  XQuartz includes a lot, but SFML only needs freetype, right?

Title: Re: SFML Mac Portability
Post by: Hiura on June 09, 2012, 10:23:51 am

Quote from: capz on June 08, 2012, 06:33:23 pm

When you attempt to run an SFML 2.0 app, you are indeed presented with an option to install XQuartz.

Great!

Is the user still prompted to install XQuartz if you copied freetype library to your application bundle ? (If you don't have time to test this I'll test it later when 10.8 is officially released.)

Quote from: Bocaj on June 09, 2012, 12:36:09 am

Would it be possible to ship freetype with SFML so the user doesn't have to download XQuartz to run it?  XQuartz includes a lot, but SFML only needs freetype, right?

Yes, SFML only need freetype from X11/XQuartz. However, I prefer not providing this extra framework because then I should keep SFML version of freetype up-to-date which is already done by XQuartz. So in this mindset I rather prefer "forcing" SFML developer to install XQuartz on their own so they can put freetype in their .app.

Now this is not a definitive decision. I'm open to discussion to find what's best for both developers and users. However this won't be changed until SFML 2.1. So we have time before us.

Title: Re: SFML Mac Portability
Post by: capz on June 09, 2012, 07:36:51 pm

Quote from: Hiura on June 09, 2012, 10:23:51 am

Quote from: capz on June 08, 2012, 06:33:23 pm

When you attempt to run an SFML 2.0 app, you are indeed presented with an option to install XQuartz.

Great!

Is the user still prompted to install XQuartz if you copied freetype library to your application bundle ? (If you don't have time to test this I'll test it later when 10.8 is officially released.)

I'd personally be fine with grabbing a copy of the dylib and bundling it with my app similar to how you link with sfml itself, but sfml probably won't compile unless it's present at compile-time of the framework, no?

Title: Re: SFML Mac Portability
Post by: Hiura on June 09, 2012, 07:38:25 pm

Yes, but you don't actually need to build SFML to use it. Just download the last release from the website.  ;)

Title: Re: SFML Mac Portability
Post by: capz on June 10, 2012, 01:27:39 am

Quote from: Hiura on June 09, 2012, 07:38:25 pm

Yes, but you don't actually need to build SFML to use it. Just download the last release from the website.  ;)

Oh I wasn't aware that there are prebuilt frameworks already :D

Anyway..  ;D
So I poked around in yet another clean install of 10.8 (making snapshots so I can revert from now on :P) and I noticed some things which I thought were interesting:
SFML will in fact compile just fine without XQuartz installed if you make a (soft) symlink to libfreetype.6.dylib, called libfreetype.dylib. A bunch of libs and headers actually ship with the OS, and even though freetype is not the very latest version(2.4.4), the whole thing builds just fine.

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  :o

Console.app shows the following output:

Quote

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

Title: Re: SFML Mac Portability
Post by: Ceylo on June 10, 2012, 04:20:33 pm

What does

Code: [Select]

otool -L /Users/test/Library/Developer/Xcode/DerivedData/test-evmgfzadndoehnbskpupqrhdfnbb/Build/Products/Debug/test.app/Contents/MacOS/testgives you ?

Title: Re: SFML Mac Portability
Post by: capz on June 13, 2012, 09:38:54 pm

Quote from: Ceylo on June 10, 2012, 04:20:33 pm

What does

Code: [Select]

otool -L /Users/test/Library/Developer/Xcode/DerivedData/test-evmgfzadndoehnbskpupqrhdfnbb/Build/Products/Debug/test.app/Contents/MacOS/testgives you ?

Virtual-Mac:~ test$ otool -L /Users/test/Library/Developer/Xcode/DerivedData/test-evmgfzadndoehnbskpupqrhdfnbb/Build/Products/Debug/test.app/Contents/MacOS/test
/Users/test/Library/Developer/Xcode/DerivedData/test-evmgfzadndoehnbskpupqrhdfnbb/Build/Products/Debug/test.app/Contents/MacOS/test:
        /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 833.24.0)
        @executable_path/../Frameworks/sfml-audio.framework/Versions/2.0.0/sfml-audio (compatibility version 2.0.0, current version 2.0.0)
        @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-network.framework/Versions/2.0.0/sfml-network (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/sfml-window.framework/Versions/2.0.0/sfml-window (compatibility version 2.0.0, current version 2.0.0)
        @executable_path/../Frameworks/SFML.framework/Versions/2.0.0/SFML (compatibility version 0.0.0, current version 0.0.0)
        @executable_path/../Frameworks/sndfile.framework/Versions/A/sndfile (compatibility version 2.0.0, current version 2.24.0)
        /usr/X11/lib/libfreetype.6.dylib (compatibility version 14.0.0, current version 14.2.0)
        /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
        /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
        /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 635.19.0)
 

:P

Title: Re: SFML Mac Portability
Post by: Ceylo on June 13, 2012, 09:49:03 pm

Quote from: capz on June 10, 2012, 01:27:39 am

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  :o

Console.app shows the following output:

Quote

/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.

Title: Re: SFML Mac Portability
Post by: Hiura on June 14, 2012, 09:54:06 am

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.)

Title: Re: SFML Mac Portability
Post by: capz on June 14, 2012, 04:30:05 pm

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 :o

Title: Re: SFML Mac Portability
Post by: Bocaj on June 15, 2012, 01:57:41 am

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?

Title: Re: SFML Mac Portability
Post by: Hiura on June 15, 2012, 10:58:48 am

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.

Title: Re: SFML Mac Portability
Post by: capz on June 17, 2012, 10:41:53 pm

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 (http://www.kyngchaos.com/software/frameworks)

Title: Re: SFML Mac Portability
Post by: Hiura on June 17, 2012, 10:48:48 pm

Thanks for the link.  :)

Title: Re: SFML Mac Portability
Post by: eigen on June 18, 2012, 02:21:56 pm

Quote

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 :(

Title: Re: SFML Mac Portability
Post by: Ceylo on June 18, 2012, 03:37:38 pm

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

Title: Re: SFML Mac Portability
Post by: eigen on June 18, 2012, 06:59:44 pm

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.

Title: Re: SFML Mac Portability
Post by: Ceylo on June 18, 2012, 07:02:18 pm

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

Title: Re: SFML Mac Portability
Post by: eigen on June 19, 2012, 09:49:17 am

Thanks, it seems to be working now :)

Title: Re: SFML Mac Portability
Post by: Hiura on June 19, 2012, 01:24:19 pm

I've summed up this issue here (https://github.com/SFML/SFML/issues/241). Let me know if I've missed something.