-
Notifications
You must be signed in to change notification settings - Fork 5.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
configure / make fail to find MKL on Ubuntu 20.04 #4262
Comments
Thanks a lot!
The script doesn't seem to have a separate variable for the MKL include
dir. But that setup still seems to fit the pattern, where
MKLROOT=/usr and MKLLIBDIR=/usr/lib/x86_64-linux-gnu.
@kkm is there any chance you could take a look at this at some point? We
should make it automatically work for Ubuntu.
…On Wed, Sep 9, 2020 at 5:47 AM Graham ***@***.***> wrote:
Steps to reproduce:
$ cat /etc/os-release
NAME="Ubuntu"
VERSION="20.04.1 LTS (Focal Fossa)"
[...]
$ sudo apt install intel-mkl-full gfortran libsox-dev [...etc]
$ git clone https://github.com/kaldi-asr/kaldi.git
$ ls -l /usr/lib/x86_64-linux-gnu/libmkl_*
$ ls -l /usr/include/mkl/
(i.e. they exist)
$ cd tools
$ extras/check_dependencies.sh
./extras/check_dependencies.sh: Intel MKL is not installed. Run extras/install_mkl.sh to install it.
[...]
I realised the approval of check_dependencies wasn't required to actually
make it work, so I just went ahead and made the tools, which worked fine.
But then MKL hit a snag again on building kaldi proper:
$ cd ../src
$ ./configure --shared
(doesn't work)
$ ./configure --shared --mkl-libdir=/usr/lib/x86_64-linux-gnu
(also doesn't work)
$ CXXFLAGS="-I/usr/include/mkl/" ./configure --shared --mkl-libdir=/usr/lib/x86_64-linux-gnu
MKL configured libs: -L/usr/lib/x86_64-linux-gnu -Wl,-rpath=/usr/lib/x86_64-linux-gnu -lmkl_intel_lp64 -lmkl_core -lmkl_sequential -ldl -lpthread -lm
MKL include directory: -I/usr/lib/x86_64-linux-gnu/../../include
Using Intel MKL as the linear algebra library.
mkl-test.cc:21:10: fatal error: mkl.h: No such file or directory
21 | #include <mkl.h>
| ^~~~~~~
compilation terminated.
***configure failed: Cannot validate the MKL switches ***
so, I patched ./configure:
diff --git a/src/configure b/src/configure
index e0ac02115..da1253e26 100755--- a/src/configure+++ b/src/configure@@ -266,6 +266,8 @@ configure_mkl_includes() {
local mklroot=$1 mkllibdir=$2
if [[ -d $mklroot/include ]]; then
echo "-I$1/include"+ elif [[ -d /usr/include/mkl ]]; then+ echo "-I/usr/include/mkl"
elif [[ -d $mkllibdir/../../include ]]; then
echo "-I$mkllibdir/../../include"
else
Now configure succeeds:
$ CXXFLAGS="-I/usr/include/mkl" ./configure --shared --mkl-libdir=/usr/lib/x86_64-linux-gnu
Configuring KALDI to use MKL.
[...]
MKL configured libs: -L/usr/lib/x86_64-linux-gnu -Wl,-rpath=/usr/lib/x86_64-linux-gnu -lmkl_intel_lp64 -lmkl_core -lmkl_sequential -ldl -lpthread -lm
MKL include directory: -I/usr/include/mkl
Using Intel MKL as the linear algebra library.
Intel(R) Math Kernel Library Version 2020.0.0 Product Build 20191122 for Intel(R) 64 architecture applications
[...]
but make then failed as it passed in a mandatory reference to an include
directory "$(MKLROOT)/include". So, I must confess at this point I lost
patience and patched kaldi.mk rather than figure out how it's made:
--- src/kaldi.mk 2020-09-08 20:50:00.000000001 +0100+++ src/kaldi.mk 2020-09-08 20:51:00.903004252 +0100@@ -49,17 +49,12 @@
ifndef OPENFSTLIBS
$(error OPENFSTLIBS not defined.)
endif-ifndef MKLROOT-$(error MKLROOT not defined.)-endif--MKLLIB ?= $(MKLROOT)/lib/intel64
CXXFLAGS = -std=c++11 -I.. -isystem $(OPENFSTINC) -O1 $(EXTRA_CXXFLAGS) \
-Wall -Wno-sign-compare -Wno-unused-local-typedefs \
-Wno-deprecated-declarations -Winit-self \
-DKALDI_DOUBLEPRECISION=$(DOUBLE_PRECISION) \- -DHAVE_EXECINFO_H=1 -DHAVE_CXXABI_H -DHAVE_MKL -I$(MKLROOT)/include \+ -DHAVE_EXECINFO_H=1 -DHAVE_CXXABI_H -DHAVE_MKL -I/usr/include/mkl \
-m64 -msse -msse2 -pthread \
-g
having done this, make finally succeeded and kaldi appears to have been
built completely successfully.
So at the least, the auto-detection is broken, and at worst the build
process simply can't cope with the include/library structure imposed by an
upstream Ubuntu install of intel-mkl.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#4262>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAZFLO34XGJXE6MU5SYMQP3SE2RATANCNFSM4RAR2X5A>
.
|
@kkm000 any time to work on this? |
Sorry, misstated the ticket. Yes, will fix.
|
@4gra, is it critical to use the repackaged MKL that comes with Ubuntu? It is much better to remove the |
It's not crucial, but I administer a large system which deploys these packages across many machines and it would make my life significantly easier if it gets along with as many upstream packages as possible. If not I'd have to distribute the MKL twice on those systems, which is obviously not great. |
My huge problem with Ubuntu has always been that they distribute a deluge
of updates, the system literally changes daily. Installing just *an* MKL
version might not cut it. I understand that a responsible cluster admin
would 'apt-mark hold' it, but don't expect that of an average user.
On the other hand, MKL is very stable and backward-compatible, and I do not
remember any issues from upgrading it (not that I do that often). Let me
see how Ubuntu has actually repackaged it.
|
@kkm000 (slightly off-topic but I somewhat agree. The deluge of updates for their own sake can be counterproductive and we hold many packages, MKL included, for a stable environment. We intend to stick to 20.04 LTS for some time, I hope its rate of churn will reduce over time.) |
Not until 22.04 LTS is released, in my sour experience. Then they trickle
down to security updates only.
I remember about your issue, just busy with other stuff. It would be great
to install MKL as a package without the need for an additional script, I
only need to figure out their packaging. I think the " intel-mkl-full" is a
"virtual" package with no files, but "Depends:" on the next version with a
strict equality, forcing the version upgrade. They upgrade it every time
new MKL packages hit their feed. I'm guessing, but it;s the same thing as
e.g. linux-image pseudo-package. At the least, a better idea would be to
install a specific version instead. You never know when Ubuntu decides to
upgrade your MKL..
I'd recommend the same with the kernel, because you never know if DKMS
would be able to compile the NVIDIA driver for the suddenly updated kernel.
Been there, done that. Security updates are important, but
just-because-it's-the-latest aren't much. The downside is that the removal
of the old package versions (those with the version in the name, like
"linux-image-5.8.0-0.bpo.2-amd64" becomes your responsibility.
|
Ubuntu 20.04+ packages an unknown 20.x MKL version. The installation in /opt/intel is still preferred, but if none were found or supplied by the user, the package is probes as well, the last in order of probing. Closes kaldi-asr#4262
Ubuntu 20.04+ packages an unknown 20.x MKL version. The installation in /opt/intel is still preferred, but if none were found or supplied by the user, the package is probed as well, the last in order of probing. Closes #4262
Thanks for your careful consideration. |
Sure. Did it work for you?
|
I'll be doing a slew of software updates in the next week or so, so I'll get back to you. |
Steps to reproduce:
I realised the approval of check_dependencies wasn't required to actually make it work, so I just went ahead and made the tools, which worked fine. But then MKL hit a snag again on building kaldi proper:
so, I patched
./configure
:Now
configure
succeeds:but
make
then failed as it passed in a mandatory reference to an include directory "$(MKLROOT)/include". So, I must confess at this point I lost patience and patchedkaldi.mk
rather than figure out how it's made:having done this,
make
finally succeeded and kaldi appears to have been built completely successfully.So at the least, the auto-detection is broken, and at worst the build process simply can't cope with the include/library structure imposed by an upstream Ubuntu install of intel-mkl.
The text was updated successfully, but these errors were encountered: