SFGUI (0.4.0 released)

[Tank]

Updated to SFML's new naming conventions. Nightly builds will follow.

[Mars_999]

Thanks for the heads up!!!

[Meteorhead]

Hi!

I have read through the forum from the point on where crashes were mentioned at the end of applications, however no solution was mentioned, or the attempt to have it fixed. Is there anything to do to fix it from an end-user POV, such as myself? If I took it correctly staticly linked libs could do the tricks, but that is less elegant.

[binary1248]

That depends on what kind of crash you mean. If you mean the GetDefaultFont() crash then the only way is to static link (this goes for any SFML project btw). If you mean the crash while static linking, then you have to grab the latest master and look at the usage of the SFGUI sfgui; guard variable. It is our current workaround for SFML's intolerance for OpenGL resources in static objects.

[Meteorhead]

I am talking about the crash, that happens when closing the application. I create an sf::Text object to draw an FPS counter which I keep updating with an instance of sf::String and when the application closes, it segfaults. All SFGUI samples behave this way, although I pulled master from both SFML and SFGUI just yesterday. Is there anything to do about this? I do not recall using getDefaultFont, but it might just occur that this function runs somewhere if I do not specify a specific font anywhere else.

[Tank]

BREW (the default rendering engine) uses getDefaultFont() if no other fonts are specified.

To avoid the crash build and link statically on Windows, both SFML and SFGUI.

[Meteorhead]

For some reason I cannot build SFGUI statically, neither can I build an SFML application using the statically built SFML libs that used to work before with the dynamic variants.

Using dynamic libraries, everything was fine. Tank suggested to build and link both SFML and SFGUI statically. Most likely the mistake is on my part, but when I try to build the same project that used to work with DLLs (SFML only just yet), even though I updated lib names in the "Linker->Input" property part to be:

sfml-main.lib;sfml-system-s.lib;sfml-window-s.lib;sfml-graphics-s.lib;opengl32.lib;glu32.lib;GLEW64.lib;%(AdditionalDependencies)"

when I compile my program it gives heaps of undefined external symbols looking like:

1>------ Build started: Project: SFML_GL_test, Configuration: Release x64 ------
1>Build started 2012.04.04. 16:39:30.
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(299,5): warning MSB8004: Output Directory does not end with a trailing slash.  This build instance will add the slash as it is required to allow proper evaluation of the Output Directory.
1>InitializeBuildStatus:
1>  Touching "x64\Release\SFML_GL_test.unsuccessfulbuild".
1>ClCompile:
1>  main.cpp
1>msvcrt.lib(ti_inst.obj) : error LNK2005: "private: __cdecl type_info::type_info(class type_info const &)" (??0type_info@@AEAA@AEBV0@@Z) already defined in LIBCMT.lib(typinfo.obj)
1>msvcrt.lib(ti_inst.obj) : error LNK2005: "private: class type_info & __cdecl type_info::operator=(class type_info const &)" (??4type_info@@AEAAAEAV0@AEBV0@@Z) already defined in LIBCMT.lib(typinfo.obj)
1>LIBCMT.lib(crt0init.obj) : warning LNK4098: defaultlib 'msvcrt.lib' conflicts with use of other libs; use /NODEFAULTLIB:library
1>main.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual class sf::Vector2<unsigned int> __cdecl sf::RenderWindow::getSize(void)const " (__imp_?getSize@RenderWindow@sf@@UEBA?AV?$Vector2@I@2@XZ)
1>main.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __cdecl sf::RenderWindow::~RenderWindow(void)" (__imp_??1RenderWindow@sf@@UEAA@XZ)
1>main.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __cdecl sf::RenderWindow::RenderWindow(class sf::VideoMode,class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &,unsigned int,struct sf::ContextSettings const &)" (__imp_??0RenderWindow@sf@@QEAA@VVideoMode@1@AEBV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@IAEBUContextSettings@1@@Z)
1>main.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __cdecl sf::View::View(class sf::Rect<float> const &)" (__imp_??0View@sf@@QEAA@AEBV?$Rect@M@1@@Z)

When I try to build SFGUI to make static libraries, I get the following in nmake:

Linking CXX static library lib\sfgui-s.lib
[ 84%] Built target sfgui
[ 85%] Building CXX object examples/CMakeFiles/Box.dir/Box.cpp.obj
Box.cpp
NMAKE : fatal error U1073: don't know how to make 'C:\Kellekek\SFML\lib\sfml-gra
phics.lib'
Stop.
NMAKE : fatal error U1077: '"C:\Kellekek\Microsoft Visual Studio 10.0\VC\BIN\amd
64\nmake.exe"' : return code '0x2'
Stop.

I don't know why is it looking for sfml-graphics.lib when I told it in cmake that SFML was built statically, so I would think it should be looking for sfml-graphics-s.lib (which exists as expected in it's intended install location) Can someone tell me where I am going wrong?

Thank you for the help in advance,
Máté

[eXpl0it3r]

Make sure you do define SFML_STATIC and I think it's the same for SFGUI: SFGUI_STATIC
CMake should define those on its own, but maybe the CMake file is faulty.

[Meteorhead]

I defined SFML_STATIC ahead of all includes, then there were lots of conflicting "already defined in..." messages. I had to use "Ignore Spcific Default Libraries" in "Linker->Input" by removing those responsible for conflicting defines:

MSVCRT;MSVCPRT

Plus I had to remove GLEW64.lib as a required input, as it was conflicting with sfml-graphics-s.lib. Now I only got a few unresolved external symbols, namely:


1>  main.cpp
1>sfml-system-s.lib(String.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: static unsigned __int64 __cdecl std::ctype<wchar_t>::_Getcat(class std::locale::facet const * *,class std::locale const *)" (__imp_?_Getcat@?$ctype@_W@std@@SA_KPEAPEBVfacet@locale@2@PEBV42@@Z)
1>sfml-system-s.lib(String.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: wchar_t __cdecl std::ctype<wchar_t>::widen(char)const " (__imp_?widen@?$ctype@_W@std@@QEBA_WD@Z)
1>sfml-system-s.lib(String.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: char __cdecl std::ctype<wchar_t>::narrow(wchar_t,char)const " (__imp_?narrow@?$ctype@_W@std@@QEBAD_WD@Z)
1>sfml-window-s.lib(WindowImpl.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: __cdecl std::_Container_base12::~_Container_base12(void)" (__imp_??1_Container_base12@std@@QEAA@XZ)
1>sfml-graphics-s.lib(Shader.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class std::basic_istream<char,struct std::char_traits<char> > & __cdecl std::basic_istream<char,struct std::char_traits<char> >::read(char *,__int64)" (__imp_?read@?$basic_istream@DU?$char_traits@D@std@@@std@@QEAAAEAV12@PEAD_J@Z)
1>sfml-graphics-s.lib(Shader.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class std::fpos<int> __cdecl std::basic_istream<char,struct std::char_traits<char> >::tellg(void)" (__imp_?tellg@?$basic_istream@DU?$char_traits@D@std@@@std@@QEAA?AV?$fpos@H@2@XZ)
1>sfml-graphics-s.lib(Shader.cpp.obj) : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class std::basic_istream<char,struct std::char_traits<char> > & __cdecl std::basic_istream<char,struct std::char_traits<char> >::seekg(__int64,int)" (__imp_?seekg@?$basic_istream@DU?$char_traits@D@std@@@std@@QEAAAEAV12@_JH@Z)
1>sfml-graphics-s.lib(ImageLoader.cpp.obj) : error LNK2001: unresolved external symbol __imp_ldexp
1>D:\ToBeSaved\Develop\SFML_GL_test\\bin\SFML_GL_test.exe : fatal error LNK1120: 8 unresolved externals
1>
1>Build FAILED.

Any ideas how to resolve this last issue?

ps.: am I really that underschooled using static linking (I'm not a big fan of it, neither on windows or linux) or are things really that buggy? I figured it would take 5 minutes top to change cmake config, rebuild libs and change project properties, but I have been messing with it for hours now.

[eXpl0it3r]

I defined SFML_STATIC ahead of all includes, then there were lots of conflicting "already defined in..." messages.

I'd say this is not the right approach.
I asume you're using Visual Studio, so there's an option under Project->[ProjectName]-Preferences->C/C++->Preprocessor->Preprocessor definitions
You should provide SFML_STATIC there.

Did you check the STATIC_STD_LIBS in the CMake configuration?
If so please make sure you're using the right standard libraries in your project.

And keep in mind do not mix debug and release libraries vs debug and release build modes!

am I really that underschooled using static linking (I'm not a big fan of it, neither on windows or linux) or are things really that buggy? I figured it would take 5 minutes top to change cmake config, rebuild libs and change project properties, but I have been messing with it for hours now.

One can not know everything and it takes its time to figure out how to build it.
Its pretty easy for me to build them, just uncheck BUILD_SHARED_LIBS (check STATIC_STD_LIBS if you want to use static standard libs), generate and build.

If you're not a fan of static libs why do you use them?

[Meteorhead]

If you read back a bit, then you'll see it's neccessary because SFGUI crashes on every application exit because of an issue that arises due to the way libs unload. Static linking can solve the issue.

[binary1248]

When you get "already defined in..." messages regarding functions from the C runtime you shouldn't automatically choose to ignore specific libraries, otherwise the symbols won't be imported and you get errors such as in your second post. Most of the time the reason for "already defined in..." is actually that you are importing/using the wrong version of the C runtime somewhere in your build process.

See: http://msdn.microsoft.com/en-us/library/abx4dbyh%28v=vs.100%29.aspx

ps.: am I really that underschooled using static linking (I'm not a big fan of it, neither on windows or linux) or are things really that buggy? I figured it would take 5 minutes top to change cmake config, rebuild libs and change project properties, but I have been messing with it for hours now.

Normally it should take only 5 minutes. It's a matter of determining how SFML was built (among other things if it uses static or dynamic C runtime), replicating those settings in the SFGUI CMake configuration and building SFGUI. Using different link settings ANYWHERE in your project (not only building SFML or SFGUI) will probably cause errors. Static linking is not any more complicated than dynamic linking is and you should be able to keep with the procedure you would go through to link dynamically too. The only thing I wouldn't touch is STATIC_STD_LIBS, neither in SFML nor SFGUI. MSVC doesn't really like it when you static link the runtime.

Plus I had to remove GLEW64.lib as a required input, as it was conflicting with sfml-graphics-s.lib.

Maybe Laurent should make it more obvious that GLEW is already included in sfml-graphics-s.lib.

[eXpl0it3r]

When you get "already defined in..." messages regarding functions from the C runtime you shouldn't automatically choose to ignore specific libraries, otherwise the symbols won't be imported and you get errors such as in your second post. Most of the time the reason for "already defined in..." is actually that you are importing/using the wrong version of the C runtime somewhere in your build process.

Well it's true that one has to be carefull about this, but it's true that MSVC complains a lot about the diffrent versions of the standard library, I think specially if you link them statically. Mostly they are just warnings though and the libs and the application will run without problems. So you end up excluding all the libs you actually don't want and VS strangly still includes.
For the diffrent libraries see http://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.80).aspx

The only thing I wouldn't touch is STATIC_STD_LIBS, neither in SFML nor SFGUI. MSVC doesn't really like it when you static link the runtime.

I haven't experienced any other problems as the ones above but it still isn't such a good idea.

[Nexus]

Hi, I clicked the thread and saw something on the first page

Using shared_ptr directly is a good solution, unfortunately it appears as such in the docs. Not a big deal, but I'd prefer the consistent "Ptr"/"PtrConst" style.

In Aurora, I've written a macro

#define AURORA_FAKE_DOC(real, fake) real

In doxygen, you define it as fake. With it, you let something else appear in the documentation than in the code. It's also useful for implementation-defined and complicated types of which the details are irrelevant to the user.

I know it's ugly, but I think it's the only solution to have both a clean documentation and no unnecessary header dependencies.

[Tank]

Meteorhead:
I guess you're doing everything correctly, just one little step you must be aware of: When you build SFGUI with dynamic linkage, the FindSFML script looks for the dynamic libraries and stores them in SFML_*_LIBRARY_DEBUG/RELEASE variables. If you now decide to link against static libraries and check "SFML_STATIC_LIBRARIES", FindSFML won't update those variables.

So when changing SFML_STATIC_LIBRARIES, make sure to delete all SFML_*_LIBRARY_* variables so they're re-initialized. The same goes for FindSFGUI in case you're using it.

The way the whole process works best is to open CMake GUI (if you're using it, otherwise do the equivalent on the CLI) with a fresh and uninitialized environment (e.g. empty 'build' directory), add and set the variables first (that is: SFML_STATIC_LIBRARIES, BUILD_SHARED_LIBS) and then configure & generate.

If you, Laurent, are reading this: I'd suggest to add a variable that tracks the content of SFML_STATIC_LIBRARIES for FindSFML. As soon as it changes the script should automagically delete all SFML_*_LIBRARY_* variables so that they're searched for again. I guess I'll do the same for FindSFGUI.