You're right that the compiler itself is not the problem. The resulting dependency on libgfortran.so runtime library and the JAR including the .so file is the problem. We can remove the .so file from the JAR and require that it's present on the user's system. That would be similar to how we already require presence of LGPL libc.so and libgcc.so on the user's system. (LGPL is also Category-X)
The reason that the third-party Pypi builds don't make the same assumption for libgfortran.so is that according to the packaging standard https://www.python.org/dev/peps/pep-0599/#the-manylinux2014-policy we mustn't assume that libgfortran.so is present. By reusing the code responsible for the Python static build, the JAR builds ended up with libgfortran.so included. So the key question is: How common is the presence of libgfortran.so among the users of the repository.apache.org convenience binaries. Is it reasonable to require it? This should have been listed as Option 3) in the previous email. Best regards Leonard PS: Another potential issue is the ABI. Ideally, if the ABI is stable, we can compile OpenBLAS on CentOS 7 with libgfortran.so.3, declare a dependency on libgfortran.so and have the resulting binary also work with libgfortran.so.4 and libgfortran.so.5. I haven't tested that though. On Tue, 2020-05-12 at 14:57 -0700, Tianqi Chen wrote: > 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 > >
