Linux usr local lib ldconfig

ldconfig error:»is not a symbolic link» when using Linux loader

Inside /usr/local/lib/ there are three libraries that I use. I’ll call them here as lib1 , lib2 and lib3 . Now, when I do an ldd on my binary it results:

 lib1.so => not found lib2.so => not found lib3.so => /usr/local/lib/lib3.so (0x00216000) 

But all of them are in the same folder as /usr/local/lib/.so . Every time I run ldconfig , the same error appears:

/usr/local/lib/ is not a symbolic link 

 sudo egrep '\/usr\/local' /etc/ld.so.conf.d/* projectA.conf.old:/usr/local/projectA/lib local.conf:/usr/local/lib 

ld.so.conf only includes /etc/ld.so.conf.d/*.conf , so this *.old isn’t processed, and it refers to /usr/local/projectA/lib . After a time trying I deleted all lib1 and lib2 (at some point I tested it on binary’s folder), the same error occurs.

6 Answers 6

I ran into this issue with the Oracle 11R2 client. Not sure if the Oracle installer did this or someone did it here before I arrived. It was not 64-bit vs 32-bit, all was 64-bit.

The error was that libexpat.so.1 was not a symbolic link.

It turned out that there were two identical files, libexpat.so.1.5.2 and libexpat.so.1 . Removing the offending file and making it a symlink to the 1.5.2 version caused the error to go away.

Makes sense that you’d want the well-known name to be a symlink to the current version. If you do this, it’s less likely that you’ll end up with a stale library.

Yes. As he mentioned i also see identical files. Some one rename *.so to *.so.old and copied *.so from the latest driver same name(libmyodbc5w.so.old, libmyodbc5w.so). This could also lead into this issue. rm libmyodbc5w.so.old resolved the issue.

This fix applies to lots of different files (it happens a lot with CUDA related files). Essentially, delete the non-symbolic one and recreate it so it links to the latest version. So in this case cd to the directory where the file is found, call ls -a | grep libexpat , this will show the libexpat.so.1.5.2 and libexpat.so.1 . Call rm libexpat.so.1; ln -s libexpat.so.1.5.2 libexpat.so.1 . You may need to use sudo for this.

I simply ran the command below:

export LD_LIBRARY_PATH=/usr/lib/ 

Worked for me while installing Oracle 19c on RHEL7. The error was «/sbin/ldconfig: /lib64/libsnmp++.so.33 is not a symbolic link»

Why would that be the solution to the symlink problem?? Because if forces the search of a lib into another path, and it won’t meet the problem? But the missing symlink (due to a copy for instance) remains.

Solved, at least at the point of the question.

I searched in the web before asking, and there were no conclusive solution, the reason why this error is: lib1.so and lib2.so are not OK, very probably where not compiled for a 64 bit PC, but for a 32 bits machine otherwise lib3.so is a 64 bits lib. At least that is my hypothesis.

VERY unfortunately ldconfig doesn’t give a clean error message informing that it could not load the library, it only pumps:

ldconfig: /folder_where_the_wicked_lib_is/ is not a symbolic link

I solved this when I removed the libs not found by ldd over the binary. Now it’s easier that I know where lies the problem.

My ld version: GNU ld version 2.20.51, and I don’t know if a most recent version has a better message for its users.

Источник

Ldconfig самая полезная команда для новичков сборки в Linux

Рано или поздно любой из начинающих изучать Линукс сталкивается с такой задачей как сборка (компиляция) какого-либо пакета (программы) из исходных кодов (source code). Такая необходимость возникает довольно часто при обновлении программного продукта, либо его установки из CVS источников, либо вообще есть программные продукты которые не распространяются в package (rpm, deb) формате, а только в исходных кодах.

По сути дела задача довольно тривиальная и сводится, как правило, к набору команд ./configure; make; make install, да к тому-же весь процесс сборки и инсталяции подробно описывается в пояснительных файлах пакета, к примеру README, INSTALL, INSTALL-SOURCE, documentation, SOURCE и т.п., хотя это далеко не факт, что такие описания могут вообще присутствовать.

Все бы ничего, но, камнем преткновения при сборке становятся самые распространенные ошибки, звучащие к примеру так:

error while loading shared libraries: xxxx.so.0 cannot open shared object file no such file or directory

Все эти ошибки вызваны одним: Ваш сборщик объектных файлов не смог найти необходимых ему библиотек сопутствующих продуктов, необходимых для полной корректной сборки. Конечно, можно залезть в скрипт сборки и начать там ручками править пути к этим библиотекам, хотя за Вас это должен был сделать конфигуратор, но случается что и он то-же не панацея, вобщем это не наш путь, наша палочка-выручалочка утилита ldconfig, которая создает необходимые связки и формирует кэш динамических библиотек установленных в Вашем Линуксе.
Вам всего лишь необходимо отредактировать файл /etc/ld.so.config, в котором хранятся пути к необходимым библиотекам. К примеру, можно забить туда строки:

/usr/local/lib /usr/local/lib/mysql

и выполнить с консоли команду ldconfig, после которой эта утилита просмотрит указанные ей директории на наличие там библиотек и поместит ссылки на них в кэш.
Просмотреть, какие-же библиотеки в данный момент находятся в кэше можно командой:

И в ответ Вы получите длиннющий список, а поэтому, для более удобной конкретики, чтобы посмотреть, есть ли у Вас библиотеки от пакета mysql, можно так:

# ldconfig -p | grep mysql libmysqlclient.so.10 (libc6) => /usr/local/lib/mysql/libmysqlclient.so.10 libmysqlclient.so (libc6) => /usr/local/lib/mysql/libmysqlclient.so

Поначалу, в пору своей первобытности в Линуксе, сам неоднократно наступал на эти грабли, и мои друзья на них наступали, и друзья моих друзей получали эти шишки . и самое интересное, что пока, кроме Интернета, ни в одной книжке по Линукс я не встречал больших рекламных плакатов: «Изучите работу ldconfig. «, а стоило бы это кричать уже на первых страницах.

Короче, — берегите лоб, надеюсь я Вам помог в этом.

28 мая, 2007 , 15:36
handyblogger[at]gmail.com

Источник

🐧 Как использовать команду ldconfig в системах Linux

Команда ldconfig используется для того, чтобы сообщить системе о новом расположении разделяемых библиотек.

При этом используется информация, предоставленная конфигурационным файлом /etc/ld.so.conf.

Команда ldconfig создает базу данных кэша всех библиотек на основе конфигурационного файла.

Этот кэш обычно хранится в файле /etc/ld.so.cache.

Вот синтаксис команды ldconfig:

В следующей таблице описаны полезные опции команды ldconfig:

ОПЦИЯ	ОПИСАНИЕ
-v	Вывести дополнительную информацию.
-n	Использовать опцию командной строки для указания местоположения новых разделяемых библиотек. Пример: ldconfig -n /some/directory.
-f	Указать другой файл конфигурации, а не файл по умолчанию (/etc/ld.so.conf).
-p	Используется для вывода списка текущих библиотек, хранящихся в файле кэша.

Конфигурационный файл /etc/ld.so.conf

Основным конфигурационным файлом для разделяемых библиотек является файл /etc/ld.so.conf; однако, как правило, в этом файле есть только одна строка:

# cat /etc/ld.so.conf include ld.so.conf.d/*.conf

Строка include в этом файле указывает системе также использовать все файлы конфигурации в указанном каталоге.

В случае предыдущего примера это будут все файлы, которые заканчиваются на “.conf” в каталоге /etc/ld.so.conf.d.

Сам конфигурационный файл прост.

Он просто содержит каталог, в котором хранятся разделяемые библиотеки:

# more /etc/ld.so.conf.d/libiscsi-x86_64.conf /usr/lib64/iscsi # ls /usr/lib64/iscsi libiscsi.so.2 libiscsi.so.2.0.10900

Список кэшированных библиотек

Чтобы перечислить кэшированные библиотеки, вы можете использовать опцию -p команды ldconfig, как показано ниже:

# ldconfig -p | more 784 libs found in cache `/etc/ld.so.cache' p11-kit-trust.so (libc6,x86-64) => /lib64/p11-kit-trust.so libz.so.1 (libc6,x86-64) => /lib64/libz.so.1 libyaml-0.so.2 (libc6,x86-64) => /lib64/libyaml-0.so.2 libyajl.so.2 (libc6,x86-64) => /lib64/libyajl.so.2 libxtables.so.10 (libc6,x86-64) => /lib64/libxtables.so.10 libxslt.so.1 (libc6,x86-64) => /lib64/libxslt.so.1 libxshmfence.so.1 (libc6,x86-64) => /lib64/libxshmfence.so.1 libxml2.so.2 (libc6,x86-64) => /lib64/libxml2.so.2 libxmlrpc_util.so.3 (libc6,x86-64) => /lib64/libxmlrpc_util.so.3 libxmlrpc_server_cgi.so.3 (libc6,x86-64) => /lib64/libxmlrpc_server_cgi.so.3 libxmlrpc_server_abyss.so.3 (libc6,x86-64) => /lib64/libxmlrpc_server_abyss.so.3 .

Добавление новых библиотек с помощью ldconfig

Чтобы добавить в систему новые шаренные библиотеки, сначала нужно загрузить библиотеки в систему и поместить их в каталог.

После добавления новых библиотек необходимо создать конфигурационный файл в каталоге /etc/ld.so.conf.d, а затем выполнить команду ldconfig.

Все эти задачи следует выполнять от имени пользователя root:

# ls /usr/lib64/test mylib.so.1 # cat /etc/ld.so.conf.d/libtest.conf /usr/lib64/test # ldconfig

Если команда ldconfig выполнена успешно, вывода не будет.

Переменная LD_LIBRARY_PATH

Обычные пользователи не могут успешно выполнить команду ldconfig; однако, если обычный пользователь хочет использовать пользовательскую общую библиотеку, то он может загрузить этот файл в свой домашний каталог и использовать переменную LD_LIBRARY_PATH для указания местоположения файлов пользовательской библиотеки, как показано ниже:

$ ls /home/testuser/lib mylib.so.1 $ LD_LIBRARY_PATH=/home/testuser/lib

При полезном выполнении последняя команда не должна давать никакого результата.

Чтобы сделать это изменение постоянным, поместите команду LD_LIBRARY_PATH=/home/testuser/lib в файл ~/.bashrc.

$ vi ~/.bashrc LD_LIBRARY_PATH=/home/testuser/lib export LD_LIBRARY_PATH

Команда ldd

С помощью команды ldd можно посмотреть, какие общие библиотеки использует определенная команда.

Вот синтаксис команды ldd:

# ldd /bin/ls linux-vdso.so.1 => (0x00007ffee2b3f000) libselinux.so.1 => /lib64/libselinux.so.1 (0x00007ff5a6c22000) libcap.so.2 => /lib64/libcap.so.2 (0x00007ff5a6a1d000) libacl.so.1 => /lib64/libacl.so.1 (0x00007ff5a6814000) libc.so.6 => /lib64/libc.so.6 (0x00007ff5a6447000) libpcre.so.1 => /lib64/libpcre.so.1 (0x00007ff5a61e5000) libdl.so.2 => /lib64/libdl.so.2 (0x00007ff5a5fe1000) /lib64/ld-linux-x86-64.so.2 (0x00007ff5a6e49000) libattr.so.1 => /lib64/libattr.so.1 (0x00007ff5a5ddc000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007ff5a5bc0000)

Цель использования команды ldd – устранение проблем с кодом, который вы пишете.

Эта команда сообщает вам не только о том, какие библиотеки вызываются, но и о том, из какого каталога вызывается каждая библиотека.

Это может быть очень полезно, если библиотека ведет себя не так, как вы ожидаете.

В следующей таблице описаны полезные опции для команды ldd:

Опция	ОПИСАНИЕ
-v	Вывести дополнительную информацию.
-u	Отображение всех неиспользуемых прямых зависимостей.

Источник

Use shared libraries in /usr/local/lib

I have build some libraries from sources, and the files after make install are in /usr/local/lib For example, in my case I have the file libodb-2.2.so which is in this directory. However when I launch the executable that has linked with libodb , I got the error: error while loading shared libraries: libodb-2.2.so: cannont open shared object file: No such file or directory. Does it mean that I have build my executable not correctly ? or should I indicate the system that there may be some interesting libs in the folder /usr/local/lib also ? I’m using Ubuntu 12.04, Linux kernel 3.2.0-38-generic.

@DDS I suggest that you elaborate a bit more. You know it’s a collaborative site here. Please, indicate the way gdb would have helped in anyway with a link problem, for example. I am genuinely curious. At first your remark seems to me unrelated to the problem. But I may be wrong. Indeed I do not know enough gdb , and the loading of libraries.

@DDS Beginner at learning C programming, or at learning building on Linux? Please, be more precise. For example I was coming from Windows. That does not mean I don’t know C++. I tend to think your judgmental behaviour is not accurate. Even if it had been on SO, your behaviour will soon get the attention of moderators. Be aware of that. You are on a COLLABORATIVE site, of enthusiast programmers sharing useful knowledge. Not somewhere design to flatter your ego. (Don’t worry I have also been gently /reasonably bashed when I started SO, and I think that was a really good thing that happened).

Источник