Author Topic: [C++/OSX]two bugs/issues, locale and assets (Read 7434 times)

andyj · « **on:** January 08, 2009, 01:08:45 pm »

OS: Mac OS X 10.5.5 Intel
SFML version : 1.4 final
I got the full SDK from the website and tried to run the examples.
For the .app based samples, I was getting errors even if I had copied the frameworks to /Library/Frameworks.

The first thing I noticed when I opened the Terminal and moved into the bin directory and opened the apps was this error : locale::facet::_S_create_c_locale name not valid .

That was the second problem, the first one was that it couldn't find the data from the "datas" folder, which I solved by moving into the bin directory and ran the samples apps (e.g. opengl.app/Contents/MacOS/opengl).

This could probably be fixed by getting the path of the executable from within the binary files and storing the required files in .app/Contents/Resources/.

I recompiled SFML in release mode and the samples, the result was the same.

Any ideas on how I could fix the locale problem?

andyj · « **Reply #1 on:** January 09, 2009, 12:08:10 am »

Here I am answering to my own post, hehe.
Starting the offending apps with LC_ALL="C" opengl.app/Contents/MacOS/opengl seems to work.
Therefore, it seems it's a locale related problem.

Here you can find more pieces of information.

I hope this can be fixed easily.

Ceylo · « **Reply #2 on:** January 09, 2009, 02:33:12 am »

Really interesting...

And thought I had already been noticing this issue, I could not figure out why it was happening. Your idea sounds useful.

I'mma talk to Laurent about it, thanks !

Quote from: "andyj"

That was the second problem, the first one was that it couldn't find the data from the "datas" folder, which I solved by moving into the bin directory and ran the samples apps (e.g. opengl.app/Contents/MacOS/opengl).

This could probably be fixed by getting the path of the executable from within the binary files and storing the required files in .app/Contents/Resources/.

Storing the files in the Resources folder won't change anything. When launching the application from the Finder, the "current working directory" is set to /. Therefore, the app won't be able to load the resource files until you put them in the root directory (I admit this is quite annoying...). The solution would be to change the working directory. But... why, why not ?

I talked a little bit about this to Laurent, because it's a Mac OS X issue (I don't know what's the behaving with Linux), and the final conclusion was that "it's the SFML user's work". The main argument is that if SFML does the setting for the user, his would be overwritten, which is unconvenient.

We can talk hours about it, and I'm still not sure what is to be done, that's why I did nothing to fix this.

By the way, I saw you wrote at 1 PM (GMT +1), which means you downloaded the first archive version, a corrupted one (there were broken links in the frameworks). You won't be able to build any SFML application with the provided frameworks until you download the archive again (but actually sound to have built them yourself...).

andyj · « **Reply #3 on:** January 09, 2009, 08:24:04 am »

The issue was the same even with the DMG. I have rebuilt even the SFML source from the second package, the DMG, because I thought there may have been some kind of incompatibility (e.g. compiled with an older XCode on 10.4, etc).

What I said was to take the arguments which get passed to the app, that means the first argument which is the path to the binary, remove the name of the binary and the MacOS part and you've got a clean path to "[...].app/Contents/". What happens from now on is pretty obvious, you add Resources/res to the path, where res is a file you want to load from the Resources directory.

SFML could have something which does this, like: getAppResPath and the user could use it or create his own code.

Ceylo · « **Reply #4 on:** January 09, 2009, 09:24:46 pm »

The .dmg file does not fix any SFML bug. The frameworks were just malformed.

And.. your solution is... heavy.
If you want the user to use argv, let him at least set the working directory correctly rather than annoying him with an absolute path.

I can get the program path without forcing the user to give me the main() function arguments, this is not a problem. The point is rather choosing to do it or not.

I think I'll actually set the just working directory to the Resources folder at SFML initialization. Let me think about it a few more days (or weeks

, anyway the 1.5 release is far away).

andyj · « **Reply #5 on:** January 10, 2009, 01:30:02 am »

Quote from: "Ceylo"

The .dmg file does not fix any SFML bug. The frameworks were just malformed.

And.. your solution is... heavy.
If you want the user to use argv, let him at least set the working directory correctly rather than annoying him with an absolute path.

I can get the program path without forcing the user to give me the main() function arguments, this is not a problem. The point is rather choosing to do it or not.

I think I'll actually set the just working directory to the Resources folder at SFML initialization. Let me think about it a few more days (or weeks , anyway the 1.5 release is far away).

I noticed it was repackaged. It made sense to me to check again (because it might have had something which fixed the distribution, not modified code) and see what happens.

My solution was pretty much of a fix I thought of a while ago and I'd love to read how you'd tackle the problem.This means that I'd like to compile some SFML apps for OS X before SFML 1.5 gets out.

Ceylo · « **Reply #6 on:** January 10, 2009, 02:03:51 pm »

Quote from: "andyj"

I'd love to read how you'd tackle the problem.

I'd set the right working directory with chdir(). Then you could read files with paths relative to the resources folder.

Quote from: "andyj"

This means that I'd like to compile some SFML apps for OS X before SFML 1.5 gets out.

Ok ^^.

andyj · « **Reply #7 on:** January 11, 2009, 04:44:46 pm »

That's ok too, I was wondering how you would get rid of the args.
Anyway, it seems that the issue with the locales is fixed in the SVN. Maybe there will be a 1.4.1 maintenance release?

Ceylo · « **Reply #8 on:** January 11, 2009, 05:29:06 pm »

Yep, there will. Too much annoying points in the current version.

Ceylo · « **Reply #9 on:** January 12, 2009, 02:10:03 pm »

Andyj, could you try out SFML with the latest SVN version ?

Type this in the Terminal application to get the files :

Code: [Select]

svn cp https://sfml.svn.sourceforge.net/svnroot/sfml

andyj · « **Reply #10 on:** January 12, 2009, 02:43:06 pm »

Yes, I will try it in a few minutes and I'll update this post.

P.S.: Judging by the SVN changes, I can see that some bugs were fixed, including the locale bug. It should all be fine.

Update: I tested revision 984. I compiled SFML Frameworks in Release mode and the samples in Release mode. They worked, the locale error is gone.
Obviously, it still needs the CWD to be the bin directory and a manual execution via opengl.app/Contents/MacOS/opengl in terminal.

Ceylo · « **Reply #11 on:** January 12, 2009, 04:11:04 pm »

The working directory is set to the Resources folder when using a bundled application, or the directory containing the executable otherwise.

I think it's better do to the Mac OS X way (that is having all the resources in the bundle) than trying to just follow the Windows one, but of course this prevents the samples from working fine (maybe symbolic links in the Resources directory pointing to the datas folder would do the trick).

Edit: using symbolic links works fine. I added a shell script to make them when building with Xcode. I'll send the changes soon.

andyj · « **Reply #12 on:** January 12, 2009, 04:19:54 pm »

I see, adding a symbollic link should be ok. I thought they weren't loaded even if they were in the Resources folder.
I'm glad this is fixed, I will be watching the SVN revisions to see what pops up in there for the re-release.

Ceylo · « **Reply #13 on:** January 12, 2009, 04:37:10 pm »

Everything we talked about here should now be fixed.

Could you also have a look at this topic and check whether it's working for you ? http://www.sfml-dev.org/forum/viewtopic.php?p=5846#5846

andyj · « **Reply #14 on:** January 12, 2009, 06:46:59 pm »

Yes, it's working. I tested pong on OS X and it had the same sounds.

Like I said, I rebuilt the samples and the frameworks from the new SVN revision (obviously, I deleted the ones I had in the Frameworks directory from Library and replaced them with these).

He may have an older XCode and/or an older OS X version. I was using 10.5.5 with XCode 3.1.