On Wed, Jun 27, 2012 at 7:50 PM, David Cournapeau <cournape@gmail.com> wrote:
On Wed, Jun 27, 2012 at 7:17 PM, Nathaniel Smith <njs@pobox.com> wrote:
Currently the numpy build system(s) support two ways of building numpy: either by compiling a giant concatenated C file, or by the more conventional route of first compiling each .c file to a .o file, and then linking those together. I gather from comments in the source code that the former is the traditional method, and the latter is the newer "experimental" approach.
It's easy to break one of these builds without breaking the other (I just did this with the NA branch, and David had to clean up after me), and I don't see what value we really get from having both options -- it seems to just double the size of the test matrix without adding value.
There is unfortunately a big value in it: there is no standard way in C to share symbols within a library without polluting the whole process namespace, except on windows where the default is to export nothing.
Most compilers support it (I actually know of none that does not support it in some way or the others), but that's platform-specific.
IIRC this isn't too tricky to arrange for with gcc, but why is this an issue in the first place for a Python extension module? Extension modules are opened without RTLD_GLOBAL, which means that they *never* export any symbols. At least, that's how it should work on Linux and most Unix-alikes; I don't know much about OS X's linker, except that it's unusual in other ways. -N