[Bf-committers] MinGW debug builds do not run

Fri Feb 25 16:13:45 CET 2011

Ok, I think to have found the solution to compile debug Blender with 
scons + mingw.

Tested on WinXP + MinGW gcc 4.5.2 + scons + Blender rev. 35129
I have msvc 2008 express installed, so it may depend on that too.
Can someone without msvc installed confirm that it works?
Thanks.

Short version:
-------------

Add this to your user-config.py
BF_DEBUG_CCFLAGS = ['-g', '-DDEBUG','-D_DEBUG']

Long explanation:
----------------

My debug Blenders always crashed on start with this error (same as Tom 
Edwards):

"The procedure entry point PyModule_Create2 could not be located in the
dynamic link library python31_d.dll."

Actually there is no PyModule_Create2 entry point in python31_d.dll, 
however there is one for PyModule_Create2TraceRefs.
Instead in python31.dll there's an entry for PyModule_Create2 and none 
for PyModule_Create2TraceRefs.

bash-3.1$ cd lib/windows/python/lib/

bash-3.1$ grep -nr PyModule_Create2[^T] *
Binary file python31.dll matches
Binary file python31.lib matches
Binary file python31mw.lib matches
Binary file python31mw_d.lib matches

bash-3.1$ grep -nr PyModule_Create2TraceRefs *
python31_d.def:122:PyModule_Create2TraceRefs
Binary file python31_d.dll matches
Binary file python31_d.lib matches
Binary file python31_d.pdb matches
Binary file python31mw.lib matches
Binary file python31mw_d.lib matches

Turns out that the python headers are replacing symbol definitions 
depending whether you are building a python release or debug dll.

modsupport.h:94:

#ifdef Py_TRACE_REFS
  /* When we are tracing reference counts, rename PyModule_Create2 so
     modules compiled with incompatible settings will generate a
     link-time error. */
  #define PyModule_Create2 PyModule_Create2TraceRefs
#endif

object.h:54:

/* Py_DEBUG implies Py_TRACE_REFS. */
#if defined(Py_DEBUG) && !defined(Py_TRACE_REFS)
#define Py_TRACE_REFS
#endif

pyconfig.h:369:

#ifdef _DEBUG
#	define Py_DEBUG
#endif

The default user-config doesn't set _DEBUG so Blender compiles against 
PyModule_Create2 which doesn't exists in python31_d.dll, hence the crash.

On 23/02/2011 20.01, Peter Kümmel wrote:
> On 23.02.2011 10:45, Nathan Letwory wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 21.2.2011 1:15, Peter Kümmel wrote:
>>> It compiles now out of the box but still crashes.
>>> Seems I have to go the 'hard' way you described.
>>
>> Python 3.1 debug dll is built dynamically linking against msvc9 debug
>> runtime, so if you want to run debug with other than vs2008, you'll have
>> to acquire the appropriate debug runtime dlls. These are not
>> redistributable, so you'll need to get vs2008 (I assume the express
>> version will do, but can't tell for sure).
>>
>> You could also rebuild python 3.1 debug dll with mingw, if that's
>> possible, I suppose. And when using vs2010, you could rebuild the python
>> 3.1 debug dll with that.
>>
>
> OK. Is it possible that these dlls get added to subversion?
> I would update the cmake rules then.
>
> Peter
>
>> Anyway, have the correct debug runtime dlls in the same dir as
>> blender.exe, and you should be running fine.
>>
>> /Nathan
>>
>>>
>>> On 20.02.2011 14:46, Campbell Barton wrote:
>>>> IIRC MSVC2008 full version is used for releases,
>>>> I have a free MSVC2010 which has a similar problem to MinGW, debug
>>>> builds fail to run with strange popup dialog error.
>>>>
>>>> Re Crash on startup:
>>>>     If its a crash (not a linking/error message), best not assume blender
>>>> is without fault, debug info&    call-stack can help a lot in tracking
>>>> down these problems.
>>>>
>>>> The IOError define is already in lib/windows, committed shortly after
>>>> changing the exception.
>>>> I use an update alias which does both repo's before building to
>>>> prevent these kinds of errors.
>>>>
>>>> Do you still get the crash on startup?
>>>>
>>>> On Sun, Feb 20, 2011 at 11:54 AM, Peter Kümmel<syntheticpp at gmx.net>    wrote:
>>>>> On 20.02.2011 04:24, Campbell Barton wrote:
>>>>>
>>>>>> Whats supported isn't set in stone, its more a case of which
>>>>>> configurations are tested&      known to work.
>>>>>
>>>>> OK, thanks. And what is mostly used for the Windows releases?
>>>>>
>>>>>>
>>>>>> this works for me.
>>>>>> - windows xp
>>>>>> - mingw-gcc4.5.2, (from mingw's main site)
>>>>>> - cmake 2.8 (build type set to Release or RelWithDebInfo)
>>>>>> - blender (tested r34959)
>>>>>
>>>>> I had a little bit outdated checkout with 4.4, W7-64Bit, and
>>>>> problems with release and debug.
>>>>>
>>>>>>
>>>>>> A crash on startup may be a real bug rather then lack of support, you
>>>>>> could run with gdb and see why its crashing.
>>>>>> If you are unable to figure out how to fix you could file a bug and
>>>>>> include a backtace.
>>>>>
>>>>> I assume not really a error in blender code, it's the mixture of
>>>>> pre-compiled binaries, compiler used for blender, OS, and runtime
>>>>> libraries.
>>>>>
>>>>> Best is to build everyting with the same compiler.
>>>>>
>>>>>>
>>>>>> Another way to help find the cause of the crash is to disable all
>>>>>> WITH_* options in cmake configuration, WITH_OPENAL, WITH_IMAGE_OPENEXR
>>>>>> ... etc.
>>>>>>
>>>>>> If this works you could try again with usable settings (so you get an
>>>>>> interface),
>>>>>> all off except WITH_PYTHON WITH_INSTALL and WITH_PYTHON_INSTALL.
>>>>>
>>>>> I already had the idea to try it without python ;)
>>>>>
>>>>>> After that its trial and error to see which library causes the crash,
>>>>>> the offending lib could be disabled by default with mingw until its
>>>>>> fixed properly.
>>>>>>
>>>>>> One other thing, you were getting the error 'PyModule_Create2'
>>>>>> interestingly I got this error too on Linux when trying to load a
>>>>>> library built with a debug python but finding a release library.
>>>>>
>>>>> I could link against the lib/windows version with attached patch.
>>>>>
>>>>>>
>>>>>> On Sat, Feb 19, 2011 at 3:26 PM, Peter Kümmel<syntheticpp at gmx.net>      wrote:
>>>>>>>
>>>>>>> Tested it with cmake too. It links after a small fix, but
>>>>>>> crashes immediately after starting. Seems mingw isn't supported.
>>>>>>>
>>>>>>> Peter
>>
>>
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1.4.10 (MingW32)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iQEcBAEBAgAGBQJNZNckAAoJEKtfN7KsE0Ttpr8IAI3/xa4WCO373kchO1W7AI16
>> ZZSzd9oe9PYgyZqJ3AylmdozyNaEg//EuLFtWQnFqov9XE/tuK/8ZNVOD3Ro2hLK
>> tZ6Z38eQjkXaMOrXR/R+yZnbRutsru3P6xqTHfZY7Au65Z8BQaW1LxXZD0LRrB+p
>> ITMxB3Tn17wxDEj7AJywVKB4GHhFUMo0vaVdB5LLjnpMXpB+wjGSrvhyZQUStGnb
>> y05TAxR+Z6fXgvtHrf967PQAeoVVjdigyCY0UNtOg4YMDAeHSVeIQqYHSsPvXmru
>> B4383jq4q/mnUgOcgYJhSrFr1mSx0f7LmeMdWcq6G2XHK+8NTS7aZ8x9pY0xMdE=
>> =ifdD
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>