[Numpy-discussion] 64bit infrastructure

Wed Aug 22 13:55:55 EDT 2012

On Wed, Aug 22, 2012 at 5:46 PM, Ondřej Čertík <ondrej.certik at gmail.com> wrote:
> On Wed, Aug 22, 2012 at 8:50 AM, David Cournapeau <cournape at gmail.com> wrote:
>> On Wed, Aug 22, 2012 at 4:12 PM, Ondřej Čertík <ondrej.certik at gmail.com> wrote:
>>> On Wed, Aug 22, 2012 at 7:35 AM, Travis Oliphant <travis at continuum.io> wrote:
>>>> On Aug 22, 2012, at 9:28 AM, David Cournapeau wrote:
>>>>
>>>>> On Wed, Aug 22, 2012 at 3:25 PM, Travis Oliphant <travis at continuum.io> wrote:
>>>>>>
>>>>>> On Aug 22, 2012, at 3:59 AM, Ralf Gommers wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Aug 21, 2012 at 12:51 AM, Travis Oliphant <travis at continuum.io>
>>>>>> wrote:
>>>>>>>
>>>>>>> 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?
>>>
>>>
>>> I have the same question as Travis. If you are interested about ABI
>>> for Fortran, I have created this FAQ:
>>>
>>> http://fortran90.org/src/faq.html#are-fortran-compilers-abi-compatible
>>>
>>> Since NumPy only calls the Fortran routines, but does not expose them,
>>> then the only issue is how to build NumPy with (let's say) Intel
>>> Fortran. That's a separate issue.
>>> Once NumPy is built, then nobody cares, because they only need to
>>> interface the C routines, if anything at all.
>>>
>>> As far as Fortran runtime library goes (which of course is different
>>> for Intel and gfortran), I am currently not sure whether it is
>>> possible to mix them, but I think you probably can, if numpy .so is
>>> using Intel, and my own .so is using gfortran.
>>>
>>>
>>> Finally, if NumPy is build using MSVC, does this force everybody to
>>> use the same C compiler? I thought that C compilers are ABI
>>> compatible, at least Intel C and gfortran C are ABI compatible.  Is
>>> MSVC different?
>>>
>>> Btw, to correctly call Fortran from C, one should always be using the
>>> iso_c_binding module, as explained here:
>>>
>>> http://fortran90.org/src/best-practices.html#interfacing-with-c
>>>
>>> Then the Fortran code becomes just like any other C library.
>>
>> It is unfortunately more complicated than that.
>>
>>  1 regarding fortran runtimes: I have never been able to link a
>> gfortran object file with Visual Studio linker (link.exe).
>
> You cannot mix the Fortran object .o files between compilers.
> That will never work, because Fortran compilers are not ABI
> compatible, see the FAQ.

I mean linking .o from the *same* compiler into a library through the
MS linker (link.exe instead of gcc one). That's how it works in
numpy/scipy so far, where we can link g77-produced .o files with the
MS compiler.

Most platforms have one linker, e.g. I think intel fortran compiler on
linux uses ld underneath.
>
> The only way this could work is if you can mix gcc .o file with MSVC
> linker (I don't
> know if this is possible or not). If that works,
> then you should be able to use iso_c_binding in Fortran to produce
> gcc's compatible .o
> file and then link it.

The problem is NOT communicating between C and fortran. I could
produce a simple fortran dll used inside a MSVC program, as long as
this fortran dll did not use anything from the fortran runtime. See
http://cournape.wordpress.com/2009/03/09/gfortran-visual-studio/ for
an actual example.

The problem is when you need the fortran runtime (which you do for scipy).

>
> Which errors were you getting when linking it? Was it a problem with
> libgfortran runtime
> (that you of course need to link as well)? This runtime can be a problem.

yes, the problem is gfortran runtime. libgfortran expects some mingw32
stuff, that cannot be linked into something through MS linker. IIRC,
you could use enough violence to make it link, but you would get nasty
runtime segfaults before anything gets run.

>
>>  2 mixing runtimes is never a good idea, because it becomes difficult
>> to avoid passing a pointer from one runtime to the other. Intel
>> fortran compiler obviously knows how to deal with the C runtime of
>> Visual Studio, but gfortran doesn't.
>
> By Fortran runtime I mean this library in my Ubuntu:
>
>         libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3
> (0x00007ffaa9ce9000)
>
> Here
> are all the libraries in my typical gfortran program:
>
>         linux-vdso.so.1 =>  (0x00007ffffe9ff000)
>         libgfortran.so.3 => /usr/lib/x86_64-linux-gnu/libgfortran.so.3
> (0x00007ffaa9ce9000)
>         libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ffaa99ef000)
>         libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ffaa97d8000)
>         libquadmath.so.0 => /usr/lib/x86_64-linux-gnu/libquadmath.so.0
> (0x00007ffaa95a2000)
>         libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ffaa91e5000)
>         /lib64/ld-linux-x86-64.so.2 (0x00007ffaaa022000)
>
> What exactly is the C runtime? libc?

It is kind of the equivalent of the C runtime, except it contains more
stuff than just the C std library.

> I don't want to force other people either to use Intel Fortran.
>
> But I still don't understand why I could not use gfortran and gcc for
> my program,
> that links against numpy (that uses let's say Intel Fortran internally).
>
> I don't have access to Intel Fortran on windows, but I am available to
> help with this issue.

I don't see many solutions to this problem:
  - one is rebuilding libgfortran with visual studio to use the MS C
runtime instead of mingw. That sounds painful
  - removing any dependency of the fortran runtime in scipy.

David