[Numpy-discussion] draft release guide

[David Cournapeau]

Francesc Alted wrote:

> 
> C:\Users\francesc\Desktop\NumPy>gdb python
> GNU gdb (GDB) 7.1.50.20100318-cvs
> Copyright (C) 2010 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-w64-mingw32".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>...
> Reading symbols from \Python26_64/python.exe...(no debugging symbols 
> found)...done.
> (gdb) r
> Starting program: \Python26_64/python.exe
> [New Thread 2880.0x410]
> Python 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit (AMD64)] 
> on
> win32
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import numpy
> C:\Python26_64\lib\site-packages\numpy\core\__init__.py:5: Warning: Numpy 
> built
> with MINGW-W64 on Windows 64 bits is experimental, and only available for
> testing. You are advised not to use it for production.
> 
> CRASHES ARE TO BE EXPECTED - PLEASE REPORT THEM TO NUMPY DEVELOPERS
>   import multiarray
>>>> numpy.test()
> Running unit tests for numpy
> NumPy version 1.4.0
> NumPy is installed in C:\Python26_64\lib\site-packages\numpy
> Python version 2.6.5 (r265:79096, Mar 19 2010, 18:02:59) [MSC v.1500 64 bit 
> (AMD
> 64)]
> nose version 0.11.3
> Forcing DISTUTILS_USE_SDK=1
> .....warning: HEAP[python.exe]:
> warning: Invalid address specified to RtlFreeHeap( 0000000002240000, 
> 0000000000C
> 25110 )
> 
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x0000000076fa6061 in ntdll!DbgBreakPoint ()
>    from C:\Windows\system32\ntdll.dll
> (gdb) bt
> #0  0x0000000076fa6061 in ntdll!DbgBreakPoint ()
>    from C:\Windows\system32\ntdll.dll
> #1  0x0000000076ffe17a in ntdll!EtwEventProviderEnabled ()
>    from C:\Windows\system32\ntdll.dll
> #2  0x00000000022af0d8 in ?? ()
> #3  0x000000005104095c in ?? ()
> #4  0x0000000000219a08 in ?? ()
> #5  0x000000000e040001 in ?? ()
> #6  0x0000000002240000 in ?? ()
> #7  0x0000000076fe27a1 in ntdll!MD4Final () from C:\Windows\system32\ntdll.dll
> #8  0x0000000076fb9630 in ntdll!LdrGetProcedureAddress ()
>    from C:\Windows\system32\ntdll.dll
> #9  0x0000000076fb9500 in ntdll!LdrGetProcedureAddress ()
>    from C:\Windows\system32\ntdll.dll
> #10 0x0000000002240000 in ?? ()
> #11 0x0000000000c25110 in ?? ()
> #12 0x0000000002240000 in ?? ()
> #13 0x000000000623f197 in ?? ()
> #14 0x0000000002240000 in ?? ()
> #15 0x00000000770151a9 in ntdll!RtlTraceDatabaseCreate ()
>    from C:\Windows\system32\ntdll.dll
> #16 0x0000000000000000 in ?? ()
> (gdb)

Believe it or not, but this is already much better than what I had last 
time I looked at it (the stack was corrupted after two items, and gdb 
often crashed). I had to build custom mingw runtimes to get there last 
year :)

> 
> So, it is still exactly as you said: it seems like gdb cannot introspect MS 
> debug symbols.

And for completeness, the MS tools of course cannot read the mingw 
debugging symbols, but the contrary would have been surprising. It does 
not help that debugging things inside the MS C runtime is a nightmare 
(because you have to rebuild everything, including python). I wonder if 
MS makes the sources of their runtime available under some license to 
look more into it.

I also thought about using valgrind, but then there are some issues 
running wine in 64 bits mode under valgrind (maybe solved since then: 
https://bugs.kde.org/show_bug.cgi?id=197259).

> 
> Exactly.  OK, I think I'm done with this try for the moment.  It is a pity 
> because mingw-w64 does an excellent job with my preliminary tests with Blosc 
> compressor (it achieves 4x better performance than mingw-w32 and 2x better 
> than MSVC 2008 32-bit).  But before going MSVC 64-bit route, I'd like to test 
> Intel compiler 64-bit.  Anyone knows if it can cope with numpy?

What works well is MS compiler + Intel Fortran compiler (at least with 
numscons). Surprisingly, when I tried using the Intel C compiler + Intel 
Fortran compiler, I also had a lot of issues, not unlike the ones with 
mingw. What I am afraid is that the C runtimes issues are unsolvable on 
win64 because of python, and that we have to use the MS compiler (for C 
and C++).

cheers,

David