NumPy 1.14 on Window requires flang.lib when compiling C extensions

[jjhelmus]

When compiling a C extension which uses NumPy 1.14 the linker seems to be requiring flang.lib and other libraries. For example this build of arm_pyart.

The immediate issue can be solved by building against an older NumPy and relying on NumPy's backwards compatibility.

[ocefpaf]

Argh... I'll remove the Windows packages, again, and we can talk about a better strategy in this later.

Thanks for the report @jjhelmus

cc.: @xoviat

[ghost]

That's not what is happening. You're trying to compile fortran code without the flang dependency.

Note: NumPy thinks that the flang compiler works (config.have_f90c()) because of the numpy->openblas->libflang->openmp->clangdev dependency, which provides an executable named flang that doesn't work when the flang package is not installed.

[ghost]

Possible solutions to this problem:

1. Move the flang.exe executable out of the clangdev package (not in favor).
2. Modify NumPy to check that the Fortran compiler actually works before trying to use it (possibly in favor).
3. Telling downstream users to use flang to compile Fortran code (no changes required here; enables modules that require Fortran; in favor).

[jakirkham]

Any idea why this issue doesn't affect us when using Intel Fortran to build NumPy?

Also why is there a flang.exe in clangdev? Seems like a poor separation of concerns.

[jjhelmus]

@xoviat You are correct, this seems to be caused by the fact that arm_pyart has both C and Fortran code.

I tried compiling pywavelets, which only has C code, against NumPy 1.14 and everything is fine.

In the arm_pyart example what I don't understand is why "flang.lib flangrti.lib ompstub.lib" are being added to the link arguments for the _sigmetfile module which is a C extension.

arm_pyart has logic to skip extensions which use Fortran, but this logic depends on config.have_f90c() returning False. It sounds like this logic will need to be updated

[ghost]

Any idea why this issue doesn't affect us when using Intel Fortran to build NumPy?

Intel Fortran runtime libraries don't depend on a compiler package. For example, the intel-openmp package doesn't depend on having ifort installed.

Also why is there a flang.exe in clangdev? Seems like a poor separation of concerns.

The modified clangdev that we provide contains a Fortran compiler driver. However, the code generation is done in the flang package.

In the arm_pyart example what I don't understand is why "flang.lib flangrti.lib ompstub.lib" are being added to the link arguments for the _sigmetfile module which is a C extension.

Compiler libraries are applied globally. When you enable the Fortran compiler, all of your extensions get the Fortran libraries. Same with a custom C compiler.

[ghost]

One idea is to create a new flang-driver package that is just the flang executable and have it depend on clangdev (similar to how we split libflang out).

cc @isuruf

[jjhelmus]

Compiler libraries are applied globally. When you enable the Fortran compiler, all of your extensions get the Fortran libraries. Same with a custom C compiler.

Good to know, thanks for the help.

Since this is not an issue with NumPy itself I'm closing this. I would be in favor of re-adding the Windows NumPy 1.14 packages to the main label and removing them from broken.

[ghost]

The issue that I've opened at clangdev-feedstock should fix the config.have_f90c() function.

[jjhelmus]

The issue that I've opened at clangdev-feedstock should fix the config.have_f90c() function.

Sounds good, this seems in-line with the docstring section, "True if a Fortran 90 compiler is available (because a simple Fortran 90 code was able to be compiled successfully)"