I've looked into compiling SFML statically but it fails, i've tried rebuilding SFML statically, but it still fails, I've tried using the workarounds explained elsewhere, which kinda works, but still fails.
...
Please is there a possible fix, or an easy way to link against SFML statically that actually works? Just adding -s after the -lsfml-XXX doesn't want to work.
Wow, dude... if you think all you need to do is add -s after the -lsfml-XXX without successfully building as a static library you have a lot to learn. I'd look into why it fails building in the first place before trying to use it somewhere else. Saying it fails and not describing how it fails isn't going to help much.
Everybody can get SFML to compile statically no matter whether they are a beginner or an advanced programmer. They just need to spend enough time figuring out how to. Static linking is in fact even easier to achieve and use than dynamic linking.
There are probably around one-hundred (100) topics showing this same error, yet no one can answer their questions or provide a way to fix their problems.
Then those 100 topic starters obviously don't know how to do a bit of research before asking the exact same question. The answer is on these forums, and no there is no way to prevent it, just to work around it. Static link or don't use the default font. There is no fix to it, not yet at least. It's that simple.
The ATI/AMD driver implementation on windows obviously displays "non-standard" behavior. Whether the crash is a result of programmer error/false assumptions on the side of SFML or really just a glitchy driver implementation, nobody knows. I put my money on the former. Wgl is known to be poorly documented, so I can't really blame Laurent. I do know however that there are many other open source games out there that use Wgl/OpenGL in almost exactly the same way as SFML and they don't crash on exit on ATI/AMD cards which further supports my previous statement.
Unless you can come up with a fix for this, I would recommend sticking to the workarounds and hope that Laurent fixes it sometime in the foreseeable future. And just so that you know, this issue is also present in SFML 2.0, so upgrading won't make it magically disappear.