So I am trying to compile Bind with DLZ ( mysql ) support on CentOS 7
After doing
./configure --prefix=/usr --sysconfdir=/etc/bind --localstatedir=/var --mandir=/usr/share/man --infodir=/usr/share/info --enable-threads --enable-largefile --with-libtool --enable-shared --enable-static --with-openssl=/usr --with-gssapi=/usr --with-gnu-ld --with-dlz-postgres=no --with-dlz-mysql=yes --with-dlz-bdb=no --with-dlz-filesystem=yes --with-dlz-stub=yes --enable-ipv6
and
make
I get the error:
/opt/bind/bind-9.11.0-P3/lib/isc/.libs/libisc.so ../../lib/isc/.libs/libisc.so -lcrypto -L/usr/lib/mysql -lmysqlclient -lcrypt -lm -ldl -lz -lpthread
/usr/bin/ld: cannot find -lmysqlclient
collect2: error: ld returned 1 exit status
make[2]: *** [named] Error 1
make[2]: Leaving directory `/opt/bind/bind-9.11.0-P3/bin/named'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/opt/bind/bind-9.11.0-P3/bin'
make: *** [subdirs] Error 1
I have gotten it to work on one CentOS 7 box, however I installed all sorts of whacky stuff while trying to get it to work. I don't actually know why it compiles on that machine, and I would like to be able to replicate the process. So I created a fresh install of CentOS 7 and try and find out how to compile Bind with DLZ support. Bind 9.11.0-P3.
I have mariadb-libs installed and the /usr/lib64/mysql directory looks like this.
ll /usr/lib64/mysql/
total 16884
-rw-r--r--. 1 root root 2687 Nov 14 15:15 INFO_BIN
-rw-r--r--. 1 root root 170 Sep 12 2016 INFO_SRC
lrwxrwxrwx. 1 root root 17 Mar 29 16:40 libmysqlclient_r.so -> libmysqlclient.so
lrwxrwxrwx. 1 root root 20 Mar 29 16:40 libmysqlclient.so -> libmysqlclient.so.18
lrwxrwxrwx. 1 root root 24 Mar 29 16:40 libmysqlclient.so.18 -> libmysqlclient.so.18.0.0
-rwxr-xr-x. 1 root root 3135736 Nov 14 15:17 libmysqlclient.so.18.0.0
lrwxrwxrwx. 1 root root 15 Mar 29 16:40 libmysqld.so -> libmysqld.so.18
-rwxr-xr-x. 1 root root 14116296 Nov 14 15:17 libmysqld.so.18
-rwxr-xr-x. 1 root root 10474 Nov 14 15:14 mysqlbug
-rwxr-xr-x. 1 root root 6758 Nov 14 15:15 mysql_config
drwxr-xr-x. 2 root root 4096 Mar 29 16:40 plugin
The /usr/lib/mysql directory looks like this.
ll /usr/lib/mysql/
total 0
drwxr-xr-x. 2 root root 6 Mar 29 21:36 plugin
On the machine that Bind Compiles on the /usr/lib/mysql folder looks different, and when I do yum whatprovides on the other machine I get this result:
yum whatprovides /usr/lib/mysql/libmysqlclient.so.18.0.0
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: centos.mirror.ca.planethoster.net
* extras: centos.mirror.ca.planethoster.net
* updates: mirror.it.ubc.ca
* webtatic: us-east.repo.webtatic.com
1:mariadb-libs-5.5.52-1.el7.i686 : The shared libraries required for MariaDB/MySQL clients
Repo : base
Matched from:
Filename : /usr/lib/mysql/libmysqlclient.so.18.0.0
1:mariadb-libs-5.5.52-1.el7.x86_64 : The shared libraries required for MariaDB/MySQL clients
Repo : #base
Matched from:
Filename : /usr/lib/mysql/libmysqlclient.so.18.0.0
On the fresh install I have installed these mariadb packages.
yum list mariadb*
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* base: mirror.its.sfu.ca
* extras: centos.bhs.mirrors.ovh.net
* updates: mirror.its.sfu.ca
Installed Packages
mariadb.x86_64 1:5.5.52-1.el7 #base
mariadb-bench.x86_64 1:5.5.52-1.el7 #base
mariadb-devel.x86_64 1:5.5.52-1.el7 #base
mariadb-embedded.x86_64 1:5.5.52-1.el7 #base
mariadb-embedded-devel.x86_64 1:5.5.52-1.el7 #base
mariadb-libs.x86_64 1:5.5.52-1.el7 #base
mariadb-server.x86_64 1:5.5.52-1.el7 #base
mariadb-test.x86_64 1:5.5.52-1.el7 #base
Available Packages
Please help me figure out how to install Bind with DLZ support on CentOS 7!
Add 'LDFLAGS="-I/usr/include/mysql -L/usr/lib64/mysql"'
on to the ./configure command
like so
./configure --prefix=/usr --sysconfdir=/etc/bind --localstatedir=/var --mandir=/usr/share/man --infodir=/usr/share/info --enable-threads --enable-largefile --with-libtool --enable-shared --enable-static --with-openssl=/usr --with-gssapi=/usr --with-gnu-ld --with-dlz-postgres=no --with-dlz-mysql=yes --with-dlz-bdb=no --with-dlz-filesystem=yes --with-dlz-stub=yes --enable-ipv6 LDFLAGS="-I/usr/include/mysql -L/usr/lib64/mysql"
Related
Background: We produce a big Library Management System, the server parts written in C, compiled on Linux SLES 15 and deployed to ~100 customers. The version in question was compiled on SLES 15 SP2 a year ago, and our Internal IT Department updated meanwhile the Dev and QA hosts to SP3.
It turned out, that the libcrypt.so moved with this update from SP2 to SP3 to a new location, from /lib64 to /usr/lib64 and contains a new symbol:
strings /usr/lib64/libcrypt.so.1.1.0 | grep XCRYPT_2.0
XCRYPT_2.0
# rpm -q -f /usr/lib64/libcrypt.so.1
libcrypt1-4.4.15-150300.4.2.41.x86_64
# zypper info libcrypt1
Information for package libcrypt1:
----------------------------------
Repository : SLE-Module-Basesystem15-SP3-Updates
Name : libcrypt1
Version : 4.4.15-150300.4.2.41
Arch : x86_64
If you now compile a server application on SP3 and ship this to customers (as a fix for an urgent bug) who is still using SP2, these application are missing this symbol and do not start anymore:
/opt/lib/sisis/avserver/batch/bin/prg/BASTVL: /lib64/libcrypt.so.1: version `XCRYPT_2.0' not found (required by /opt/lib/sisis/avserver/batch/bin/prg/BASTVL)
# strings /lib64/libcrypt.so.1 | grep XCR
# strings /usr/lib64/libcrypt.so.1 | grep XCR
strings: '/usr/lib64/libcrypt.so.1': No such file
# rpm -q -f /lib64/libcrypt.so.1
glibc-2.26-13.48.1.x86_64
# rpm -q -f /usr/lib64/libcrypt.so.1
error: file /usr/lib64/libcrypt.so.1: No such file or directory
i.e. our internal update from SP2 to SP3, make it impossible to deliver fixes to customers running SP2, or they need update as well to SP3 before installing fixes, at least if libcrypt.so is involved.
Any comments or hints for a workaround?
At the end I compiled from source with
git clone https://github.com/besser82/libxcrypt.git
cd libxcrypt
./autogen.sh
./configure --prefix /usr/local/sisis-pap/libxcrypt
make
sudo make install
ls -l /usr/local/sisis-pap/libxcrypt/lib64
insgesamt 1300
-rw-r--r-- 1 root root 635620 26. Jul 14:09 libcrypt.a
-rwxr-xr-x 1 root root 945 26. Jul 14:09 libcrypt.la
lrwxrwxrwx 1 root root 17 26. Jul 14:09 libcrypt.so -> libcrypt.so.1.1.0
lrwxrwxrwx 1 root root 17 26. Jul 14:09 libcrypt.so.1 -> libcrypt.so.1.1.0
-rwxr-xr-x 1 root root 681656 26. Jul 14:09 libcrypt.so.1.1.0
lrwxrwxrwx 1 root root 10 26. Jul 14:09 libowcrypt.a -> libcrypt.a
lrwxrwxrwx 1 root root 11 26. Jul 14:09 libowcrypt.so -> libcrypt.so
lrwxrwxrwx 1 root root 13 26. Jul 14:09 libowcrypt.so.1 -> libcrypt.so.1
lrwxrwxrwx 1 root root 10 26. Jul 14:09 libxcrypt.a -> libcrypt.a
lrwxrwxrwx 1 root root 11 26. Jul 14:09 libxcrypt.so -> libcrypt.so
and pointed our application via LD_LIBRARY_PATH to use this version of libcrypt.so.1.
I'm writing some loadable modules for Zabbix, as such, compiling shared objects. I've written one which uses the MySQL C API to read some data from tables, it's fairly standard, and includes:
#include <my_global.h>
#include <mysql.h>
My gcc command looks like so (expanded mysql_config for clarity):
gcc -fPIC -shared -o zbx_mysql.so zbx_mysql.c -I/usr/lib64/mysql `mysql_config --cflags` -I/opt/zabbix/3.2/include -L/usr/lib64/mysql -lmysqlclient -lpthread -lm -lrt -ldl
Contents of /usr/lib64/mysql:
-rw-r--r-- 1 root root 21358968 Sep 13 17:15 libmysqlclient.a
lrwxrwxrwx 1 root root 20 Nov 19 23:19 libmysqlclient_r.so.18 -> libmysqlclient.so.18
lrwxrwxrwx 1 root root 24 Nov 19 23:19 libmysqlclient_r.so.18.1.0 -> libmysqlclient.so.18.1.0
lrwxrwxrwx 1 root root 20 Nov 19 23:19 libmysqlclient.so -> libmysqlclient.so.20
lrwxrwxrwx 1 root root 24 Nov 19 23:19 libmysqlclient.so.18 -> libmysqlclient.so.18.1.0
-rwxr-xr-x 1 root root 9580608 Sep 13 17:07 libmysqlclient.so.18.1.0
lrwxrwxrwx 1 root root 24 Nov 19 23:18 libmysqlclient.so.20 -> libmysqlclient.so.20.3.7
-rwxr-xr-x 1 root root 9884704 Sep 13 17:15 libmysqlclient.so.20.3.7
-rw-r--r-- 1 root root 44102 Sep 13 17:13 libmysqlservices.a
drwxr-xr-x 4 root root 28 Nov 19 23:18 mecab
drwxr-xr-x. 3 root root 4096 Nov 19 23:19 plugin
The .so compiles and runs fine on the dev box, but copying it to a box without mysql-devel installed yields the following error:
cannot load module "zbx_mysql.so": libmysqlclient.so.20: cannot open shared object file: No such file or directory
I can only assume this means that the libmysqlclient.so.20.so isn't being bundled into my .so. I'm pretty much a novice here, so if anyone can advise it'd be greatly appreciated.
Shared libraries aren't "bundled", that's why they're shared. The machine you're trying to run on obviously misses the library. Libraries typically aren't in the "-dev" or "-devel" packages.
On your typical *nix system, you can have multiple versions of the same shared library installed, but normally only one development package. If you have the dev package for mysql-client 20 installed, the compiled code will link against that version. If you want your compiled code to link against mysql-client 18, install the older version of the development package.
If you need to be independent of the libraries installed on your target system, one possibility would be to link a static library instead.
I'm using virsh attatch-disk to add a new device to a running guest under KVM:
# virsh attatch-disk <running-guest-id> --source c.raw --target vdb
the output is:
error: Failed to attach disk
error: Failed to open file 'c.raw': No such file or directory
But the new disk file is under the pwd:
ls -l
total 26653060
-rw-r--r--. 1 root root 8312913920 Jan 10 10:25 c.q
-rw-r--r--. 1 root root 53687091200 Jan 5 16:50 c.raw
-rw-r--r--. 1 root root 10759023104 Jan 6 02:14 c.VHD
why virsh open failed? I browsed libvirtd.log:
2017-01-14 15:22:00.954+0000: 2204: error : virStorageFileGetMetadataRecurse:952 : Failed to open file 'c.raw': No such file or directory
2017-01-14 15:22:08.310+0000: 2209: info : remoteDispatchAuthList:2432 : Bypass polkit auth for privileged client pid:1921,uid:0
What the log mean?
virsh --version
0.10.2
qemu-x86_64 -version
qemu-x86_64 version 2.4.1, Copyright (c) 2003-2008 Fabrice Bellard
I got the answer, you must use c.raw's Abs path, relative path are not handled by virsh.
I have Perl installed on Linux RHEL:
perl -v
This is perl 5, version 12, subversion 2 (v5.12.2) built for x86_64-linux-thread-multi
When I run command to see Perl modules installed:
find `perl -e 'print "#INC"'` -name '*.pm' -print
I can see for DBI:
/mu/sdk/perl/5.12.2-gcc443-rhel5-64/lib/DBI/DBD/Metadata.pm
/mu/sdk/perl/5.12.2-gcc443-rhel5-64/lib/DBI/DBD/SqlEngine.pm
/mu/sdk/perl/5.12.2-gcc443-rhel5-64/lib/DBD/mysql/GetInfo.pm
/mu/sdk/perl/5.12.2-gcc443-rhel5-64/lib/DBD/mysql.pm
/mu/sdk/perl/5.12.2-gcc443-rhel5-64/lib/Bundle/DBD/mysql.pm
And MySQL installed and running:
Server version: 5.6.26 MySQL Community Server (GPL)
I have 2 lines of code in a Perl Script:
use DBI;
my $dbh = DBI->connect("DBI:mysql:database=test;host=localhost","root", "pass");
Error that I see is:
$ perl mysql.pl
install_driver(mysql) failed: Can't load '/mu/sdk/perl/5.12.2-gcc443-rhel5-64/lib/auto/DBD/mysql/mysql.so' for module DBD::mysql: libmysqlclient.so.15: cannot open shared object file: No such file or directory at /mu/apps/perl/5.12.2-gcc443-rhel5-64/lib/DynaLoader.pm line 200.
at (eval 3) line 3
Compilation failed in require at (eval 3) line 3.
Perhaps a required shared library or dll isn't installed where expected
at mysql.pl line 2
$
I verified with YUM:
$ sudo yum install perl-DBD-MySQL
Setting up Install Process
Package perl-DBD-MySQL-4.013-3.el6.x86_64 already installed and latest version
Nothing to do
$
This is the list of /usr/lib64/mysql :
$ pwd
/usr/lib64/mysql
$ ls -lrth
/usr/lib64/mysql
total 14M
-rwxr-xr-x 1 root root 8.6M Jul 14 17:47 libmysqlclient.so.18.1.0*
-rwxr-xr-x 1 root root 2.7M Jul 14 17:49 libmysqlclient.so.16.0.0*
-rwxr-xr-x 1 root root 2.7M Jul 14 17:49 libmysqlclient_r.so.16.0.0*
lrwxrwxrwx 1 root root 24 Jul 27 18:23 libmysqlclient.so.18 -> libmysqlclient.so.18.1.0*
lrwxrwxrwx 1 root root 24 Jul 27 18:23 libmysqlclient_r.so.18.1.0 -> libmysqlclient.so.18.1.0*
lrwxrwxrwx 1 root root 20 Jul 27 18:23 libmysqlclient_r.so.18 -> libmysqlclient.so.18*
lrwxrwxrwx 1 root root 24 Jul 27 18:23 libmysqlclient.so.16 -> libmysqlclient.so.16.0.0*
lrwxrwxrwx 1 root root 26 Jul 27 18:23 libmysqlclient_r.so.16 -> libmysqlclient_r.so.16.0.0*
drwxr-xr-x 3 root root 4.0K Jul 27 18:23 plugin/
$
What should I do next?
How to configure this problematic (libmysqlclient.so.15) or there is some other problem?
I'm building Octave from sources in order to include the ATLAS libraries. Did I get them included correctly? I don't know what to expect from the Octave configure script. I find "-llapack" suspiciously generic.
./configure --with-lapack=/usr/local/atlas
Source directory: .
Installation prefix: /usr/local
C compiler: gcc -Wall -W -Wshadow -Wformat -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wwrite-strings -Wcast-align -Wcast-qual -g -O2 -pthread
C++ compiler: g++ -Wall -W -Wshadow -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -g -O2 -pthread
Fortran compiler: gfortran -O
Fortran libraries: -L/usr/lib/gcc/x86_64-linux-gnu/4.8 -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.8/../../.. -lgfortran -lm -lquadmath
Lex libraries:
LIBS: -lutil -lm
...
HDF5 libraries: -lhdf5
Java home: /usr/lib/jvm/java-7-openjdk-amd64
Java JVM path: /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server
Java CPPFLAGS: -I/usr/lib/jvm/java-7-openjdk-amd64/include -I/usr/lib/jvm/java-7-openjdk-amd64/include/linux
Java libraries:
LAPACK libraries: -llapack
LLVM CPPFLAGS:
LLVM LDFLAGS:
LLVM libraries:
Magick++ CPPFLAGS: -I/usr/include/GraphicsMagick
Magick++ LDFLAGS:
Magick++ libraries: -lGraphicsMagick++ -lGraphicsMagick
...
allusers#vbubuntu:~/Downloads/octave-3.8.1$ ll -R /usr/local/atlas/
/usr/local/atlas/:
total 16
drwxr-xr-x 4 root root 4096 May 25 23:01 ./
drwxr-xr-x 13 root root 4096 May 25 23:01 ../
drwxr-xr-x 3 root root 4096 May 25 23:01 include/
drwxr-xr-x 2 root root 4096 May 25 23:01 lib/
/usr/local/atlas/include:
total 60
drwxr-xr-x 3 root root 4096 May 25 23:01 ./
drwxr-xr-x 4 root root 4096 May 25 23:01 ../
drwxr-xr-x 2 root root 4096 May 25 23:01 atlas/
-rw-r--r-- 1 root root 33962 May 25 23:06 cblas.h
-rw-r--r-- 1 root root 9708 May 25 23:06 clapack.h
/usr/local/atlas/include/atlas:
total 604
drwxr-xr-x 2 root root 4096 May 25 23:01 ./
drwxr-xr-x 3 root root 4096 May 25 23:01 ../
-rw-r--r-- 1 root root 2089 May 25 23:06 atlas_buildinfo.h
-rw-r--r-- 1 root root 90 May 25 23:06 atlas_cacheedge.h
...
-rw-r--r-- 1 root root 2716 May 25 23:06 zmm.h
-rw-r--r-- 1 root root 552 May 25 23:06 zXover.h
/usr/local/atlas/lib:
total 26548
drwxr-xr-x 2 root root 4096 May 25 23:01 ./
drwxr-xr-x 4 root root 4096 May 25 23:01 ../
-rw-r--r-- 1 root root 14165306 May 25 23:06 libatlas.a
-rw-r--r-- 1 root root 455844 May 25 23:06 libcblas.a
-rw-r--r-- 1 root root 572392 May 25 23:06 libf77blas.a
-rw-r--r-- 1 root root 10942494 May 25 23:06 liblapack.a
-rw-r--r-- 1 root root 456426 May 25 23:06 libptcblas.a
-rw-r--r-- 1 root root 572788 May 25 23:06 libptf77blas.a
allusers#vbubuntu:~/Downloads/octave-3.8.1$
Additional info:
After spamming echo statements in the config file I've noticed the following:
This line:
$as_echo "$as_me:${as_lineno-$LINENO}: checking for $cheev in $LAPACK_LIBS" >&5
has the correct $LAPACK_LIBS variable in it (the one I passed in). It's this line that appears to be the first failure to find something in the lapack libraries I'm telling it about:
if ac_fn_c_try_link "$LINENO"; then :
Just before that line I see the config file define some c code that I believe it's running to identify whether whatever 'cheeve' is, is found in the libraries.
checking for cheev_ in /usr/local/atlas/lib/... no
checking for cheev_... no
checking for cheev_ in -llapack... yes
configuration script
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h. */
/* Override any GCC internal prototype to avoid an error.
Use char because int might match the return type of a GCC
builtin and then its argument prototype would still apply. */
#ifdef __cplusplus
extern "C"
#endif
char $cheev ();
#ifdef F77_DUMMY_MAIN
# ifdef __cplusplus
extern "C"
# endif
int F77_DUMMY_MAIN() { return 1; }
#endif
int
main ()
{
return $cheev ();
;
return 0;
}
_ACEOF
At this point the C code has gone beyond my comprehension level. It seems like it has something to do with whether the F77 compiler (compiler translator??) is being invoked or not.
Well, I think I worked this out after a marathon debugging session.
Octave doesn't appear to recognize the atlas libraries unless they're in shared format (.so files not the .a files that are generated by default).
When I build ATLAS with the --shared option added, and I reference the .so files generated by ATLAS, the Octave config script accepts them. Note: Make sure you use libtatlas.so, not libsatlas.so, assuming you want the multithreaded libraries.
Reference material:
ATLAS ./configure arguments:
../configure --shared -b 64 -D c -DPentiumCPS=3000 --with-netlib-lapack-tarfile=/home/allusers/Downloads/lapack-3.5.0.tgz
Octave ./configure arguments:
./configure --with-lapack=/usr/local/atlas/lib/libtatlas.so --with-blas=/usr/local/atlas/lib/libtatlas.so
Expected Octave ./configure output:
...
BLAS libraries: /usr/local/atlas/lib/libtatlas.so
...
LAPACK libraries: /usr/local/atlas/lib/libtatlas.so
...
Incorrect Octave ./configure output:
...
BLAS libraries: -lblas
...
LAPACK libraries: -llapack
...
My full build process for ATLAS and Octave:
ATLAS setup:
bunzip2 -c atlas3.10.x.tar.bz2 | tar xfm -
mv ATLAS atlas3.10.1
cd atlas3.10.1
mkdir build_vbubuntu
cd build_vbubuntu
sudo apt-get install gfortran f2c libcnf-dev # ???
../configure --shared -b 64 -D c -DPentiumCPS=3000 --with-netlib-lapack-tarfile=/home/allusers/Downloads/lapack-3.5.0.tgz
make build
make check # test serial routines
make ptcheck # check parallel routines
make time
sudo make install
Octave setup:
sudo apt-get build-dep octave
./configure --with-lapack=/usr/local/atlas/lib/libtatlas.so --with-blas=/usr/local/atlas/lib/libtatlas.so
sudo make install
Full disclosure: While I've written up this answer because I got octave to admit that the atlas libraries exist (and I don't want to forget to write it later), the end result is still not working, a large scale matrix multiplication doesn't use multiple cores. Hence, if the cause of that issue is related I may be back to edit this answer in the future.
My successful attempt to compile octave (3.8.2) on CENTOS including atlas:
(make sure to remove blas-devel and lapack-devel, just in case)
> yum install atlas-sse3.x86_64
> setenv LDFLAGS -L/usr/lib64/atlas-sse3
>./configure --with-lapack=-latlas --with-blas=-latlas --enable-jit
> make -j20
(as root)> make install
After configure you should see:
BLAS libraries: -lcblas -lf77blas -latlas
LAPACK libraries: -llapack