В проекте Java я использую matrix-toolkits-java (MTJ) для эффективной матрицы умножение. Это зависит от netlib-java, который, в свою очередь, зависит от оптимизированной реализации BLAS и LAPACK. установлен на машине. Он специально ищет /usr/lib64/libblas.so.3 и /usr/lib64/liblapack.so.3, чтобы найти эти библиотеки.
При установке blas и lapack через Yum мы получаем символические ссылки /usr/lib64/libblas.so.3 и /usr/lib64/liblapack.so.3, указывающие на файлы .so из ссылок blas и lapack, установленных через Yum.
Теперь мы хотим использовать реализации, которые быстрее эталонных, в моем случае OpenBLAS. Независимо от того, компилирую ли я это сам или устанавливаю через Yum, в итоге получается /usr/lib64/libopenblas-r0.2.18.so.
Теперь, согласно любому руководству в Интернете, я должен заменить символические ссылки на эталонную реализацию символическими ссылками на реализацию OpenBLAS, в результате чего получится что-то вроде этого:
libblas.so.3 -> libopenblas-r0.2.18.so
liblapack.so.3 -> libopenblas-r0.2.18.so
Хорошо, я могу это сделать! Я могу сделать это через ln или через alternatives. И если я это сделаю, мой код с радостью использует быстрый OpenBLAS.
Однако, когда запускается ldconfig, мои удивительные символические ссылки исчезают, они перезаписываются эталонными установками BLAS и LAPACK. А то мой софт опять грустит и тормозит.
Итак, мой вопрос: как установить OpenBLAS на CentOS/Fedora таким образом, чтобы запуск ldconfig не разрушил его? Я не могу удалить пакеты blas и lapack, так как на них могут полагаться другие клиенты хоста. Скорее, я бы как-то заставил ОС понять, что OpenBLAS - это альтернатива blas и lapack.
