[jira] [Updated] (MXNET-796) Faulty CUDA detection with cmake
[ https://issues.apache.org/jira/browse/MXNET-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Chernov updated MXNET-796: Description: h2. Problem The current cmake CUDA support has multiple major problems. *Multiple not compatible definitions* CUDA can be part of cmake language detection and is not for older cmake versions. CUDA architectures can be detected by build-in cmake file. This would be preferred, but is not used by the current MXNet cmake scripts. CUDA is detected by 3 different files in the current cmake scripts and the choice of those is based on a obscure logic with involves different versions of cmake and platforms which it's building on * CMakeLists.txt * cmake/FirstClassLangCuda.cmake * 3rdparty/mshadow/cmake/Cuda.cmake *No support for new CUDA architectures or faulty detection* Only 3rdparty/mshadow/cmake/Cuda.cmake supports Volta architecture, but not in all circumstances. In a lot of situations the right architecture can not be detected properly and the script falls back to build all architectures bowing up both: build time and artefact size. cmake/FirstClassLangCuda.cmake is outdated and does not support Volta at all. CMakeLists.txt sets the CMAKE_GENERATOR_TOOLSET variable which is considered [undefined behaviour|https://cmake.org/cmake/help/v3.1/variable/CMAKE_GENERATOR_TOOLSET.html]. *Confusing and misleading cmake user options* Currently USE_CUDA / USE_OLDCMAKECUDA. Some of them will do or not do what they supposed to based on cmake generator version and version of cmake. *Other problems with dependencies* For example the caffe integration raises the minimum required cmake version to 3.3 due required to c++11 support. h2. Solution As a solution all custom detection of CUDA should be removed and if CUDA is used the minimum cmake version should be raised to 3.10 due to support of latest Volta architectures. [https://github.com/apache/incubator-mxnet/issues/12107] was: h2. Problem The current cmake CUDA support has multiple major problems. *Multiple not compatible definitions* CUDA can be part of cmake language detection and is not for older cmake versions. CUDA architectures can be detected by build-in cmake file. This would be preferred, but is not used by the current MXNet cmake scripts. CUDA is detected by 3 different files in the current cmake scripts and the choice of those is based on a obscure logic with involves different versions of cmake and platforms which it's building on * CMakeLists.txt * cmake/FirstClassLangCuda.cmake * 3rdparty/mshadow/cmake/Cuda.cmake *No support for new CUDA architectures or faulty detection* Only 3rdparty/mshadow/cmake/Cuda.cmake supports Volta architecture, but not in all circumstances. In a lot of situations the right architecture can not be detected properly and the script falls back to build all architectures bowing up both: build time and artefact size. cmake/FirstClassLangCuda.cmake is outdated and does not support Volta at all. *Confusing and misleading cmake user options* Currently USE_CUDA / USE_OLDCMAKECUDA. Some of them will do or not do what they supposed to based on cmake generator version and version of cmake. *Other problems with dependencies* For example the caffe integration raises the minimum required cmake version to 3.3 due required to c++11 support. h2. Solution As a solution all custom detection of CUDA should be removed and if CUDA is used the minimum cmake version should be raised to 3.10 due to support of latest Volta architectures. https://github.com/apache/incubator-mxnet/issues/12107 > Faulty CUDA detection with cmake > > > Key: MXNET-796 > URL: https://issues.apache.org/jira/browse/MXNET-796 > Project: Apache MXNet > Issue Type: Bug >Reporter: Anton Chernov >Priority: Major > > h2. Problem > The current cmake CUDA support has multiple major problems. > *Multiple not compatible definitions* > CUDA can be part of cmake language detection and is not for older cmake > versions. > CUDA architectures can be detected by build-in cmake file. This would be > preferred, but is not used by the current MXNet cmake scripts. > CUDA is detected by 3 different files in the current cmake scripts and the > choice of those is based on a obscure logic with involves different versions > of cmake and platforms which it's building on > * CMakeLists.txt > * cmake/FirstClassLangCuda.cmake > * 3rdparty/mshadow/cmake/Cuda.cmake > *No support for new CUDA architectures or faulty detection* > Only 3rdparty/mshadow/cmake/Cuda.cmake supports Volta architecture, but not > in all circumstances. > In a lot of situations the right architecture can not be detected properly > and the script falls back to build all architectures bowing up both: build > time and artefact size. >
[jira] [Updated] (MXNET-796) Faulty CUDA detection with cmake
[ https://issues.apache.org/jira/browse/MXNET-796?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Chernov updated MXNET-796: Description: h2. Problem The current cmake CUDA support has multiple major problems. *Multiple not compatible definitions* CUDA can be part of cmake language detection and is not for older cmake versions. CUDA architectures can be detected by build-in cmake file. This would be preferred, but is not used by the current MXNet cmake scripts. CUDA is detected by 3 different files in the current cmake scripts and the choice of those is based on a obscure logic with involves different versions of cmake and platforms which it's building on * CMakeLists.txt * cmake/FirstClassLangCuda.cmake * 3rdparty/mshadow/cmake/Cuda.cmake *No support for new CUDA architectures or faulty detection* Only 3rdparty/mshadow/cmake/Cuda.cmake supports Volta architecture, but not in all circumstances. In a lot of situations the right architecture can not be detected properly and the script falls back to build all architectures bowing up both: build time and artefact size. cmake/FirstClassLangCuda.cmake is outdated and does not support Volta at all. *Confusing and misleading cmake user options* Currently USE_CUDA / USE_OLDCMAKECUDA. Some of them will do or not do what they supposed to based on cmake generator version and version of cmake. *Other problems with dependencies* For example the caffe integration raises the minimum required cmake version to 3.3 due required to c++11 support. h2. Solution As a solution all custom detection of CUDA should be removed and if CUDA is used the minimum cmake version should be raised to 3.10 due to support of latest Volta architectures. https://github.com/apache/incubator-mxnet/issues/12107 was: h2. Problem The current cmake CUDA support has multiple major problems. *Multiple not compatible definitions* CUDA can be part of cmake language detection and is not for older cmake versions. CUDA architectures can be detected by build-in cmake file. This would be preferred, but is not used by the current MXNet cmake scripts. CUDA is detected by 3 different files in the current cmake scripts and the choice of those is based on a obscure logic with involves different versions of cmake and platforms which it's building on * CMakeLists.txt * cmake/FirstClassLangCuda.cmake * 3rdparty/mshadow/cmake/Cuda.cmake *No support for new CUDA architectures or faulty detection* Only 3rdparty/mshadow/cmake/Cuda.cmake supports Volta architecture, but not in all circumstances. In a lot of situations the right architecture can not be detected properly and the script falls back to build all architectures bowing up both: build time and artefact size. cmake/FirstClassLangCuda.cmake is outdated and does not support Volta at all. *Confusing and misleading cmake user options* Currently USE_CUDA / USE_OLDCMAKECUDA. Some of them will do or not do what they supposed to based on cmake generator version and version of cmake. *Other problems with dependencies* For example the caffe integration raises the minimum required cmake version to 3.3 due required to c++11 support. h2. Solution As a solution all custom detection of CUDA should be removed and if CUDA is used the minimum cmake version should be raised to 3.10 due to support of latest Volta architectures. > Faulty CUDA detection with cmake > > > Key: MXNET-796 > URL: https://issues.apache.org/jira/browse/MXNET-796 > Project: Apache MXNet > Issue Type: Bug >Reporter: Anton Chernov >Priority: Major > > h2. Problem > The current cmake CUDA support has multiple major problems. > *Multiple not compatible definitions* > CUDA can be part of cmake language detection and is not for older cmake > versions. > CUDA architectures can be detected by build-in cmake file. This would be > preferred, but is not used by the current MXNet cmake scripts. > CUDA is detected by 3 different files in the current cmake scripts and the > choice of those is based on a obscure logic with involves different versions > of cmake and platforms which it's building on > * CMakeLists.txt > * cmake/FirstClassLangCuda.cmake > * 3rdparty/mshadow/cmake/Cuda.cmake > *No support for new CUDA architectures or faulty detection* > Only 3rdparty/mshadow/cmake/Cuda.cmake supports Volta architecture, but not > in all circumstances. > In a lot of situations the right architecture can not be detected properly > and the script falls back to build all architectures bowing up both: build > time and artefact size. > cmake/FirstClassLangCuda.cmake is outdated and does not support Volta at all. > *Confusing and misleading cmake user options* > Currently USE_CUDA / USE_OLDCMAKECUDA. Some of them will do or not do what > they supposed to based on cmake generator
[jira] [Created] (MXNET-796) Faulty CUDA detection with cmake
Anton Chernov created MXNET-796: --- Summary: Faulty CUDA detection with cmake Key: MXNET-796 URL: https://issues.apache.org/jira/browse/MXNET-796 Project: Apache MXNet Issue Type: Bug Reporter: Anton Chernov h2. Problem The current cmake CUDA support has multiple major problems. *Multiple not compatible definitions* CUDA can be part of cmake language detection and is not for older cmake versions. CUDA architectures can be detected by build-in cmake file. This would be preferred, but is not used by the current MXNet cmake scripts. CUDA is detected by 3 different files in the current cmake scripts and the choice of those is based on a obscure logic with involves different versions of cmake and platforms which it's building on * CMakeLists.txt * cmake/FirstClassLangCuda.cmake * 3rdparty/mshadow/cmake/Cuda.cmake *No support for new CUDA architectures or faulty detection* Only 3rdparty/mshadow/cmake/Cuda.cmake supports Volta architecture, but not in all circumstances. In a lot of situations the right architecture can not be detected properly and the script falls back to build all architectures bowing up both: build time and artefact size. cmake/FirstClassLangCuda.cmake is outdated and does not support Volta at all. *Confusing and misleading cmake user options* Currently USE_CUDA / USE_OLDCMAKECUDA. Some of them will do or not do what they supposed to based on cmake generator version and version of cmake. *Other problems with dependencies* For example the caffe integration raises the minimum required cmake version to 3.3 due required to c++11 support. h2. Solution As a solution all custom detection of CUDA should be removed and if CUDA is used the minimum cmake version should be raised to 3.10 due to support of latest Volta architectures. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@mxnet.apache.org For additional commands, e-mail: issues-h...@mxnet.apache.org
[jira] [Created] (MXNET-679) Refactor handling BLAS libraries with cmake
Anton Chernov created MXNET-679: --- Summary: Refactor handling BLAS libraries with cmake Key: MXNET-679 URL: https://issues.apache.org/jira/browse/MXNET-679 Project: Apache MXNet Issue Type: Improvement Reporter: Anton Chernov Solve issues with lapack, add build instructions for CMake build options. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@mxnet.apache.org For additional commands, e-mail: issues-h...@mxnet.apache.org
[jira] [Created] (MXNET-621) Create a git-secrets git hook installation script
Anton Chernov created MXNET-621: --- Summary: Create a git-secrets git hook installation script Key: MXNET-621 URL: https://issues.apache.org/jira/browse/MXNET-621 Project: Apache MXNet Issue Type: Improvement Reporter: Anton Chernov Repeatedly by some users AWS secrets were compromised by committing them to public forks of MXNet. The problem is that the commits of secrets happen mostly in forks (not main MXNet repository), so no policy can be effectively enforced there. A local git-secrets git hook installation script should be created in mxnet repo with instructions in README how to call it. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@mxnet.apache.org For additional commands, e-mail: issues-h...@mxnet.apache.org
[jira] [Updated] (MXNET-286) libomp.so is missing in Docker builds for armv6
[ https://issues.apache.org/jira/browse/MXNET-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Chernov updated MXNET-286: Resolution: Fixed Status: Done (was: To Do) > libomp.so is missing in Docker builds for armv6 > > > Key: MXNET-286 > URL: https://issues.apache.org/jira/browse/MXNET-286 > Project: Apache MXNet > Issue Type: Bug >Reporter: Anton Chernov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > https://github.com/apache/incubator-mxnet/issues/10230 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@mxnet.apache.org For additional commands, e-mail: issues-h...@mxnet.apache.org
[jira] [Updated] (MXNET-287) ARMv6 build with 8-10 times bigger file size
[ https://issues.apache.org/jira/browse/MXNET-287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Chernov updated MXNET-287: Resolution: Fixed Status: Done (was: To Do) > ARMv6 build with 8-10 times bigger file size > > > Key: MXNET-287 > URL: https://issues.apache.org/jira/browse/MXNET-287 > Project: Apache MXNet > Issue Type: Bug >Reporter: Anton Chernov >Priority: Major > Time Spent: 1.5h > Remaining Estimate: 0h > > https://github.com/apache/incubator-mxnet/issues/10398 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@mxnet.apache.org For additional commands, e-mail: issues-h...@mxnet.apache.org
[jira] [Created] (MXNET-287) ARMv6 build with 8-10 times bigger file size
Anton Chernov created MXNET-287: --- Summary: ARMv6 build with 8-10 times bigger file size Key: MXNET-287 URL: https://issues.apache.org/jira/browse/MXNET-287 Project: Apache MXNet Issue Type: Bug Reporter: Anton Chernov https://github.com/apache/incubator-mxnet/issues/10398 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@mxnet.apache.org For additional commands, e-mail: issues-h...@mxnet.apache.org
[jira] [Created] (MXNET-286) libomp.so is missing in Docker builds for armv6
Anton Chernov created MXNET-286: --- Summary: libomp.so is missing in Docker builds for armv6 Key: MXNET-286 URL: https://issues.apache.org/jira/browse/MXNET-286 Project: Apache MXNet Issue Type: Bug Reporter: Anton Chernov https://github.com/apache/incubator-mxnet/issues/10230 -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: issues-unsubscr...@mxnet.apache.org For additional commands, e-mail: issues-h...@mxnet.apache.org
[jira] [Updated] (MXNET-115) USE_LAPACK is forced on all platforms with OpenBLAS and cmake
[
https://issues.apache.org/jira/browse/MXNET-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Chernov updated MXNET-115:
Description:
When building with cmake, MXNET_USE_LAPACK is inappropriately forced on all
platforms breaking the build if the library is not available.
{code:java}
tests/CMakeFiles/mxnet_unit_tests.dir/cpp/operator/krprod_test.cc.o: In
function `mxnet_lapack_dposv':
/work/mxnet/src/operator/contrib/../c_lapack_api.h:260: undefined reference to
`dposv_'
/work/mxnet/src/operator/contrib/../c_lapack_api.h:265: undefined reference to
`dposv_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_sgelqf':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:285: undefined reference
to `sgeqrf_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_sorglq':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:302: undefined reference
to `sorgqr_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dgelqf':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:286: undefined reference
to `dgeqrf_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dorglq':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:303: undefined reference
to `dorgqr_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_sgelqf':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:285: undefined reference
to `sgeqrf_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_sorglq':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:302: undefined reference
to `sorgqr_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dpotri':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:235: undefined reference
to `dpotri_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_spotri':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:234: undefined reference
to `spotri_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dpotrf':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:233: undefined reference
to `dpotrf_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_spotrf':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:232: undefined reference
to `spotrf_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dsyevd':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:323: undefined reference
to `dsyevd_'
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:323: undefined reference
to `dsyevd_'
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:323: undefined reference
to `dsyevd_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_ssyevd':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:322: undefined reference
to `ssyevd_'
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:322: undefined reference
to `ssyevd_'
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:322: undefined reference
to `ssyevd_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dgelqf':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:286: undefined reference
to `dgeqrf_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dorglq':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:303: undefined reference
to `dorgqr_'
collect2: error: ld returned 1 exit status
{code}
The corresponding cmake override is in root
[CMakeLists.txt|https://github.com/apache/incubator-mxnet/blob/master/CMakeLists.txt#L350-L359]:
{code:java}
# ---[ LAPack
if(USE_LAPACK AND NOT MSVC)
add_definitions(-DMXNET_USE_LAPACK=1)
list(APPEND mxnet_LINKER_LIBS lapack)
else(USE_LAPACK)
# Workaround for Windows until using new Jenkinsfile.
if(BLAS STREQUAL "Open" OR BLAS STREQUAL "open" OR USE_BLAS STREQUAL "Open"
OR USE_BLAS STREQUAL "open")
add_definitions(-DMXNET_USE_LAPACK=1)
endif()
endif()
{code}
This effectively forces the {{MXNET_USE_LAPACK}} define on all platforms
(USE_LAPACK=OFF, MSVC=ON / USE_LAPACK=OFF, MSVC=OFF) if the intent was actually
switching it off.
Right now the problem is that some python tests depend on the lapack functions.
h2. Possible solution
An API function should be introduced to tell the language binding if lapack (or
corresponding operators) is available and the tests should be skipped if not.
was:
When building with cmake, MXNET_USE_LAPACK is inappropriately forced on all
platforms breaking the build if the library is not available.
{code}
tests/CMakeFiles/mxnet_unit_tests.dir/cpp/operator/krprod_test.cc.o: In
function `mxnet_lapack_dposv':
/work/mxnet/src/operator/contrib/../c_lapack_api.h:260: undefined reference to
`dposv_'
/work/mxnet/src/operator/contrib/../c_lapack_api.h:265: undefined reference to
`dposv_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_sgelqf':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:285: undefined reference
to `sgeqrf_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_sorglq':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:302: undefined reference
to `sorgqr_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dgelqf':
[jira] [Updated] (MXNET-115) USE_LAPACK is forced on all platforms with OpenBLAS and cmake
[
https://issues.apache.org/jira/browse/MXNET-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Chernov updated MXNET-115:
Description:
When building with cmake, MXNET_USE_LAPACK is inappropriately forced on all
platforms breaking the build if the library is not available.
{code}
tests/CMakeFiles/mxnet_unit_tests.dir/cpp/operator/krprod_test.cc.o: In
function `mxnet_lapack_dposv':
/work/mxnet/src/operator/contrib/../c_lapack_api.h:260: undefined reference to
`dposv_'
/work/mxnet/src/operator/contrib/../c_lapack_api.h:265: undefined reference to
`dposv_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_sgelqf':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:285: undefined reference
to `sgeqrf_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_sorglq':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:302: undefined reference
to `sorgqr_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dgelqf':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:286: undefined reference
to `dgeqrf_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dorglq':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:303: undefined reference
to `dorgqr_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_sgelqf':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:285: undefined reference
to `sgeqrf_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_sorglq':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:302: undefined reference
to `sorgqr_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dpotri':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:235: undefined reference
to `dpotri_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_spotri':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:234: undefined reference
to `spotri_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dpotrf':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:233: undefined reference
to `dpotrf_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_spotrf':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:232: undefined reference
to `spotrf_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dsyevd':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:323: undefined reference
to `dsyevd_'
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:323: undefined reference
to `dsyevd_'
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:323: undefined reference
to `dsyevd_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_ssyevd':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:322: undefined reference
to `ssyevd_'
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:322: undefined reference
to `ssyevd_'
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:322: undefined reference
to `ssyevd_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dgelqf':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:286: undefined reference
to `dgeqrf_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dorglq':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:303: undefined reference
to `dorgqr_'
collect2: error: ld returned 1 exit status
{code}
The corresponding cmake override is in root
[CMakeLists.txt|https://github.com/apache/incubator-mxnet/blob/master/CMakeLists.txt#L350-L359]:
{code}
# ---[ LAPack
if(USE_LAPACK AND NOT MSVC)
add_definitions(-DMXNET_USE_LAPACK=1)
list(APPEND mxnet_LINKER_LIBS lapack)
else(USE_LAPACK)
# Workaround for Windows until using new Jenkinsfile.
if(BLAS STREQUAL "Open" OR BLAS STREQUAL "open" OR USE_BLAS STREQUAL "Open"
OR USE_BLAS STREQUAL "open")
add_definitions(-DMXNET_USE_LAPACK=1)
endif()
endif()
{code}
This effectively forces the {{MXNET_USE_LAPACK}} define on all platforms
(USE_LAPACK=OFF, MSVC=ON / USE_LAPACK=OFF, MSVC=OFF) if the intent was actually
switching it off.
Right now the problem is that some python tests depend on the lapack functions.
h3. Possible solution
An API function should be introduced to tell the language binding if lapack (or
corresponding operators) is available and the tests should be skipped if not.
was:
When building with cmake, MXNET_USE_LAPACK is inappropriately forced on all
platforms breaking the build if the library is not available.
{code}
tests/CMakeFiles/mxnet_unit_tests.dir/cpp/operator/krprod_test.cc.o: In
function `mxnet_lapack_dposv':
/work/mxnet/src/operator/contrib/../c_lapack_api.h:260: undefined reference to
`dposv_'
/work/mxnet/src/operator/contrib/../c_lapack_api.h:265: undefined reference to
`dposv_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_sgelqf':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:285: undefined reference
to `sgeqrf_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_sorglq':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:302: undefined reference
to `sorgqr_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dgelqf':
[jira] [Updated] (MXNET-115) USE_LAPACK is forced on all platforms with OpenBLAS and cmake
[
https://issues.apache.org/jira/browse/MXNET-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Chernov updated MXNET-115:
Description:
When building with cmake, MXNET_USE_LAPACK is inappropriately forced on all
platforms breaking the build if the library is not available.
{code}
tests/CMakeFiles/mxnet_unit_tests.dir/cpp/operator/krprod_test.cc.o: In
function `mxnet_lapack_dposv':
/work/mxnet/src/operator/contrib/../c_lapack_api.h:260: undefined reference to
`dposv_'
/work/mxnet/src/operator/contrib/../c_lapack_api.h:265: undefined reference to
`dposv_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_sgelqf':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:285: undefined reference
to `sgeqrf_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_sorglq':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:302: undefined reference
to `sorgqr_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dgelqf':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:286: undefined reference
to `dgeqrf_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dorglq':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:303: undefined reference
to `dorgqr_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_sgelqf':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:285: undefined reference
to `sgeqrf_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_sorglq':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:302: undefined reference
to `sorgqr_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dpotri':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:235: undefined reference
to `dpotri_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_spotri':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:234: undefined reference
to `spotri_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dpotrf':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:233: undefined reference
to `dpotrf_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_spotrf':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:232: undefined reference
to `spotrf_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dsyevd':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:323: undefined reference
to `dsyevd_'
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:323: undefined reference
to `dsyevd_'
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:323: undefined reference
to `dsyevd_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_ssyevd':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:322: undefined reference
to `ssyevd_'
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:322: undefined reference
to `ssyevd_'
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:322: undefined reference
to `ssyevd_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dgelqf':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:286: undefined reference
to `dgeqrf_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dorglq':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:303: undefined reference
to `dorgqr_'
collect2: error: ld returned 1 exit status
{code}
The corresponding cmake override is in root
[CMakeLists.txt|https://github.com/apache/incubator-mxnet/blob/master/CMakeLists.txt#L350-L359]:
{code}
# ---[ LAPack
if(USE_LAPACK AND NOT MSVC)
add_definitions(-DMXNET_USE_LAPACK=1)
list(APPEND mxnet_LINKER_LIBS lapack)
else(USE_LAPACK)
# Workaround for Windows until using new Jenkinsfile.
if(BLAS STREQUAL "Open" OR BLAS STREQUAL "open" OR USE_BLAS STREQUAL "Open"
OR USE_BLAS STREQUAL "open")
add_definitions(-DMXNET_USE_LAPACK=1)
endif()
endif()
{code}
This effectively forces the {{MXNET_USE_LAPACK}} define on all platforms
(USE_LAPACK=OFF, MSVC=ON / USE_LAPACK=OFF, MSVC=OFF) if the intent was actually
switching it off.
Right now the problem is that some python tests depend on the lapack functions.
Possible solution
An API function should be introduced to tell the language binding if lapack (or
corresponding operators) is available and the tests should be skipped if not.
was:
When building with cmake, MXNET_USE_LAPACK is inappropriately forced on all
platforms breaking the build if the library is not available.
{code:java}
tests/CMakeFiles/mxnet_unit_tests.dir/cpp/operator/krprod_test.cc.o: In
function `mxnet_lapack_dposv':
/work/mxnet/src/operator/contrib/../c_lapack_api.h:260: undefined reference to
`dposv_'
/work/mxnet/src/operator/contrib/../c_lapack_api.h:265: undefined reference to
`dposv_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_sgelqf':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:285: undefined reference
to `sgeqrf_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_sorglq':
/work/mxnet/src/operator/tensor/./.././c_lapack_api.h:302: undefined reference
to `sorgqr_'
libmxnet.a(la_op.cc.o): In function `MXNET_LAPACK_dgelqf':
