Shared Library Search and Cache
Hello,
I'm posting this in the Fedora forum because that is the specific distribution I'm running, although I believe this is a fairly generic question. I'm trying to better understand how shared libraries are searched for. I have a library I am trying to work with that is looking for "libmysqlclient_r.so". I ran Code:
$ dnf provides */libmysqlclient_r.so After installing that, I have a new ld config file: /etc/ld.so.conf.d/mariadb-x86_64.conf With the contents Code:
/usr/lib64/mysql Code:
$ ls -l /usr/lib64/mysql/ I ran ldconfig and tried again with no change in the outcome. What is interesting is that if I look at the cache, that particular shared library is not listed: Code:
$ ldconfig -p | grep libmysqlclient How can I make it so that libmysqlclient_r.so is found when the system searches the shared libraries? A couple other notes: - I'm running Fedora 22 (x86_64) - The library I'm working with is a Common Lisp library, cl-mysql, which is attempting to load "libmysqlclient_r.so" via the c foreign function interface - If I change cl-mysql to look for just "libmysqlclient.so" instead, it works, however, I would still like to better understand what is going on here. Any help is greatly appreciated, Jason |
Generally libraries were in /lib, &/usr/lib. Now it's more likiely to be /lib64 & &/usr/lib64. If you drop s symlink to your lib in there, it will be found.
/etc/ld.so.conf usually tells the system where, and in what order to search for libs in other strange places. I see fedora used /etc/ld.so.conf.d/, so they apparently made a directory to dump lib assignments in. Useful when adding & deleting packages, which goes ona lot in fedora. |
Thank you, that does resolve the problem and I believe I understand why. However, I still don't understand why the links in /usr/lib64/mysql did not work.
From man ld.so: Quote:
However, I was expecting it to work without creating a link in /usr/lib64 because of the prior search item, the cache file. I assume that if I don't see the library in the output of Code:
$ ldconfig -p Again, my setup is as follows /etc/ld.so.conf Code:
include ld.so.conf.d/*.conf Code:
/usr/lib64/mysql Code:
$ ls -l /etc/lib64/mysql Code:
$ ldconfig -p | grep mysql |
Run ldconfig without the -p option to update the cache. You can add -v to see what it does.
|
I have been running ldconfig prior to printing out the contents of the cache.
Code:
$ sudo ldconfig -v | grep mysql Code:
$ ldconfig -p | grep mysql |
probably this link is incorrect: libmysqlclient.so.18 -> libmysqlclient_r.so
you need to link libmysqlclient_r.so -> libmysqlclient.so.18 |
Quote:
Code:
$ ls -l /usr/lib64/mysql |
return back to the original question: how did you try it, what was the original error?
you may try strace to check what's happening and also set LD_LIBRARY_PATH |
Quote:
I believe this is because ldconfig is not putting it into the shared library cache (it is not listed in ldconfig -p). I would like for this to work using ldconfig. Alternatives are: a.) Create a link in /usr/lib64 This works. I believe it works because it bypasses ldconfig all together. ld.so looks in /usr/lib64 as a last resort (man page quoted above). However, I don't like this as a solution because it brings me no further in understanding what is happening with ldconfig and because 6 months and a couple upgrades later when something isn't working, I am likely not going to remember to check on this link. b.) I haven't done so, but suspect setting LD_LIBRARY_PATH as you suggest would also work. But again, this is going around ldconfig. c.) I can also modify cl-mysql to link against libmysqlclient.so (instead of _r.so). This works, however I don't maintain cl-mysql and it could be in use on systems where there is a meaningful difference between libmysqlclient.so and libmysqlclient_r.so (the _r.so version is guaranteed to be reentrant). However, this is still an interesting result. libmysqlclient.so is being stored in the shared library cache. Why is libmysqlclient_r.so not? To be very specific, I would like to understand what is happening when I run ldconfig and build the cache. If libmysqlclient_r.so is not being cached by ldconfig, I would like to understand why. |
|
Yet another option is to add your path containing libmysqlclient_r.so to /etc/ld.so.conf, THRN run ldconfig
|
Quote:
Stil, to be sure, I modified my /etc/ld.so.conf file to look as follows Code:
/usr/lib64/mysql Code:
$ sudo ldconfig -v | grep mysql I grabed the glibc source to try to understand what ldconfig is doing, but there is too much preprocessor magic for me to tackle right now. |
One last possibility.
64 bit libs & 32 bit libs are incompatible. Run file on the lib, and the executble using it and check they are both 32 or 64 bit. |
Everything is 64-bit. The library I am working with is a common lisp library, so below I simply run file on the common lisp runtime, /usr/bin/sbcl.
Code:
$ file /usr/lib64/mysql/libmysqlclient_r.so To simplify the problem, I wrote a simple program that links against the mysql client library and calls my_init() https://dev.mysql.com/doc/refman/5.7/en/my-init.html Code:
#include <stdio.h> Code:
$ gcc -L/usr/lib64/mysql -lmysqlclient_r -I/usr/include/mysql -o mysql_test_init mysql_test_init.c So, to take it to the next step, I tried to write a simple program using dlopen. Code:
#include <stdlib.h> Code:
$ gcc -ldl -o mysql_test_dlopen mysql_test.c |
can you please add -pthread to gcc to compile and link things. Probably that will make sense. And also you can try to strace the last two commands you executed to see what is the difference.
|
All times are GMT -5. The time now is 06:43 PM. |