Unofficial Nightly Builds

[eXpl0it3r]

I'm sorry, I've no idea on Mac development, but you might want to create a topic of your own, write a comment on the blog post or ask the creator of the OS X builds directly, his name is Cornstalks.
With a topic of your own, the OS X dev of SFML might answer as well. Also make sure to search the forum first.

[Cornstalks]

I followed the tutorial here http://www.mjbshaw.com/2013/02/building-sfml-2-with-c11-on-os-x.html and it almost worked, except when I launch the Xcode Template "SFML App" I have a build error saying:

ditto: can't get real path for source
couldn't copy /Library/Frameworks/freetype.framework to /Users/vanpet/Library/Developer/Xcode/DerivedData/engine-aflrprlylygpwtcgjaleylrwvizo/Build/Products/Debug/engine.app/Contents/Frameworks/freetype.framework
Command /bin/sh failed with exit code 2

Any idea what is happening?

Heh, I just saw your comment on my blog and just responded to it this morning. Good news is, I just got my computer back today so I can work on this.

I'd recommend possibly starting a new thread, as this is more about building SFML than using some pre-built binaires. Or you can respond on my blog. Either way, I'll see what you write and respond

[santiaboy]

Hey, I downloaded the last nightly build (Latest (2013-03-15) [5c46daacd4]) and I have a question.

Has font::getDefaultFont() been erased? I can't seem to be able to use it, and so if I don't have a font of my own every text is 0 width, 0 height and doesn't display for some reason

[FRex]

Has font::getDefaultFont() been erased?

YES, ages ago.

[eXpl0it3r]

Has font::getDefaultFont() been erased?

Yes as stated by FRex it was removed, due to various problems. You'll now always have to provide a font, otherwise nothing will be shown.

[santiaboy]

Thanks, I was becoming crazy due to nothing appearing on screen. Also, I used to call setFont AFTER setPosition, which made everything be more to the right than it should be.

Do you know if when SFML 2 finally releases (the 2.0 not the RC) do I have to compile it again or it would be like this nightly builds or will I have to use CMake?

[eXpl0it3r]

Do you know if when SFML 2 finally releases (the 2.0 not the RC) do I have to compile it again or it would be like this nightly builds or will I have to use CMake?

When SFML 2.0 gets completetly released, it will get compiled for all the major compilers, similar to my nightly builds, so you can download it once and keep working with a stable build, until a new version gets released.

But since SFML's development, won't be shutting down and will constantly get a bit more advanced than the stable build, I'll be still maintaining these nightly builds.

[santiaboy]

Sweet. Thanks for making this job of uploading the nightly builds!

[eXpl0it3r]

Sweet. Thanks for making this job of uploading the nightly builds!

You're welcome!

[santiaboy]

Sorry to bother you again, but this is the first time I updated SFML since I downloaded RC

I downloaded [5c46daacd4] MinGW TDM GCC 4.7.1 32bit version, and everything went OK. However, when I try to run the .exe outside code::blocks, there's an error requesting "libgcc_s_sjlj-1.dll", "libstdc++-6.dll", which I never needed before. I have them on my code::blocks folder. I know that I have to copy them to the folder or link them statically, so the question is this: Why do I need to do this now when I never needed before? Does it means I made some kind of error while trying to update?

[eXpl0it3r]

Sorry to bother you again

No problem!

So you're using Code::Blocks 12.11 with the compiler MinGW TDM, right?
What have you been using before?

Does it means I made some kind of error while trying to update?

No everything is fine, in theory it's a bad SFML RC build, since it apparently links the runtime library statically for the dynamic builds...

Why do I need to do this now when I never needed before?

The problem is, that the MinGW TDM builds link the runtime library statically by default and only when asked shared, thus the build CMake build script (and many other build scripts) "break" with the MinGW TDM compiler. For my nightly builds I use a work around to build them properly, thus all the SFML libraries located in directly in the lib/ folder link dynamically against the runtime library and only the static libraries within the lib/static-std/ folder link statically against the runtime library.
So you now either have to decide between:

• Dynamic SFML & runtime libraries
• Static SFML and dynamic runtime libraries
• Static SFML & runtime libraries

For the first one you just link against the lib/sfml-XYZ(-d).a files and add -shared-libstdc++ and -shared-libgcc to the "Other linker options" in the project settings.
For the second one you link against the lib/sfml-XYZ-s(-d).a files and add -shared-libstdc++ and -shared-libgcc to the "Other linker options" in the project settings.
For the third one you only link against the lib/static-std/sfml-XYZ-s(-d).a files.

Keep in mind, that this applies only to the TDM builds of MinGW, all the other MinGW builds I've seen use the standard way of linking the runtime libraries, that is shared by default and only when specified -static-libstdc++ and -static-libgcc statically.

I hope that wasn't too confusing, it's just a bad decision of guy building the MinGW TDM versions...

[santiaboy]

Sorry to bother you again

No problem!

So you're using Code::Blocks 12.11 with the compiler MinGW TDM, right?
What have you been using before?

Code::Blocks 10.05 with the GCC compiler and GDB debugger from MinGW.

Big explanation

Before I had to include the SFML dll, and none of the other 2 ("libgcc_s_sjlj-1.dll", "libstdc++-6.dll") , but I didn't need to add anything to other linked options. I guess I'll go with Dynamic SFML & runtime libraries, adding the 2 dll to the folder isn't enought reason to downgrade code::blocks to 10.05 haha

Thanks for the explanation!

[eXpl0it3r]

Before I had to include the SFML dll, and none of the other 2 ("libgcc_s_sjlj-1.dll", "libstdc++-6.dll") , but I didn't need to add anything to other linked options. I guess I'll go with Dynamic SFML & runtime libraries, adding the 2 dll to the folder isn't enought reason to downgrade code::blocks to 10.05 haha

Well I guess you didn't really get it...

The problem is not with Code::Blocks and if you're really still using v10.05, then I advise you to update.

The SFML 2.0 RC for the TDM compiler, are wrongly built and thus you didn't need the runtime libraries. My binaries are correctly built and thus you need the runtime libraries when linking dynamically.
SFML CMake settings essentially don't allow linking the runtime library static, while the SFML libraries being dynamic, so the only way to get the runtime library linked statically, you'll also have to link SFML statically.

Hmmm maybe I should try to fix the CMake script for the TDM builds or at least open another bug report, then again, it's already too late for SFML 2.0...

[eXpl0it3r]

Believe it or not, but the Unofficial Nightly Builds are back!

Updated the SFML and Thor builds to the latest commit. Removed the rubenvb version and added the MinGW Builds 32 & 64 bit, plus the nuwen.net version.

As always the packages include all possible builds (shared/static/static runtime lib, debug/release) with the fully generated documentation and completely statically build examples.
Enjoy and let me know your thoughts and ideas!

[xylr117z4]

Thanks for keeping this up-to-date.  I had cMake configured a long time ago but I've since upgraded to a new PC and I don't really remember how to do that so this is much much easier.