I downloaded the Linux copy not the source
Just for fun, could you try with a custom built SFML from source?
I just made sure everything was linked correctly in code::blocks an still same results.
Are you sure you don't have multiple copies of SFML installed?
Like, one from your distributions repositories + the one you downloaded? I'm thinking of issues where you use header files from one version but link against another or even at runtime the dynamic linker (ld.so) finds a third. Stuff like that can sometimes drive you crazy ;-)
I only asked if it was the operating system because as I stated when I was searching the forums for a thread with my problem someone had the same code on Linux and windows and windows worked and Linux had the segfault.
There can be a ton of reasons for that.
Your code may contain undefined behaviour that only causes a crash on some systems (but is of course a bug none-the-less).
I recommend reading these articles if you are not familiar with the concept of "undefined behaviour" (or even if you are; they are great reads regardless of your level of experience):
What Every C Programmer Should Know About Undefined Behavior #1/3 What Every C Programmer Should Know About Undefined Behavior #2/3 What Every C Programmer Should Know About Undefined Behavior #3/3 A Guide to Undefined Behavior in C and C++, Part 1 A Guide to Undefined Behavior in C and C++, Part 2 A Guide to Undefined Behavior in C and C++, Part 3Your code may depend on implementation defined behaviour that then leads to different results when building with different compilers (example: I recently had to debug a problem that eventually turned out to be the code depending on the order of evaluation of function arguments (which is implementation defined) - Visual C++ and GCC evaluate from right to left and the code worked, clang evaluates from left to right and the code broke - both evaluation orders are perfectly fine, what was not fine was the code depending on it).
Your code may be just fine but run into resource limits on one system but not another.
You may not notice that the code "crashes" on one platform but may notice on another. Say for example that your Windows machine is not configured to generate minidumps on crashes but will just silently terminate the program while your Linux machine is configured to generate a core on crashes - so you'd notice more distinctly one one than the other.
Etc, etc etc.
I read somewhere that it may very well be Linux, not the operating system itself but their graphics driver isn't really the best as far as I read.
Driver quality varies
a lot that's true. And sometimes the OpenGL drivers are responsible for app crashes; but I'd say it shouldn't be the first place to look for issues. When that's said though, NVidia tends to provide quite solid drivers in my experience and Intel's drivers are usually not bad either - AMD/ATI drivers are a bit more questionable (in my experience). If you are using Mesa and software rendering, that's a whole different kettle of fish, but the latest 10.x drivers seem to work reasonably well (although performance is of course nowhere near hardware accelerated levels).
In any case, upgrading to the latest stable drivers for your card is usually always a good idea.
I tried getting the core dump, it worked but now I cant do it again, I will mess with it more tomorrow and post my core dump.
Hint:
ulimit -c unlimitedDon't bother posting your dump. It's useless without the executable that generated it. Just debug it locally (hint: learn to use gdb) or just re-run the app through the debugger - just run
gdb app and then type "run" - it'll stop when it crashes and the "bt" command will get you a backtrace - google for gdb tutorials for more.
You guys also forgot something: my code won't compile! I have to buy a new computer and try again 
Luckily, that one is rather uncommon.
