[Biopython-dev] Re: Work towards getting KDTree compiling

[Brad Chapman]

Hi Michiel;

[mingw32]
> >As a complete guess, I tried applying the same changes I used for
> >Python 2.2.x to mingw32 compilation. Will you give the new setup.py 
> >a try and see if it improves anything at all?
> 
> Sorry, doesn't work. Using Python 2.3.3:
> 
> building 'Bio.KDTree._CKDTree' extension
> creating build\temp.win32-2.3\Release\bio\kdtree
> Traceback (most recent call last):
[...]

Ugh, that's worse :-). Clearly I have no idea what I am doing with
that, so I'll quit messing around. What I did right now was turn off
the compilation of C++ extensions with mingw32. I think. Could you
please double check it to make sure it works now -- by works, I
mean skips the compilation of C++ and finishes okay. We'll have to
wait for either better mingw32 support or someone who knows what
they are doing to deal with this again.

[Sun]
> >Does Tests/test_KDTree.py work for you as well? If there are no
> >problems then I say we are all in the clear. Since distutils is
> >really just pulling up the C++ compiler information from the
> >environment, there is really nothing we can do about the cc/g++
> >conflict -- honestly this is probably a issue where a solaris user
> >has to set CXX to point to the native c++ compiler.
> 
> It works! Allright! Using Python 2.3.3 on SunOS 5.8:

Good stuff. Well, as long as it compiles and works I'm happy. Woo.

[Mac OS X]
> >Hmmm. How do they crash? Just a core dump? Can you attach gdb and
> >see anything? Also, is this with gcc? What versions? For the record,
> >I'm compiling with gcc version 2.95.4 and 3.3.3 without any
> >problems.
> >
> 
> I'm not sure if this will help much but this is what I get from gdb:
> 
> >>> from Bio.KDTree import *
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries bfd_mach_o_scan_read_symtab_symbol: 
> symbol name out of range (399792 >= 5512)
> . done
> 
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> 0x8fe0cc18 in __dyld_is_symbol_coalesced ()
> (gdb)

Bleah. Some kind of memory leak when loading the libraries -- I have
zero idea what that means or how to fix it. If it compiles decently,
then I'll leave it right now, and just hope that some Mac OS people
can come up with a reason/solution for this. Anyone else with OS X
can confirm?

Otherwise, well -- I have no idea what to do.

> The celmodule.cc code in Affy is very short and uses few C++ specific 
> routines. Converting this code to standard C is almost trivial and would 
> more robust than modifying setup.py to handle C++. Converting KDTree would 
> require some more work though.

I'd agree in general -- C++ code seems to be a major mess through
distutils. I know that Harry Zuzan, the author of the celmodule
code, said he prefers to work in C++ previously. I'm not sure
what his plans are for expanding this -- right now it appears to be
a tradeoff between what he wants to code in and what level of use on
various platforms he can expect.

Thanks again for all your work on this Michiel. Now I remember why I
prefer to just plain code in Python :-).

Brad