Windows support

[ViralBShah]

Is flexiblas supported with mingw compilers on Windows? If it is known to work, I'd love to explore the use of flexiblas as the way we work with BLAS/LAPACK in Julia. Some discussion here https://github.com/JuliaLang/julia/issues/4290

[Enchufa2]

I don't know about Windows compatibility, as I'm the mere downstream packager for Fedora, but I would like to highlight that Julia was one of the exceptions we had to make for this change due to the complex setup Julia has to support parallel 32/64-bit builds with prefixes, etc. For the rest of the languages (Python SciPy & Numpy, Octave, R... and the rest of the BLAS/LAPACK consumers), it works just great (see e.g., this guide for live switching in an R session). So we would be very happy if Julia considers adding support for FlexiBLAS, as it could be better integrated into Fedora.

[ViralBShah]

Ah I didn't know that the change was made to accommodate Julia. That is great. We ended up picking 64-bit BLAS/LAPACK and adopting the suffixes that we noticed many other numerical software folks were doing, and to avoid inevitable crashes when people mix things. Thank you for accommodating. When I first read about FlexiBLAS, this was the first question I had - and it was already answered in the positive. :-)

We'll start with doing it in our BinaryBuilder first, and trying it out in the package ecosystem as an experiment. I am hoping the build will just work on Windows. But if it doesn't work on Windows with mingw, we won't be able to adopt it, since we have spent a huge amount of effort over the years to ensure that Julia works across Linux, Mac and Windows.

[Enchufa2]

Sorry, maybe I wasn't clear enough. What I meant is that we made the change to accomodate the whole stack of BLAS/LAPACK consumers in Fedora to use FlexiBLAS, and we had to make an exception for Julia because we couldn't make it work with FlexiBLAS in its current state. So literally everything in Fedora uses FlexiBLAS except for Julia.

[ViralBShah]

Sorry, I misunderstood. It should be fairly easy to support it on Fedora. I'll plan to try it out in the next few days.

[grisuthedragon]

In the early versions of FlexiBLAS I did some work with mingw cross compiling and testing it under wine. I stopped this efforts since developing for Windows is ugly and there was no demand on it. If I remember a discussion with @Enchufa2 right, it is more urgent to include the suffixed *64 symbols in the context of Julia. I plan this feature for the long winter nights and I will include wrappers around the dlsym/dlopen routines such that the corresponding windows routines can be included. That should be the first step towards a windows version.

[ViralBShah]

I agree that is the right priority. Many projects have adopted that convention, and we have urged the Intel MKL team to support that as well (but we haven't heard back).

I'm sure the Julia community will be happy to help test.

[grisuthedragon]

@ViralBShah If you know something, can you comment on #2 if you think we need the suffix support there as well? Although I am developing BLAS and LAPACK stuff since more than 10 years, julia is the project where I recognized the usage of the suffix thing.

[ViralBShah]

Yes we use the 64_ suffix on all platforms, and we adopted it midway into the Julia project a few years ago. We had users who clearly needed the 64-bit BLAS and there were too many issues using the 64-bit BLAS by default without mangling names. You're right though that it is not a common thing, although we followed convention set in a few other projects to resolve the crashes resulting from packages expecting a 32-bit BLAS linking to our 64-bit one that Julia ships by default.

See this discussion: https://github.com/JuliaLang/julia/issues/30828#issuecomment-521741743 https://github.com/JuliaLang/julia/issues/4923

Because of the name mangling, we are able to simultaneously support both 32-bit and 64-bit BLAS/LAPACK now in our package ecosystem.

cc @andreasnoack @staticfloat

[Enchufa2]

@ViralBShah If you know something, can you comment on #10 if you think we need the suffix support there as well?

You probably meant #2, right?

[grisuthedragon]

@ViralBShah If you know something, can you comment on #10 if you think we need the suffix support there as well?

You probably meant #2, right?

I changed it ;-)