Author Topic: SFML 2.0 - Static builds (Read 7838 times)

slotdev · « **on:** June 17, 2011, 01:50:26 pm »

Hi Folks

I am trying to rebuild SFML 2.0, linking statically to the Windows CRT stuff, and it's not working. I am sure all my compiler settings are correct, but when I look at the DLLs with Dependency Walker, it shows up dependencies on:

c:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.6195_none_d09154e044272b9a\MSVCP80.DLL

....which aren't installed on my target machines (erm, all 18,000 of them!).

This used to work fine until I updated SFML 2.0 a few months back.

Here are my compiler settings (for all SFML libraries):

Configuration Type: Dynamic Library (.dll)
Use of MFC: Use standard Windows libraries
Use of ATL: Static Link to ATL
Minimize CRT Use in ATL: Yes
Character Set: Use Multi-Byte Character Set (hmmm?)
Common Lang. Runtime Support: No Common Lang Runtime support

Any ideas?

slotdev · « **Reply #1 on:** June 17, 2011, 02:04:52 pm »

I have deja-va. I am sure I have asked this before.

I think it was a CMAKE option that needed to be set to use the CRT stuff statically?

Laurent · « **Reply #2 on:** June 17, 2011, 02:06:10 pm »

Which revision of SFML 2 are you using?

Quote

Here are my compiler settings (for all SFML libraries):

Configuration Type: Dynamic Library (.dll)
Use of MFC: Use standard Windows libraries
Use of ATL: Static Link to ATL
Minimize CRT Use in ATL: Yes
Character Set: Use Multi-Byte Character Set (hmmm?)
Common Lang. Runtime Support: No Common Lang Runtime support

Did you change this yourself? Did you generate the projects with CMake?
By the way, the interesting option is in "C/C++" "Code generation" "Runtime libraries".

slotdev · « **Reply #3 on:** June 17, 2011, 02:41:31 pm »

Right, it works now. But for some reason when I run it on my development system, it crashes with a heap allocation fault (which I remember having to change to non-static libs to work around).

I'm using a version from 27/5 - so fairly recent.

slotdev · « **Reply #4 on:** June 17, 2011, 05:50:38 pm »

Sorry, Laurent, to answer your questions:

In the compiler info above, I changed that myself. I then realised it was an option in CMAKE, so I changed that and recompiled everything, and it works.

The problem with this is, using Release DLLs, there is a "heap corruption" somewhere in SFML when you try to run a program (release mode build). If being run normally (Ctrl + F5) it just gives a Windows "This program has stopped working" dialog, and if you run it under F5 (debug, which should just run it as normal, given all the debug info isn't generated), you get this:

HEAP[PR1027.exe]: Invalid address specified to RtlFreeHeap( 003D0000, 020453D8 )
Windows has triggered a breakpoint in PR1027.exe.

This may be due to a corruption of the heap, and indicates a bug in PR1027.exe or any of the DLLs it has loaded.

The output window may have more diagnostic information
The program '[6772] PR1027.exe: Native' has exited with code 0 (0x0).

Call stack (useless)

>   ntdll.dll!77c10844()
    [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]
    ntdll.dll!77bd2a74()
    ntdll.dll!77c1189f()
    ntdll.dll!77bca9af()

Any ideas??

Thanks
Ed

Laurent · « **Reply #5 on:** June 17, 2011, 06:03:15 pm »

Does it run ok in debug mode? Are you sure that you're not linking the debug libraries in release mode?

slotdev · « **Reply #6 on:** June 17, 2011, 06:10:27 pm »

Hmm so I realised, in Debug mode, I was using my old DLLs. Put the new ones in, and I get the same heap error, but now I have traced it to a single line of code.

Code: [Select]


	sf::Font myFont;
	if (myFont.LoadFromFile("arial.ttf"))
	{
		sf::Text startText("hello world",myFont,150); // DIES IN HERE!
        }

It actually crashes in "new.cpp" line 59:

Code: [Select]

void *__CRTDECL operator new(size_t size) _THROW1(_STD bad_alloc)
        {       // try to allocate size bytes
        void *p;
        while ((p = malloc(size)) == 0) // DIES HERE!
                if (_callnewh(size) == 0)
                {       // report no memory
                static const std::bad_alloc nomem;
                _RAISE(nomem);
                }

        return (p);
        }

Call stack trace:

    ntdll.dll!77c10844()

    [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]

    ntdll.dll!77bd2a74()

    ntdll.dll!77b8cd87()

>   sfml-system-d-2.dll!operator new(unsigned int size=11075584) Line 59 + 0x9 bytes   C++

    KernelBase.dll!7700468e()

    sfml-graphics-d-2.dll!_CrtIsValidHeapPointer(const void * pUserData=0x00b16ec8) Line 2072   C++

    sfml-graphics-d-2.dll!_free_dbg_nolock(void * pUserData=0x00b16ec8, int nBlockUse=1) Line 1279 + 0x9 bytes   C++

    sfml-graphics-d-2.dll!_free_dbg(void * pUserData=0x00b16ec8, int nBlockUse=1) Line 1220 + 0xd bytes   C++

    sfml-graphics-d-2.dll!operator delete(void * pUserData=0x00b16ec8) Line 54 + 0x10 bytes   C++

    sfml-graphics-d-2.dll!std::allocator<unsigned int>::deallocate(unsigned int * _Ptr=0x00b16ec8, unsigned int __formal=12) Line 141 + 0x9 bytes   C++

    sfml-graphics-d-2.dll!std::basic_string<unsigned int,std::char_traits<unsigned int>,std::allocator<unsigned int> >::_Tidy(bool _Built=true, unsigned int _Newsize=0) Line 2076   C++

    sfml-graphics-d-2.dll!std::basic_string<unsigned int,std::char_traits<unsigned int>,std::allocator<unsigned int> >::~basic_string<unsigned int,std::char_traits<unsigned int>,std::allocator<unsigned int> >() Line 906   C++

    sfml-graphics-d-2.dll!sf::String::~String() + 0x16 bytes   C++

Now I am really confused

slotdev · « **Reply #7 on:** June 17, 2011, 06:17:29 pm »

I've broken the code up more to track the bug down:

Code: [Select]

	
        sf::Font myFont;
	if (myFont.LoadFromFile("arial.ttf"))
	{
		sf::Text startText;
		startText.SetString("hello world"); // DIES HERE
		startText.SetFont(myFont);
		startText.SetCharacterSize(150);
        }

It dies on a line in a file called "C:\Program Files (x86)\Microsoft Visual Studio 8\VC\crt\src\dbgheap.c\dbgheap.c", line 268:

Code: [Select]


pvBlk = _heap_alloc_dbg(nSize, nBlockUse, szFileName, nLine);

"nSize" is 1636408. That strikes me as quite a lot?

slotdev · « **Reply #8 on:** June 17, 2011, 06:26:39 pm »

I am having deja-vu seriously today. This problem has been raised before, and you (Laurent) suggested viewing this: https://github.com/SFML/SFML/issues/53

So it's a problem with static linking to stdlib. Now, my problem is, I MUST static link to this (and anything else to avoid WinSxS errors).

So....what can I do ?

Ed

Laurent · « **Reply #9 on:** June 17, 2011, 10:50:47 pm »

So you statically link the std libs in your project as well?

slotdev · « **Reply #10 on:** June 18, 2011, 01:43:18 pm »

Laurent

Yes I use /MT and /MTd, so really I'm not sure what is going on.

Thanks
Ed

slotdev · « **Reply #11 on:** June 18, 2011, 07:03:41 pm »

Do you think I am mixing static and dynamic? I really need to fix this as my game will be using a lot of sf::Text stuff!

Laurent · « **Reply #12 on:** June 19, 2011, 10:14:18 am »

I don't know, sorry. Try to download the latest SFML 2 files and restart everything from scratch.

slotdev · « **Reply #13 on:** June 19, 2011, 04:08:12 pm »

I've updated to the latest SFML 2 just now, recompiled everything, replaced all the DLLs in my project, and the same problem occurs. Can you try a simple app which uses a static linked SFML 2, static linked STDLIB (/MT) and see if you get the same problem with sf::Text?

Thanks

slotdev · « **Reply #14 on:** June 20, 2011, 06:18:17 pm »

The mystery deepens, somewhat.

So I just ran my update SFML 2 and game on the target system, and it all works like a dream.

The target is running XP Embedded, 32-bit.

My dev system is Win7, 64 bit. I compiled the SFML libs using VC 2005 32-bit (I don't think there is a 64 bit compiler/compiler option anyway?) and it does not work, in Release mode, as described above.

So, the question is, what's the difference? Why does it work on a 32-bit system and not a 64-bit....and why does it work on a 64-bit but in Debug mode only?

Very strange.