Package Base Details: mxnet

Git Clone URL: (read-only, click to copy)
Keywords: deep_learning deep_neural_networks distributed_systems machine_learning
Submitter: Godisemo
Maintainer: None
Last Packager: petronny
Votes: 11
Popularity: 0.043274
First Submitted: 2017-02-11 00:12 (UTC)
Last Updated: 2020-12-12 11:17 (UTC)

Pinned Comments

petronny commented on 2019-06-21 08:00 (UTC) (edited on 2019-06-25 07:24 (UTC) by petronny)

And about this package, I've splitted it into mxnet{,-cuda,-mkl}. And it will take lots of time and space to compile.

The pre-built binaries of mxnet{,-cuda,-mkl} and their dependencies can be found in arch4edu.

Latest Comments

carlosal1015 commented on 2021-12-21 01:27 (UTC)

Hi, I have the following message error:

/tmp/makepkg/mxnet/src/mxnet/include/mshadow/././bfloat.h:75:26: note: ‘class mshadow::bfloat::bf16_t’ declared here
   75 | class MSHADOW_ALIGNED(2) bf16_t {
      |                          ^~~~~~
In file included from /tmp/makepkg/mxnet/src/mxnet/include/mshadow/tensor.h:1075,
                 from /tmp/makepkg/mxnet/src/mxnet/include/mxnet/./base.h:33,
                 from /tmp/makepkg/mxnet/src/mxnet/include/mxnet/engine.h:34,
                 from /tmp/makepkg/mxnet/src/mxnet/src/operator/numpy/./../../common/utils.h:32,
                 from /tmp/makepkg/mxnet/src/mxnet/src/operator/numpy/./np_delete_op-inl.h:31,
                 from /tmp/makepkg/mxnet/src/mxnet/src/operator/numpy/
/tmp/makepkg/mxnet/src/mxnet/include/mshadow/./tensor_cpu-inl.h:157:13: warning: ‘void* memcpy(void*, const void*, size_t)’ writing to an object of type ‘class mshadow::bfloat::bf16_t’ with no trivial copy-assignment; use copy-assignment or copy-initialization instead [-Wclass-memaccess]
  157 |       memcpy(dst[y].dptr_, src[y].dptr_, sizeof(DType) * dst.size(1));
      |       ~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from /tmp/makepkg/mxnet/src/mxnet/include/mshadow/./base.h:299,
                 from /tmp/makepkg/mxnet/src/mxnet/include/mshadow/tensor.h:35,
                 from /tmp/makepkg/mxnet/src/mxnet/include/mxnet/./base.h:33,
                 from /tmp/makepkg/mxnet/src/mxnet/include/mxnet/engine.h:34,
                 from /tmp/makepkg/mxnet/src/mxnet/src/operator/numpy/./../../common/utils.h:32,
                 from /tmp/makepkg/mxnet/src/mxnet/src/operator/numpy/./np_delete_op-inl.h:31,
                 from /tmp/makepkg/mxnet/src/mxnet/src/operator/numpy/
/tmp/makepkg/mxnet/src/mxnet/include/mshadow/././bfloat.h:75:26: note: ‘class mshadow::bfloat::bf16_t’ declared here
   75 | class MSHADOW_ALIGNED(2) bf16_t {
      |                          ^~~~~~
ninja: build stopped: subcommand failed.
==> ERROR: A failure occurred in build().

gnaggnoyil commented on 2021-05-26 17:31 (UTC) (edited on 2021-05-26 17:31 (UTC) by gnaggnoyil)

The same gcc toolchain version incompability issue @olko had mentioned happens again now. This time it's cuda 11.3 using gcc10 to build while all other system dependencies such as opencv are built with gcc11, which in turn makes error like the following:

[627/630] Linking CXX executable im2rec
FAILED: im2rec
: && /opt/cuda/bin/g++ -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -Wall -Wno-unknown-pragmas -Wno-sign-compare -O3 -std=c++11 -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now CMakeFiles/im2rec.dir/tools/ -o im2rec -L/opt/cuda/lib64   -L/opt/cuda/targets/x86_64-linux/lib/stubs   -L/opt/cuda/targets/x86_64-linux/lib -Wl,-rpath,/opt/cuda/lib64/stubs:/opt/cuda/lib64:/home/gnaggnoyil-wsl/.cache/yay/mxnet/src/mxnet-cuda/build/3rdparty/openmp/runtime/src  -Wl,--whole-archive  libmxnet.a  -Wl,--no-whole-archive  -lcblas  -fopenmp  /usr/lib/  3rdparty/openmp/runtime/src/  -lpthread  -llapack
  /usr/lib/  -lcuda  /lib/  /usr/lib/  3rdparty/dmlc-core/libdmlc.a  /usr/lib/  /usr/lib/  /usr/lib/  /usr/lib/  -lpthread  /opt/cuda/lib64/  /opt/cuda/lib64/stubs/  /opt/cuda/lib64/stubs/  /opt/cuda/lib64/stubs/  /opt/cuda/lib64/stubs/  /opt/cuda/lib64/stubs/  /opt/cuda/lib64/stubs/  /opt/cuda/lib64/stubs/  /opt/cuda/lib64/  -ldl  -lrt  -lcudadevrt  -lcudart_static  -lrt  -lpthread  -ldl && :
/usr/sbin/ld: /usr/lib/ undefined reference to `std::__exception_ptr::exception_ptr::_M_release()@CXXABI_1.3.13'
/usr/sbin/ld: /usr/lib/ undefined reference to `std::__throw_bad_array_new_length()@GLIBCXX_3.4.29'
/usr/sbin/ld: /usr/lib/ undefined reference to `std::__exception_ptr::exception_ptr::_M_addref()@CXXABI_1.3.13'

stefan-zobel commented on 2020-10-12 12:27 (UTC) (edited on 2020-10-12 16:24 (UTC) by stefan-zobel)

Doesn't build for me (with error "invalid reference: 1.7.0.rc1")

==> Removing existing $srcdir/ directory...
==> Extracting sources...
  -> Creating working copy of mxnet git repo...
Cloning into 'mxnet'...
fatal: invalid reference: 1.7.0.rc1
==> ERROR: Failure while creating working copy of mxnet git repo
error making: mxnet (mxnet-mkl-cuda)

But it worked after I've changed the pkgver in PKGBUILD to 1.7.0:


hwkiller commented on 2020-02-26 18:42 (UTC)

I'm not currently using the AUR package, but is the linking error you see the same as:

[ 94%] Linking CXX executable im2rec
/bin/ld: libmxnet.a( undefined reference to symbol 'cblas_ssyrk'
/bin/ld: /usr/lib/ error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[2]: *** [CMakeFiles/im2rec.dir/build.make:103: im2rec] Error 1

? I'm trying to build with CUDA and openblas, using their from-source instructions [Because I want to use it for R, not for python, and it's just easier this way]. I'd like to know whether I'm hitting the same snag as you all.

olko commented on 2020-02-05 05:41 (UTC) (edited on 2020-02-05 05:43 (UTC) by olko)

Update: MXNet can not be build with support for CUDA because Arch Linux uses GCC-9 while CUDA-10.2 supports only GCC-8. The CUDA-10.2 pacakge in Arch Linux is statically linked to GCC-8.

Mixing GCC-8 and GCC-9 compilation units may result in UB.

We have to wait for NVIDIA to release a CUDA version with GCC-9 support (of course Arch Linux's default compiler should remain GCC-9 too).

olko commented on 2020-02-04 05:11 (UTC) (edited on 2020-02-04 05:13 (UTC) by olko)

I could compile apache-mxnet-1.5.1 from sources without patching on a upt-to-data arch installation (gcc-9.2, cuda-10.2).

mkdir build && cd bild


ninja -v

enables CUDA, NCCL, OpenCV, OpenMP, MKL (intel), CPP-API.

Seams that patching isn't necessary.

Unfortunately linking fails at a clean checkout of mxnet from github (because of C++-ABI incompatibility) ...

petronny commented on 2020-02-04 04:58 (UTC)

@olko Let's do the steps one by one.
I'm trying to enable opencv and migrate the build script to now.

olko commented on 2020-01-15 20:20 (UTC)

any update? currently the AUR package of MXNet is not usable :(

petronny commented on 2019-12-25 08:52 (UTC)

@olko I'll take a look next month.

olko commented on 2019-12-25 08:39 (UTC) (edited on 2019-12-25 13:40 (UTC) by olko)

@petronny Your mxnet package fails because of unmet dependencies to intel and mkl packages (so I used the upstream archive).

I got MXNet compiled with OpenCV + CUDA + MKL.

The problem was that Arch Linux provides the newest GCC version (9.2.0 at this time) and newer versions are more eager to generate warnings.

MXNet uses -Werror that causes compilation abortion. As a quick fix I removed -Werror from the cmake config for MKLDNN. But I'll provide a pull request upstream that eliminates the warnings.

My Steps:

  • download and extract the official MXNet 1.5.1 archive (apache-mxnet-src-1.5.1-incubating.tar.gz)

  • cd apache-mxnet-src-1.5.1-incubating

  • store cmake config ( as cmake_options.yml in apache-mxnet-src-1.5.1-incubating (I believe that USE_MKLML_MKL and USE_MKLDNN are automatically switched on if USE_MKL_IF_AVAILABLE is enabled)

  • apply OpenCV patch (OpenCV-flags in namespace cv)

  • apply MKLDNN patch (remove -Werror causing abort)

  • call ./ build

Please, provide a new AUR package that uses my configuration from above (e.g. CUDA + MKL enabled for MXNet).

ty, Oliver

petronny commented on 2019-12-24 05:28 (UTC)

@olko Because it doesn't build when I wrote the PKGBUILD.

If it's building now or you figure out how to make it build, I'm happy to merge your changes.

olko commented on 2019-12-23 20:50 (UTC)

Why is mxnet configured without support for OpenCV?

olko commented on 2019-12-23 20:49 (UTC)

Why is no mxnet-cuda-mkl provided?

zottelef commented on 2019-07-17 08:30 (UTC) (edited on 2019-07-17 08:30 (UTC) by zottelef)

@petronny: after many years using R and installing packages from source I feel numb.

I added the three lines, but the following error still persists:

In file included from
/usr/include/opencv4/opencv2/opencv.hpp:48:10: fatal error: opencv2/opencv_modules.hpp: No such file or directory
   48 | #include "opencv2/opencv_modules.hpp"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

petronny commented on 2019-07-11 05:50 (UTC) (edited on 2019-07-11 05:56 (UTC) by petronny)

@zottelef Adding these 3 lines before R CMD INSTALL R-package:

echo "PKG_CXXFLAGS+=$(CFLAGS)" >> R-package/src/Makevars
sed '1i#define CV_IMWRITE_JPEG_QUALITY cv::IMWRITE_JPEG_QUALITY' -i R-package/src/

under rpkg: in Makefile should work.

I can't find a file like mxnet_0.5.tar.gz to install, but I think mxnet has been installed. I can pass the tests with make rpkgtest.

zottelef commented on 2019-07-08 07:12 (UTC) (edited on 2019-07-08 07:13 (UTC) by zottelef)

There is still and error with the R CMD INSTALL R-package: fatal error: opencv2/opencv.hpp: No such file or directory
   39 | #include <opencv2/opencv.hpp>
      |          ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
Prepending opencv4 to the /home/fabio/.cache/pikaur/build/mxnet/src/mxnet/R-package/src/

gives this error:

In file included from
/usr/include/opencv4/opencv2/opencv.hpp:48:10: fatal error: opencv2/opencv_modules.hpp: No such file or directory
   48 | #include "opencv2/opencv_modules.hpp"
      |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.

but I cannot find the file that calls opencv2/opencv_modules.hpp and prepend opencv4. opencv_modules.hpp and opencv.hpp are in /usr/include/opencv4/opencv2/ (on my computer)

petronny commented on 2019-07-05 11:13 (UTC)

@zottelef I've looked into the R support.

At last, the document asks you to run

make rpkg

which is

        mkdir -p R-package/inst/libs
        cp src/io/image_recordio.h R-package/src
        cp -rf lib/ R-package/inst/libs
        mkdir -p R-package/inst/include
        cp -rf include/* R-package/inst/include
        cp -rf 3rdparty/dmlc-core/include/* R-package/inst/include/
        cp -rf 3rdparty/tvm/nnvm/include/* R-package/inst/include
        Rscript -e "if(!require(devtools)){install.packages('devtools', repo = '')}"
        Rscript -e "library(devtools); library(methods); options(repos=c(CRAN='')); install_deps(pkg='R-package', dependencies = TRUE)"
        cp R-package/dummy.NAMESPACE R-package/NAMESPACE
        echo "import(Rcpp)" >> R-package/NAMESPACE
        R CMD INSTALL R-package
        Rscript -e "if (!require('roxygen2')||packageVersion('roxygen2') < '5.0.1'){\
        Rscript -e "require(mxnet); mxnet:::mxnet.export('R-package'); warnings()"
        rm R-package/NAMESPACE
        Rscript -e "require(roxygen2); roxygen2::roxygenise('R-package'); warnings()"
        R CMD INSTALL R-package

So if you have lib/ I think there is no need to compile youself. Could you try skip the build and use the in the prebuilt binaires?

Packaging r-mxnet is a sort of nightmare to me since almost all r-* things are in AUR and I have to add them into my repository before packaging r-mxnet. But some of them are orphaned and maybe not well-maintained so I don't really want to add them into my repository. So could you try a local installation without building first?

zottelef commented on 2019-06-26 09:18 (UTC)

@petronny I am now using the pre-built binaries. However, since I would like to build the R package (as said before) I must compile locally and then add the commands I share with you.

petronny commented on 2019-06-26 06:55 (UTC) (edited on 2019-06-26 06:56 (UTC) by petronny)

@zottelef Well, I guess something has changed in vtk 8.2.0-4 which is now in [community-testing].

I will fix this when vtk 8.2.0-4 moves to [community]. For now you can build it with extra-x86_64-build or use the pre-built binaries which are also built with extra-x86_64-build.

zottelef commented on 2019-06-25 11:47 (UTC)


gcc7 7.4.1+20181207-4 vtk 8.2.0-4

petronny commented on 2019-06-25 07:26 (UTC) (edited on 2019-06-25 07:27 (UTC) by petronny)

@zottelef I just built mxnet in my build system last night with no error.

Which version of vtk and gcc are you using? I've checked the log of the build system. It is building against vtk-8.2.0-3 and gcc7-7.4.1+20181207-4.

BTW, I've updated the link to pre-built binaries.

zottelef commented on 2019-06-25 07:12 (UTC)

A new error raised (vtk related): /usr/bin/ld: /usr/lib/ undefined reference to `std::__cxx11::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> >::basic_ostringstream()@GLIBCXX_3.4.26' collect2: error: ld returned 1 exit status make: *** [Makefile:526: bin/im2rec] Error 1

zottelef commented on 2019-06-21 08:06 (UTC)

@petronny do not be in an hurry and take you time, man! Thanks for your work so far. It is highly appreciated. R packages it would be "thick gravy goodness"! :-)

petronny commented on 2019-06-21 08:00 (UTC) (edited on 2019-06-25 07:24 (UTC) by petronny)

And about this package, I've splitted it into mxnet{,-cuda,-mkl}. And it will take lots of time and space to compile.

The pre-built binaries of mxnet{,-cuda,-mkl} and their dependencies can be found in arch4edu.

petronny commented on 2019-06-21 07:58 (UTC)

@zottelef I'll try but since I never used R before, so I can't guarantee anything.

And I'm currently working on gcc8 so I'll start trying 2 weeks later.

zottelef commented on 2019-06-21 07:46 (UTC)

@petronny is it possible to include the compilation of the R package too?

zottelef commented on 2019-06-18 13:23 (UTC)

@petronny it compiled perfectly. Thanks

petronny commented on 2019-06-18 08:12 (UTC)

@zottelef You are using gcc 9.1.0-1 in the testing repository. You have to install gcc 8.3.0-1 in the core repository or install gcc7 from AUR and manually set CC to gcc-7 and CXX to g++-7 in PKGBUILD.

zottelef commented on 2019-06-18 08:08 (UTC)

@petronny. Yes. I update cuda today (cuda 10.1.168-2, for example NVIDIA (R) CUDA Debugger is 10.1 release), tried to install mxnet right now but the error remains the same: gcc version 9.1.0 (GCC)

petronny commented on 2019-06-18 05:08 (UTC)

@zottelef Do you have the latest cuda installed?

zottelef commented on 2019-06-17 09:29 (UTC) (edited on 2019-06-17 11:32 (UTC) by zottelef)

Got this error trying to compile mxnet:

/opt/cuda/bin/nvcc -std=c++11 -Xcompiler -D_FORCE_INLINES -O3 -ccbin g++ -Xcompiler "-DMSHADOW_FORCE_STREAM -Wall -Wsign-compare -O3 -DNDEBUG=1 -I/home/fabio/.cache/pikaur/build/mxnet/src/incubator-mxnet/3rdparty/mshadow/ -I/home/fabio/.cache/pikaur/build/mxnet/src/incubator-mxnet/3rdparty/dmlc-core/include -fPIC -I/home/fabio/.cache/pikaur/build/mxnet/src/incubator-mxnet/3rdparty/tvm/nnvm/include -I/home/fabio/.cache/pikaur/build/mxnet/src/incubator-mxnet/3rdparty/dlpack/include -I/home/fabio/.cache/pikaur/build/mxnet/src/incubator-mxnet/3rdparty/tvm/include -Iinclude -funroll-loops -Wno-unused-parameter -Wno-unknown-pragmas -Wno-unused-local-typedefs -msse3 -DMSHADOW_USE_F16C=0 -I/opt/cuda/include -DMSHADOW_USE_CBLAS=1 -DMSHADOW_USE_MKL=0 -DMSHADOW_RABIT_PS=0 -DMSHADOW_DIST_PS=0 -DMSHADOW_USE_PASCAL=0 -DMXNET_USE_OPENCV=1 -I/usr/include/opencv4 -fopenmp -DMXNET_USE_OPERATOR_TUNING=1 -DMXNET_USE_LAPACK -DMSHADOW_USE_CUDNN=1 -I/home/fabio/.cache/pikaur/build/mxnet/src/incubator-mxnet/3rdparty/cub -DMXNET_ENABLE_CUDA_RTC=1 -DMXNET_USE_NCCL=0 -DMXNET_USE_LIBJPEG_TURBO=0" -M -MT build/src/operator/nn/cudnn/cudnn_batch_norm_gpu.o src/operator/nn/cudnn/ >build/src/operator/nn/cudnn/cudnn_batch_norm_gpu.d In file included from /opt/cuda/include/cuda_runtime.h:83, from <command-line>:

/opt/cuda/include/crt/host_config.h:129:2: error: #error -- unsupported GNU version! gcc versions later than 8 are not supported! 129 | #error -- unsupported GNU version! gcc versions later than 8 are not supported!

vuvko commented on 2018-12-04 10:50 (UTC) (edited on 2018-12-04 10:59 (UTC) by vuvko)

As opencv4 renamed it's package name for pkg-config from opencv to opencv4 current version cannot be built.

Upd: seems changes in opencv API prevent mxnet from building. I'm getting errors about undefined constants:

tools/ In function ‘int main(int, char**)’: tools/ error: ‘CV_LOAD_IMAGE_COLOR’ was not declared in this scope int color_mode = CV_LOAD_IMAGE_COLOR; ^~~~~~~~~~~~~~~~~~~ tools/ note: suggested alternative: ‘CV_HAL_DFT_STAGE_COLS’ int color_mode = CV_LOAD_IMAGE_COLOR; ^~~~~~~~~~~~~~~~~~~ CV_HAL_DFT_STAGE_COLS tools/ error: ‘CV_INTER_LINEAR’ was not declared in this scope int inter_method = CV_INTER_LINEAR; ^~~~~~~~~~~~~~~ tools/ note: suggested alternative: ‘CV_INLINE’ int inter_method = CV_INTER_LINEAR; ^~~~~~~~~~~~~~~ CV_INLINE tools/ error: ‘CV_IMWRITE_PNG_COMPRESSION’ was not declared in this scope encode_params.push_back(CV_IMWRITE_PNG_COMPRESSION); ^~~~~~~~~~~~~~~~~~~~~~~~~~ tools/ error: ‘CV_IMWRITE_JPEG_QUALITY’ was not declared in this scope encode_params.push_back(CV_IMWRITE_JPEG_QUALITY); ^~~~~~~~~~~~~~~~~~~~~~~

nextAaron commented on 2018-11-14 19:20 (UTC)


I had the same problem but my patch is different:

diff --git a/src/operator/nn/cudnn/ b/src/operator/nn/cudnn/ index 26b3484eb..1162c0a3f 100644 --- a/src/operator/nn/cudnn/ +++ b/src/operator/nn/cudnn/ @@ -23,9 +23,9 @@ * \brief * \author Junyuan Xie */ -#include "./cudnn_algoreg-inl.h" #include <mxnet/base.h> #include <mxnet/ndarray.h> +#include "./cudnn_algoreg-inl.h"

#include <sstream> #include <unordered_map>

petronny commented on 2018-11-14 04:00 (UTC) (edited on 2018-11-14 04:01 (UTC) by petronny)

@nextAaron When I'm building v1.3.0, it raises some errors around the CUDA_CALL stuff.
But the git master branch builds successfully.
And there is only one commit changed that file after v1.3.0.
So I extracted this patch from that commit and named it cuda_call.patch.

I agree that it's not a good choice for the patch's name...
Any suggestions?

nextAaron commented on 2018-11-14 01:33 (UTC)

What's cuda_call.patch for?

petronny commented on 2018-11-09 06:33 (UTC)

@vuvko Thanks for pointing it out. Fixed now.

vuvko commented on 2018-06-28 12:08 (UTC)

Why package version is not used when cloning repository? Or is package versioning different from mxnet?

sl1pkn07 commented on 2018-04-28 17:09 (UTC)

about python:

sl1pkn07 commented on 2018-04-22 21:17 (UTC) (edited on 2018-04-23 18:10 (UTC) by sl1pkn07)

any help?

EDIT ( ok, with USE_F16C=0 seems workground the error (or -DCOMPILER_SUPPORT_MF16C=OFF if use cmake)

and test the python part, same fail (coredump) like other users, tested with cmake or make

roachsinai commented on 2018-03-26 21:37 (UTC)

Same issue :-(.

free(): invalid pointer /tmp/yaourt-tmp-roach/aur-mxnet/./PKGBUILD: 行 50: 20759 已放弃 (核心已转储)python build --with-cython ==> 错误: 在 build() 中发生一个错误。 正在放弃... ==> 错误:Makepkg 无法构建 .

domschl commented on 2018-03-04 09:42 (UTC)

I've had the same issue as @domanov. Build fails during python build with segmentation fault. Any suggestions what can be done to narrow this down?

petronny commented on 2018-03-04 08:15 (UTC)

Hi, @domanov I can't reproduce your problem. You can install the binary build from

domanov commented on 2018-03-02 17:27 (UTC) (edited on 2018-03-02 17:34 (UTC) by domanov)

Hi, I am not able to compile mxnet, it fails with segmentation error at the end when python

PKGBUILD: line 39: 17500 Segmentation error (core dump created) python build

Any hints?

asitdepends commented on 2018-02-11 15:01 (UTC)

It's strange. In my system the build is successful. If I remove cblas or -lcblas flag, I get the same error on 'cblas_ssyrk'. readelf -Ws /usr/lib/ | grep cblas_ssyrk confirms that the symbol is there and I believe the linking should be sucessful.

petronny commented on 2018-02-11 11:03 (UTC)

I have cblas and blas installed, still get the cblas_ssyrk error.

asitdepends commented on 2018-02-11 10:19 (UTC)

I guess you might not install cblas package. In Arch blas ( is a fortran library and cblas ( is a C library. from cblas package contains the symbol cblas_ssyrk and may solve your build problem. For the dependency, you are right. I had some trouble with openblas and numpy and I thought that it was a dependency problem. But it was my mistake and is not a dependency problem.

petronny commented on 2018-02-10 06:06 (UTC) (edited on 2018-02-10 06:12 (UTC) by petronny)

I get

ld: build/src/operator/tensor/la_op.o: undefined reference to symbol 'cblas_ssyrk'
/usr/lib/ error adding symbols: DSO missing from command line

with USE_BLAS=blas ADD_LDFLAGS=-lcblas USE_LAPACK=1. So I use openblas-lapack to build the package. And openblas-lapack doesn't break dependencies.

asitdepends commented on 2018-02-09 08:54 (UTC) (edited on 2018-02-09 16:07 (UTC) by asitdepends)

Cuda 9 does not support gcc 7 which is the default gcc in the current Arch linux. So we need gcc-6 as a dependency and flags CC=gcc-6 CXX=g++6 to compile the package.

Why openblas? The blas package in the official repository should be used (USE_BLAS=blas ADD_LDFLAGS=-lcblas). Openblas breaks several dependencies of the standard packages such as python-numpy. If one really needs openblas, it could modify the PKGBUILD and do appropriate preparations. This must be optional and the standard blas must be the default.

Godisemo commented on 2017-02-28 16:17 (UTC)

Eventually I think it could be a good idea to extract the mklml library to its own AUR package, and make it an optional dependency for this one.

Godisemo commented on 2017-02-28 16:07 (UTC) (edited on 2017-02-28 16:08 (UTC) by Godisemo)

You learn something new every day. Building in a chroot environment definitely helped to resolve dependency issues. I did not know about that either. I really appreciate your feedback, thank you! The PKGBUILD should be updated to work correctly now.

petronny commented on 2017-02-28 13:39 (UTC)

No, you will get: /usr/bin/ld: cannot find -lcuda if you build it with a clean chroot enviroment. See more: (I'm using a modified extra-x86_64-build to have cudnn in my custom repository)

Godisemo commented on 2017-02-27 19:12 (UTC)

Why would I need to add that to ldflags? Everything builds fine without it.

petronny commented on 2017-02-27 19:04 (UTC)

Thanks for reply. I'm not familiar with mxnet so I trust your decisions. And one more thing needs fixing in PKGBUILD: please add echo "ADD_LDFLAGS = -L/opt/cuda/lib64/stubs" >> in prepare() for "-lcuda"

Godisemo commented on 2017-02-27 16:24 (UTC)

@petronny I recall that is linked to and does not check for which I prefer. While my approach works, it might not be entirely correct. Removing -j$(nproc) is resonable, I didn't know you could set it in the makepkg config file. And wget should be in the makedepends. I could look into optdepends and different blas versions. In the current version of mxnet I dont think you can use intel-mkl together with mklml, which gives a huge performance benefit at least on my computer. Since I dont use any of hadoop, caffe or torch I can't really add the feature to the PKGBUILD since I have no way of confirming that it works. You can add it yourself if you need it, and send me a git diff and I will push it.

petronny commented on 2017-02-27 14:42 (UTC) (edited on 2017-02-27 19:03 (UTC) by petronny)

Is line 59: install -D "$srcdir/mklml/lib/" "$pkgdir/usr/lib/" correct? And I think you can remove the -j$(nproc) option in line 53. It should have been set in /etc/makepkg.conf. And wget should be in the makedepends cblas, openblas-lapack, atlas, intel-mkl should be detected and set in prepare(), and added to optdepends hadoop, caffe, torch should be added simliarly to opencv Please fix the PKGBUILD. PS. you can find some compiled packages, such as hadoop, caffe-git, torch in