leezu edited a comment on issue #18855: URL: https://github.com/apache/incubator-mxnet/issues/18855#issuecomment-669300523
As discussed offline, we should avoid requiring all users to build openblas from source, especially as distributions start to provide `libopenblas64_.so` versions with OpenBLAS ILP64 build and `64_` suffix in symbol name. Fedora in https://bugzilla.redhat.com/show_bug.cgi?id=1295965. Debian testing / Ubuntu 20.04 provide `libopenblas64.so` without suffix per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878121 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910924 I initiated a discussion on https://lists.debian.org/debian-science/2020/08/threads.html about providing the same package in Debian. To avoid symbol version clashes as reported in these issues, we must require the suffixed symbol names or static link. We can work with cmake upstream on a standard approach to detecting 64bit suffixed openblas as part of https://cmake.org/cmake/help/latest/module/FindBLAS.html We can backport the upstream recommended approach to our https://github.com/apache/incubator-mxnet/tree/master/cmake/upstream To support older distributions that do not ship with `libopenblas64_.so`, we should include instructions for building `libopenblas64_.so` from source in our guide. Static linking is a great solution for the pip distribution build, but I don't think we should settle on a solution that requires static linking, because there are already better solution established as best practice (ie. symbol suffix) and this will restrict the versatility of MXNet source build and make it harder to package MXNet as part of Debian or other distributinos. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
