[Numpy-discussion] 64bit infrastructure
Wed Aug 22 10:06:13 CDT 2012
On Wed, Aug 22, 2012 at 3:35 PM, Travis Oliphant <email@example.com> wrote:
> On Aug 22, 2012, at 9:28 AM, David Cournapeau wrote:
>> On Wed, Aug 22, 2012 at 3:25 PM, Travis Oliphant <firstname.lastname@example.org> wrote:
>>> On Aug 22, 2012, at 3:59 AM, Ralf Gommers wrote:
>>> On Tue, Aug 21, 2012 at 12:51 AM, Travis Oliphant <email@example.com>
>>>> I'm actually not sure, why. I think the issue is making sure that the
>>>> release manager can actually "build" NumPy without having to buy a
>>>> particular compiler.
>>> That would help, yes. MS Express doesn't work under Wine last time I checked
>>> by the way.
>>> However, the issue is more than just one license. There's a large number of
>>> packages that depend on numpy and provide binaries. If they can't make those
>>> compatible with numpy ones, that's a problem. Users will first install numpy
>>> 64-bit, and then later find out that part of the scientific Python stack
>>> isn't available to them anymore.
>>> As far as I understand, you don't *have* to build all downstream
>>> dependencies with the same compiler that NumPy was built with unless your
>>> extension relies on the way C-functions pass structures on the stack (not
>>> pointers to them, but structures as a whole) or if it relies on the
>>> representation of FILE*. At one time all structures were passed as
>>> pointers specifically for this reason. The FILE* situation is a problem,
>>> but most extensions don't use NumPy C-API calls that have a FILE* argument.
>> It is much more pervasive than that, unfortunately. And for fortran,
>> it is much worse, because if we build scipy or numpy with Intel
>> Fortran, I think we pretty much force everyone to use intel fortran
>> for *any* binary on top of them.
> Can you be more specific? Does the calling convention for C-routines created with Intel Fortran differ so much?
If we were to use intel, it would be with MS compilers, and I have
never been able to link a gfortran program with visual studio. I will
try to take a look at it again during euroscipy,
More information about the NumPy-Discussion