On Wed, Jun 27, 2012 at 7:50 PM, David Cournapeau <[email protected]> wrote: > On Wed, Jun 27, 2012 at 7:17 PM, Nathaniel Smith <[email protected]> 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 _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
