SFML community forums
Help => General => Topic started by: antto on October 06, 2011, 08:52:22 am
-
hello
while building the sfml-graphics lib (release static_win32)
got this error in: include\SFML\System\ResourcePtr.inl
i suppose NULL should have a value of 0
can i just #define NULL 0
or is it too dirty?
-
#include <cstddef> before any SFML header.
-
hi Laurent, thanks for the fast respons
now, i'm not sure where exactly i should include cstddef
i tryied two things:
1) in a dirty way defined NULL 0 in the ResourcePtr.inl
2) in the same directory in Resource.hpp added #include <cstddef> before the line where Resource.inl and ResourcePtr.inl are included
both lead to the same result
d:\toolz\codeblocks8\mingw\bin\..\lib\gcc\mingw32\4.6.1\..\..\..\..\include\wchar.h|105|error: 'size_t' has not been declared|
:?
-
Include it in your own code, before any #include <SFML/Xxx.hpp> that you have.
-
i have this error while trying to build the lib itself
i haven't yet got to the point of using SFML in my own project
downloaded the "full sdk 1.6 for windows and codeblocks / mingw" .zip from the website
then unzipped it, and went to the build directory
from there i opened each .cbp project file one by one and build the Release Static_win32 target
window built fine
system too
main too
(so i got 3 libs in SFML\lib\mingw\ (lib***.a))
but got this problem while building the graphics lib
correct me if i'm wrong
i thought i have to build all the libs before i can use SFML
i want to use static linking (no dll)
-
i thought i have to build all the libs before i can use SFML
Why?
Official releases contain precompiled binaries.
-
ah, ok ;]
i'm still kinda new to all this ;]
-
i thought i have to build all the libs before i can use SFML
Why?
Official releases contain precompiled binaries.
I have downloaded the source aswell since I wish to build SFML as a static library and the OP is right there is some problem with building from source in reference to NULL not being declared. As to your "Why?" response shouldnt the library be built first and linked second (like every other library I have used) your answer just doesn't make sense to me, I dont wish to compile my app with the whole source of sfml each time thats obsurd even with a makefile this still seems excessive and whats the point of shared libraries if the source of the library needs to be linked in at compile time? or am I missing something really obvious.
-
I have downloaded the source aswell since I wish to build SFML as a static library
Static libraries don't make sense on Linux. And on Windows, static builds are provided directly in the downloadable SDKs.
So basically there's no good reason for building SFML static libs yourself.
As to your "Why?" response shouldnt the library be built first and linked second (like every other library I have used) your answer just doesn't make sense to me, I dont wish to compile my app with the whole source of sfml each time thats obsurd even with a makefile this still seems excessive and whats the point of shared libraries if the source of the library needs to be linked in at compile time? or am I missing something really obvious.
I just said that compiling SFML is not necessary because it's already compiled in the downloadable SDKs. I didn't mean that you should include SFML sources in your app, that wouldn't make sense at all.
-
Laurent,
This is my first post here. I want to congratulate you on an incredible framework. However, there is a great reason to compile from source. If you use the precompiled libs, you have to use GCC 4.4. If you want to use some new C++ 11 features you will have to move up and/or if you just want to move up to GCC 4.7.1 you will have to recompile from source. Why? Because the ABI is not 100% compatible. I tried it without recompiling the libraries and got some fatal crashes.
I fixed the null problem by just inserting
#include <cstddef> into your .cpp file, and it worked great.
However, I am now having some more problems, but not really with your code, but in wchar.h. It says that size_t is not defined. I'm pretty sure this is a C++11 / C++98 incompatibility but if you have any insight, I would be greatly appreciative. Thanks.
-Dave Ottley
-
You are aware that you answered to an over one year old thread and that Code::Blocks in the meantime is at version 12.11 and if chosen ships with TDM-GCC 4.7.1?
If not, now you know it and the whole problem doesn't exist anymore. :D
-
It should be noted that this problem still exists in its original form. I solved it by including
#include <cstddef>
in every .cpp (it is VERY important not to do this in the .hpp files) for which the NULL error was generated. I hope this will be of some help to some newbies out there somewhere, someday.
-Dave Ottley
-
Note as well that this problem doesn't occur in version 10.0, so it's pretty much useless by now.
If you wish to help you can choose fresher topics, since these old ones are either left unresolved for over a year (maybe even resolved, just not outright stated) or have already been clearly resolved ages ago, not to mention that thread necromancing isn't exactly right in most forums.