Are we really sure fortran compiler is the issue ? For example, gcc was GPL but has an exception for compiled-linked binaries using libc, so that the result binary won't be affected by GPL.
TQ On Tue, May 12, 2020 at 2:47 PM Lausen, Leonard <lau...@amazon.com.invalid> wrote: > On Tue, 2020-05-12 at 13:05 -0700, Zach Kimberg wrote: > > I would also like to ask how we use libgfortran? Since it is category X, > we > > should not be depending on it for any of the core functionality in MXNet. > > It can only have an "optional feature" ( > > https://www.apache.org/legal/resolved.html#optional) at most. > Furthermore, > > libgfortran seems to be under the full GPL ( > > https://github.com/gcc-mirror/gcc/blob/master/libgfortran/libgfortran.h) > > instead of the LGPL, so I don't know if we are even allowed to even have > it > > as an optional dependency. > > OpenBLAS's LAPACK implementation relies on a Fortran compiler. > https://github.com/xianyi/OpenBLAS#dependencies The binaries on > repository.apache.org are of the MXNet OpenBLAS variant. > gfortran is typically the default choice for Fortran compiler. > > Two options if we like to distribute official ASF convenience binaries: > > 1) We can build OpenBLAS without LAPACK, though the operators relying on > > https://github.com/apache/incubator-mxnet/blob/master/src/operator/c_lapack_api.h > are unavailable in such build. > > 2) Investigate recent LLVM based Fortran compilers, though as far as I > understand they are not yet production ready: > > https://www.phoronix.com/scan.php?page=news_item&px=LLVM-Lands-FLANG-F18-Finally > Maybe there are other alternatives. > > Best regards > Leonard >
