[Bf-committers] MinGW debug builds do not run

Fri Feb 25 18:39:07 CET 2011

Thanks Ervin, that did the trick and I was able to hunt down my problem. 
Now when is anyone going to look at my wonderful patch? ;-) 
http://projects.blender.org/tracker/index.php?func=detail&aid=26044&group_id=9&atid=127

On 25/02/2011 3:13, ervin weber wrote:
> 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
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>