ldd not finding shared object (.so) for xerces - c++

I am trying to run a sample executable provided with Xalan C++ library, which requires a the Xerces C library. But I am not able to properly link the Xerces shared object file.
mike#ubuntu:~/Xalan-C_1_9_0-redhat_80-gcc_32/bin$ ldd SimpleXPathAPI
linux-gate.so.1 => (0xf7765000)
libxalan-c.so.19 => /home/mike/Xalan-C_1_9_0-redhat_80-gcc_32/lib/libxalan-c.so.19 (0xf7409000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf73ab000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf738e000)
libxerces-c.so.26 => not found
libxalanMsg.so.19 => /home/mike/Xalan-C_1_9_0-redhat_80-gcc_32/lib/libxalanMsg.so.19 (0xf7386000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf71d8000)
/lib/ld-linux.so.2 (0xf7768000)
libstdc++.so.5 => not found
libxerces-c.so.26 => not found
I included the location containing the libxerces-c.so in my LD_LIBRARY_PATH but ldd will not find it.
mike#ubuntu:~/Xalan-C_1_9_0-redhat_80-gcc_32/bin$ echo $LD_LIBRARY_PATH
/home/mike/Xalan-C_1_9_0-redhat_80-gcc_32/lib:/usr/local/lib
I even added a soft link to ensure the .26 is included.
mike#ubuntu:/usr/local/lib$ ls -l
total 98308
-rwxr-xr-x 1 root root 25560971 Aug 28 13:39 libxerces-c-3.1.so
-rw-r--r-- 1 root root 75080734 Aug 28 13:39 libxerces-c.a
-rwxr-xr-x 1 root root 962 Aug 28 13:39 libxerces-c.la
lrwxrwxrwx 1 root root 18 Aug 28 13:39 libxerces-c.so -> libxerces-c-3.1.so
lrwxrwxrwx 1 root root 14 Oct 21 10:31 libxerces-c.so.26 -> libxerces-c.so
drwxr-xr-x 2 root root 4096 Aug 28 13:39 pkgconfig
drwxrwsr-x 4 root staff 4096 Feb 18 2015 python2.7
drwxrwsr-x 3 root staff 4096 Feb 18 2015 python3.4
drwxr-xr-x 3 root root 4096 Jul 6 15:42 site_ruby
The first time I had this => not found issue with libxalan-c.so.19 I solved it by adding the location of that file to my LD_LIBRARY_PATH. So I can't figure out why the same fix is not working for the libxerces-c.so.26. Does anyone know what I'm doing wrong?

What does this produce:
cd /usr/local/lib
file -L ./libxerces-c.so.26
Chances are, this will print something like ELF 64-bit LSB shared object ..., in which case you are trying to point 32-bit executable at 64-bit libraries, and that doesn't work.
You need to download a 32-bit build of libxerces.

Related

is components version != package version normal when in cmake find_package?

my env:
cmake version 3.16.3
OpenSSL 1.1.0f 25 May 2017
cpp-httplib v0.7.0
my sysroot
-rw-r--r-- 1 developer developer 41292 Jan 14 2018 libcrypt.a
-rw-r--r-- 1 developer developer 3143988 Mar 29 2018 libcrypto.a
lrwxrwxrwx 1 developer developer 16 Mar 29 2018 libcrypto.so -> libcrypto.so.1.1
lrwxrwxrwx 1 developer developer 18 Mar 29 2018 libcrypto.so.1.0.0 -> libcrypto.so.1.0.2
-rwxrw-r-- 1 developer developer 1497376 Mar 29 2018 libcrypto.so.1.0.2
-rw-r--r-- 1 developer developer 1827956 Mar 29 2018 libcrypto.so.1.1
lrwxrwxrwx 1 developer developer 46 Mar 29 2018 libcrypt.so -> ../../../lib/arm-linux-gnueabihf/libcrypt.so.1
-rw-r--r-- 1 developer developer 269496 Oct 7 2017 libssl3.so
-rw-r--r-- 1 developer developer 490932 Mar 29 2018 libssl.a
lrwxrwxrwx 1 developer developer 13 Mar 29 2018 libssl.so -> libssl.so.1.1
-rwxrw-r-- 1 developer developer 320924 Mar 29 2018 libssl.so.1.0.2
-rw-r--r-- 1 developer developer 327952 Mar 29 2018 libssl.so.1.1
the CMakeLists.txt in cpp-httplib specifics that:
set(_HTTPLIB_OPENSSL_MIN_VER "1.1.1")
...
find_package(OpenSSL ${_HTTPLIB_OPENSSL_MIN_VER} COMPONENTS Crypto SSL QUIET)
...
target_link_libraries(${PROJECT_NAME} ${_INTERFACE_OR_PUBLIC}
OpenSSL::SSL OpenSSL::Crypto
)
I included cpp-httplib in my project, I built it and checked shared object with ldd, then I got
libssl.so.1.1 => /usr/lib/arm-linux-gnueabihf/libssl.so.1.1 (0x7572c000)
libcrypto.so.1.0.2 => /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.2 (0x75ac3000)
libcrypto.so.1.1 => /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.1 (0x754c6000)
I understand the version isn't matched exactly due to the EXACT option is not set.
but why libssl is linking to 1.1 only and libcrypto is linking to 1.0.2 and 1.1?

Undefined reference in libpangoft2

Recently I've installed GTK+ 3.22 and its dependencies:
GLib 2.50
Pango 1.40
Gdk-Pixbuf 2.36
Atk 2.22
GObject-Introspection 1.50
The installation was successful because I tried using some new features of GTK+ 3.22 in one of my Python projects and it worked. (Before the installation, if I tried using a new feature, Python would raise an exception)
I am also working on a game which is written in C++ and I'm using Cocos2d-x to create it. Before installing the above libraries, everything worked fine. After the new packages were installed, I built my game in CodeBlocks and the following error message was shown:
In file: /usr/local/lib/libpangoft2-1.0.so.0 undefined reference to 'pango_matrix_get_font_scale_factors'
After some research, I've found out from here that in Pango 1.37 the pango_matrix_get_font_scale_factors function was added which is exactly the function that my project cannot find. As mentioned above, I've installed Pango 1.40 as a requirement for GTK +3.22.
I've also tried installing libpangoft2-1.0-0 with apt-get install and the output was: libpangoft2-1.0-0 is already the newest version.
Out of curiosity I've also looked in /usr/local/lib to see if I can find the libpangoft2-1.0-0 library.
In /usr/local/lib I've ran the following command: ls -la | grep pango which gave me the following output:
-rwxr-xr-x 1 root staff 1095 Oct 30 14:08 libpango-1.0.la
lrwxrwxrwx 1 root staff 24 Oct 30 14:08 libpango-1.0.so -> libpango-1.0.so.0.4000.3
lrwxrwxrwx 1 root staff 24 Oct 30 14:08 libpango-1.0.so.0 -> libpango-1.0.so.0.4000.3
-rwxr-xr-x 1 root staff 1073136 Oct 30 14:08 libpango-1.0.so.0.4000.3
-rwxr-xr-x 1 root staff 1263 Oct 30 14:08 libpangocairo-1.0.la
lrwxrwxrwx 1 root staff 29 Oct 30 14:08 libpangocairo-1.0.so -> libpangocairo-1.0.so.0.4000.3
lrwxrwxrwx 1 root staff 29 Oct 30 14:08 libpangocairo-1.0.so.0 -> libpangocairo-1.0.so.0.4000.3
-rwxr-xr-x 1 root staff 216216 Oct 30 14:08 libpangocairo-1.0.so.0.4000.3
-rwxr-xr-x 1 root staff 1209 Oct 30 14:08 libpangoft2-1.0.la
lrwxrwxrwx 1 root staff 27 Oct 30 14:08 libpangoft2-1.0.so -> libpangoft2-1.0.so.0.4000.3
lrwxrwxrwx 1 root staff 27 Oct 30 14:08 libpangoft2-1.0.so.0 -> libpangoft2-1.0.so.0.4000.3
-rwxr-xr-x 1 root staff 397496 Oct 30 14:08 libpangoft2-1.0.so.0.4000.3
-rwxr-xr-x 1 root staff 1265 Oct 30 14:08 libpangoxft-1.0.la
lrwxrwxrwx 1 root staff 27 Oct 30 14:08 libpangoxft-1.0.so -> libpangoxft-1.0.so.0.4000.3
lrwxrwxrwx 1 root staff 27 Oct 30 14:08 libpangoxft-1.0.so.0 -> libpangoxft-1.0.so.0.4000.3
-rwxr-xr-x 1 root staff 157240 Oct 30 14:08 libpangoxft-1.0.so.0.4000.3
I tried reinstalling Pango 1.40, but the undefined reference error still persists.
I would also like to mention:
I am using Debian 8
Since installing GTK+ 3.22 my Nautilus looks like this, notice how I do not have icons (only some kind of replacement) next to the Close button and next to my HDDs (note that the black rectangles were added by me)
I am using i3 as a window manager
My question is, how can I solve the In file: /usr/local/lib/libpangoft2-1.0.so.0 undefined reference to 'pango_matrix_get_font_scale_factors' error?
Update
If I uninstall Pango 1.40 I do not get the error anymore, but GTK+ 3.22 will not work.
Update2
Maybe Pango 1.40.3 is not installed correctly. I described an interesting problem I am having here.

Qt build version from shared object

Suppose I have an executable that uses qt library. I want to replace the shared object with a custom one. So how do I find the qt version so that I can build it myself from source?
P.S. All the files has names like libQt5**.so.5.
If you don't own a very special setup the exact version is part of the lib name; all others are symlinks. E. g. installed here is Qt 4.8.1:
$ ls -l /usr/lib/i386-linux-gnu/libQtCore.*
-rw-r--r-- 1 root root 680 Mai 27 2015 /usr/lib/i386-linux-gnu/libQtCore.prl
lrwxrwxrwx 1 root root 18 Mai 27 2015 /usr/lib/i386-linux-gnu/libQtCore.so -> libQtCore.so.4.8.1
lrwxrwxrwx 1 root root 18 Mai 27 2015 /usr/lib/i386-linux-gnu/libQtCore.so.4 -> libQtCore.so.4.8.1
lrwxrwxrwx 1 root root 18 Mai 27 2015 /usr/lib/i386-linux-gnu/libQtCore.so.4.8 -> libQtCore.so.4.8.1
-rw-r--r-- 1 root root 2,9M Mai 27 2015 /usr/lib/i386-linux-gnu/libQtCore.so.4.8.1
Additionally the libs provide macros and functions to access the version at build and run time: QT_VERSION, QT_VERSION_STR and qVersion().

C++ Mongodb driver v2.2 scons install failed on Linux

I have install this driver for a long time, but failed. There is some failed infomation as following
# scons
Reading SConscript files ...
Checking for C++ library boost_thread-mt... no
Checking for C++ library boost_thread... no
# echo $LD_LIBRARY_PATH
/usr/lib:/usr/local/lib/:/usr/local/mpc/lib:/usr/local/gmp/lib:/usr/local/mpfr/lib/
# ls /usr/local/lib/libboost_thread* -l
-rw-r--r-- 1 root root 288364 Dec 28 18:16 /usr/local/lib/libboost_thread.a
lrwxrwxrwx 1 root root 40 Jan 1 13:05 /usr/local/lib/libboost_thread-mt.so -> /usr/local/lib/libboost_thread.so.1.52.0
lrwxrwxrwx 1 root root 25 Dec 28 18:10 /usr/local/lib/libboost_thread.so -> libboost_thread.so.1.52.0
-rwxr-xr-x 1 root root 186164 Dec 28 18:10 /usr/local/lib/libboost_thread.so.1.52.0
I have installed the boost v1.52, scons v2.2.0, and I want to install the mongodb C++ driver v2.2. Any Ideas? thanks very much.
The LD_LIBRARY_PATH environment variable affects where libraries are located at runtime, not at link time. The client driver SConstruct file provides an option --extrapath, which allows you to provide additional library search paths.
Try running:
scons --extrapath=/usr/local
to see if it will pick up boost libraries that you have installed in /usr/local.

mysqlclient library linkage problem

I am linking an application with mysqlclient library on 64-bit CentOS 5.4 and get a linkage error (cannot find -lmysqlclient).
The library is in /usr/lib64/mysql/:
una#localhost$ ll /usr/lib64/mysql/
total 9072
...
lrwxrwxrwx 1 root root 26 Jan 3 15:54 libmysqlclient_r.so -> libmysqlclient_r.so.15.0.0
lrwxrwxrwx 1 root root 26 Jan 3 15:54 libmysqlclient_r.so.15 -> libmysqlclient_r.so.15.0.0
-rwxr-xr-x 1 root root 1518456 Sep 4 01:28 libmysqlclient_r.so.15.0.0
lrwxrwxrwx 1 root root 24 Jan 3 15:54 libmysqlclient.so -> libmysqlclient.so.15.0.0
lrwxrwxrwx 1 root root 24 Jan 3 15:54 libmysqlclient.so.15 -> libmysqlclient.so.15.0.0
-rwxr-xr-x 1 root root 1514000 Sep 4 01:28 libmysqlclient.so.15.0.0
...
And the directory seems to be properly registered for Linux linker:
una#localhost$ cat /etc/ld.so.conf.d/mysql-x86_64.conf
/usr/lib64/mysql
The only way I can link the application on this machine is by specifying the full path to the library file which is unacceptable in my case.
What could cause the problem here?
Thanks.
-L/usr/lib64/mysql
The ld.so.conf stuff is only used at runtime, not compile time.
/usr/lib64/mysql is certainly not in your gcc's default search path. You may use a autoconf script to search for the installation path of libmysqlclient on this kind of a distribution, and dynamically use the found location with the -L flag.