[Numpy-discussion] Should we drop support for "one file" compilation mode?
cournape at gmail.com
Tue Oct 6 13:31:04 EDT 2015
On Tue, Oct 6, 2015 at 6:18 PM, David Cournapeau <cournape at gmail.com> wrote:
> On Tue, Oct 6, 2015 at 6:14 PM, Nathaniel Smith <njs at pobox.com> wrote:
>> On Tue, Oct 6, 2015 at 10:10 AM, David Cournapeau <cournape at gmail.com>
>> > On Tue, Oct 6, 2015 at 6:07 PM, Nathaniel Smith <njs at pobox.com> wrote:
>> >> On Tue, Oct 6, 2015 at 10:00 AM, Antoine Pitrou <solipsis at pitrou.net>
>> >> wrote:
>> >> > On Tue, 6 Oct 2015 09:40:43 -0700
>> >> > Nathaniel Smith <njs at pobox.com> wrote:
>> >> >>
>> >> >> If you need some npy_* function it'd be much better to let us know
>> >> >> what it is and let us export it in an intentional way, instead of
>> >> >> relying on whatever stuff we accidentally exposed?
>> >> >
>> >> > Ok, we seem to be using only the complex math functions (npy_cpow and
>> >> > friends, I could make a complete list if required).
>> >> And how are you getting at them? Are you just relying the way that on
>> >> ELF systems, if two libraries are loaded into the same address space
>> >> then they automatically get access to each other's symbols, even if
>> >> they aren't linked to each other? What do you do on Windows?
>> > It is possible (and documented) to use any of the npy_ symbols from
>> > from outside numpy:
>> > The design is not perfect (I was young and foolish :) ), but it has
>> > fairly well and has been used in at least scipy since the 1.4/1.5 days
>> > (including windows).
>> Okay, so just to confirm, it looks like this does indeed implement the
>> static linking thing I just suggested (so perhaps I am also young and
>> foolish ;-)) -- from looking at the output of get_info("npymath"), it
>> seems to add -I.../numpy/core/include to the compiler flags, add
>> -lnpymath -L.../numpy/core/lib to the linker flags, and then
>> .../numpy/core/lib contains only libnpymath.a, so it's static linking.
> Yes, I was not trying to argue otherwise. If you thought I was, blame it
> on my poor English (which sadly does not get better as I get less young...).
> My proposal is to extend this technique for *internal* API, but with the
> following differences:
> * the declarations are not put in any public header
> * we don't offer any way to link to this library, and name it something
> scary enough that people would have to be foolish (young or not) to use it.
I am stupid: we of course do not even ship that internal library, it would
just be linked into multiarray/umath and never installed or part of binary
>> Nathaniel J. Smith -- http://vorpus.org
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion