We have a linux module developed by a 3rd party, now the module runs correctly on a Fedora system but on Ubuntu the same fails. When we do an ldd for the binary the following output is received
linux-gate.so.1 => (0xffffe000)
libdl.so.2 => /lib32/libdl.so.2 (0xf76f5000)
libc.so.6 => /lib32/libc.so.6 (0xf759b000)
/lib/ld-linux.so.2 (0xf7705000)
libutf16.so => not found
I am unable to find the library libutf16 for ubuntu, where can i find this library or is it part of a bigger library.
There is no file that contains libutf16 in its name in any package in Ubuntu 10.04.
Related
I'm trying to code a multithread application in Lazarus/free pascal, but I've noticed that when I include the "cthreads" lib (always the first line of my project.lpr file), on some Linux distros, I get a runtime error when running the application. I believe it's some broken library. However, I don't know how to identify it. Could you help me?
project1.lpr:
program project1;
uses
cthreads,
cmem;
begin
writeln('test');
end.
error:
[root#dockerinaja /]# ./project1
Runtime error 203 at $0000000000418D5C
$0000000000418D5C
$000000000040086D
ldd ./project1:
[root#dockerinaja /]# ldd /project1
linux-vdso.so.1 (0x00007ffc43fbd000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f359ff5e000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f359ff58000)
libc.so.6 => /lib64/libc.so.6 (0x00007f359fd92000)
/lib64/ld-linux-x86-64.so.2 (0x00007f359ff8b000)
I noticed that I had a very old version of Free Pascal. I just updated to version 3.2.0 and it fixed my problem. Thanks.
I first cross compile my Rust project to linux target
cargo build --target x86_64-unknown-linux-gnu
Then run ldd on my local ubuntu and the linker works fine.
linux-vdso.so.1 (0x00007fffddc62000)
libssl.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007f6d34500000)
libcrypto.so.1.0.0 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007f6d340b0000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6d33ea0000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f6d33c90000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6d33a70000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6d33850000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6d33440000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6d35a00000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6d330a0000)
But on my target os, ldd fails to find the libraries
libssl.so.1.0.0 => not found
libcrypto.so.1.0.0 => not found
/lib64/libc.so.6 => version `GLIBC_2.18' not found
Actually I have libssl.so.10 and libcrypto.so.10 installed under LD_LIBRARY_PATH. Unfortunately I am not able to install shared libraries of version 1.0.0 required by Rust.
I have read Rust Cross and the recommended solution is to install the missing shared libraries. Unfortunately that's not possible for me. So I am looking for alternative solutions to missing libraries.
libssl.so.1.0.0 and libcrypto.so.1.0.0 sound ancient. How can I tell cargo to use a later version?
How can I deal with /lib64/libc.so.6 => version GLIBC_2.18 not found?
According to this, GLIBC_2.18 can't be installed to RHEL7. I gave up dynamically linked libraries.
This post helped me out. The solution is:
[dependencies]
nats = "*"
protobuf = { version = "~2.0" }
# Add openssl-sys as a direct dependency so it can be cross compiled to
# x86_64-unknown-linux-musl using the "vendored" feature below
openssl-sys = "*"
[features]
# Force openssl-sys to staticly link in the openssl library. Necessary when
# cross compiling to x86_64-unknown-linux-musl.
vendored = ["openssl-sys/vendored"]
This way I can compile to a single executable with no library dependencies using:
cargo build --target=x86_64-unknown-linux-musl --features vendored
I am now trying to run some MATLAB code in Linux environment:
Linux version is Red Hat Enterprise Linux Server release 5.9 (Tikanga).
gcc version is 4.1.2.
MALTAB version is R2012b.
The statement in MALTAB that causes the problem is:
[status, result] = system('./vpdetection lines.tmp lines.out');
I got an error as follows:
./vpdetection: /gpfs/apps/x86_64-rhel5/matlab/R2012a/sys/os/glnxa64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found
I have googled several solutions but they all require editing system files.
Since I am running the code on server where I don't have sudo right to edit system files.
Are there any other workarounds that don't need to edit system files?
I have tried ldd command. The result is as follows:
[sxh415#cyberstar vpdetection]$ ldd matlab/vpdetection
matlab/vpdetection: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.9' not found (required by matlab/vpdetection)
matlab/vpdetection: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by matlab/vpdetection)
matlab/vpdetection: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by matlab/vpdetection)
linux-vdso.so.1 => (0x00007ffff7ff8000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003845400000)
libm.so.6 => /lib64/libm.so.6 (0x0000003840400000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003844c00000)
libc.so.6 => /lib64/libc.so.6 (0x0000003840000000)
/lib64/ld-linux-x86-64.so.2 (0x000000383fc00000)
/gpfs/apps/x86_64-rhel5/matlab/R2012a/sys/os/glnxa64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found
This error means: libstdc++.so.6 distributed with your version of Matlab is too old, and does not provide version `GLIBCXX_3.4.14'. The matlab version corresponds to gcc-4.5 or earlier, but you have some code that was compiled with gcc-4.6 (or later).
You must arrange for your executable to pick up a newer libstdc++.so.6.
I don't have sudo right to edit system files.
You could copy a sufficiently new version of libstdc++.so.6 to ~/lib64, then export LD_LIBRARY_PATH=$HOME/lib64.
Run ldd on your executable both inside MATLAB and outside on the system shell:
Shell
$ ldd ./vpdetection
MATLAB
>> !ldd ./vpdetection
To solve any dependency conflicts, try using LD_PRELOAD when launching either MATLAB itself or the executable:
$ LD_PRELOAD=/path/to/libstdc++.so matlab
or
>> system('LD_PRELOAD=/path/to/libstdc++.so ./vpdetection lines.tmp lines.out')
I have a bunch of software developed on Linux in C++ using g++. The code compiles and runs on both Ubuntu 12.04 and CentOS 5. We have a few older servers still running CentOS 5. Currently I compile for both OSes. I want to start using some C++11 features. These are supported on Ubuntu 12.04 but not CentOS 5.
I am trying to produce executables on Ubuntu for CentOS. Toward that end I have linked all the executables with
-Wl,-rpath,/home/arcamax/lib
That should tell it to look in /home/arcamax/lib for shared libs before the standard locations. I then used 'ldd' on the Ubuntu box to build a list of needed libraries and copied those libs to /home/arcamax/lib on the CentOS box. When I try to run the programs on the CentOS box I get:
When I run ldd on the CentOS5 box I get output like this:
libcrypto.so.1.0.0 => /home/arcamax/lib/libcrypto.so.1.0.0 (0x00002b3557f54000)
libpq.so.5 => /home/arcamax/lib/libpq.so.5 (0x00002b355831c000)
libstdc++.so.6 => /home/arcamax/lib/libstdc++.so.6 (0x00002b3558548000)
libm.so.6 => /home/arcamax/lib/libm.so.6 (0x00002b3558849000)
libgcc_s.so.1 => /home/arcamax/lib/libgcc_s.so.1 (0x00002b3558b43000)
libc.so.6 => /home/arcamax/lib/libc.so.6 (0x00002b3558d59000)
libpthread.so.0 => /home/arcamax/lib/libpthread.so.0 (0x00002b3559117000)
libdl.so.2 => /home/arcamax/lib/libdl.so.2 (0x00002b3559334000)
libz.so.1 => /home/arcamax/lib/libz.so.1 (0x00002b3559538000)
libssl.so.1.0.0 => /home/arcamax/lib/libssl.so.1.0.0 (0x00002b3559750000)
libkrb5.so.3 => /home/arcamax/lib/libkrb5.so.3 (0x00002b35599ac000)
libcom_err.so.2 => /home/arcamax/lib/libcom_err.so.2 (0x00002b3559c7a000)
libgssapi_krb5.so.2 => /home/arcamax/lib/libgssapi_krb5.so.2 (0x00002b3559e7f000)
libldap_r-2.4.so.2 => /home/arcamax/lib/libldap_r-2.4.so.2 (0x00002b355a0bd000)
/lib64/ld-linux-x86-64.so.2 (0x00000035aa800000)
libk5crypto.so.3 => /home/arcamax/lib/libk5crypto.so.3 (0x00002b355a30d000)
libkrb5support.so.0 => /home/arcamax/lib/libkrb5support.so.0 (0x00002b355a535000)
libkeyutils.so.1 => /home/arcamax/lib/libkeyutils.so.1 (0x00002b355a73d000)
libresolv.so.2 => /home/arcamax/lib/libresolv.so.2 (0x00002b355a942000)
liblber-2.4.so.2 => /home/arcamax/lib/liblber-2.4.so.2 (0x00002b355ab5e000)
libsasl2.so.2 => /home/arcamax/lib/libsasl2.so.2 (0x00002b355ad6c000)
libgssapi.so.3 => /home/arcamax/lib/libgssapi.so.3 (0x00002b355af88000)
libgnutls.so.26 => /home/arcamax/lib/libgnutls.so.26 (0x00002b355b1c6000)
libgcrypt.so.11 => /home/arcamax/lib/libgcrypt.so.11 (0x00002b355b482000)
libheimntlm.so.0 => /home/arcamax/lib/libheimntlm.so.0 (0x00002b355b701000)
libkrb5.so.26 => /home/arcamax/lib/libkrb5.so.26 (0x00002b355b908000)
libasn1.so.8 => /home/arcamax/lib/libasn1.so.8 (0x00002b355bb8e000)
libhcrypto.so.4 => /home/arcamax/lib/libhcrypto.so.4 (0x00002b355be2f000)
libroken.so.18 => /home/arcamax/lib/libroken.so.18 (0x00002b355c063000)
libtasn1.so.3 => /home/arcamax/lib/libtasn1.so.3 (0x00002b355c278000)
libp11-kit.so.0 => /home/arcamax/lib/libp11-kit.so.0 (0x00002b355c48a000)
libgpg-error.so.0 => /home/arcamax/lib/libgpg-error.so.0 (0x00002b355c69c000)
libwind.so.0 => /home/arcamax/lib/libwind.so.0 (0x00002b355c8a0000)
libheimbase.so.1 => /home/arcamax/lib/libheimbase.so.1 (0x00002b355caca000)
libhx509.so.5 => /home/arcamax/lib/libhx509.so.5 (0x00002b355ccd9000)
libsqlite3.so.0 => /home/arcamax/lib/libsqlite3.so.0 (0x00002b355cf23000)
libcrypt.so.1 => /home/arcamax/lib/libcrypt.so.1 (0x00002b355d1c7000)
Note there is one lib, /lib64/ld-linux-x86-64.so.2, that is still being pulled from a system location. I don't know why that is. When I try to run the program I get:
relocation error: /home/arcamax/lib/libgnutls.so.26: symbol time, version GLIBC_2.2.5 not defined in file libc.so.6 with link time reference
A few of the programs fail ldd with the message:
not a dynamic executable
Those programs report the same error as the others when I try to run them.
Don't compile on the system with the newer glibc. It will be very difficult or impossible to run them on the machine with the older glibc.
Instead you should compile on the older CentOS system and the binaries will happily run on the newer system.
I want to start using some C++11 features. These are supported on Ubuntu 12.04 but not CentOS 5.
No, they're supported by the GCC version that happens to be installed on Ubuntu 12.04, they're not supported by "Ubuntu". Install the same GCC version on the CentOS host and you can use C++11 features when you compile there.
Installing GCC is easy, just read that wiki page, and don't try to replace your system compiler i.e. install to /usr/local or /opt or $HOME or somewhere other than /usr
I'm attempting to get Pervasive v10 client ODBC working on Centos 6. As I've learned, there is no 64 bit ODBC client so I have to use the 32 bit one. I've finally gotten it to install without error but attempting usage gives the following:
# isql -v mydsn
[01000][unixODBC][Driver Manager]Can't open lib '/usr/local/psql/lib/odbcci.so' : file not found
[ISQL]ERROR: Could not SQLConnect
ldd shows this:
# ldd /usr/local/psql/lib/odbcci.so
linux-gate.so.1 => (0x007d3000)
libpscore.so.3 => /usr/local/psql/lib/libpscore.so.3 (0x00c32000)
libpscl.so.3 => /usr/local/psql/lib/libpscl.so.3 (0x005f9000)
libuuid.so.1 => /lib/libuuid.so.1 (0x0076d000)
libpthread.so.0 => /lib/libpthread.so.0 (0x00110000)
libdl.so.2 => /lib/libdl.so.2 (0x003e0000)
libstdc++.so.6 => /usr/local/psql/lib/libstdc++.so.6 (0x0012b000)
libm.so.6 => /lib/libm.so.6 (0x00876000)
libgcc_s.so.1 => /usr/local/psql/lib/libgcc_s.so.1 (0x00434000)
libc.so.6 => /lib/libc.so.6 (0x00954000)
/lib/ld-linux.so.2 (0x00f70000)
I just had a similar problem setting up ODBC and Pervasive for an Ubuntu client.
The reason it works after you su psql is because they install a .bashrc in the psql user account. The critical ingredient there for this question is export LD_LIBRARY_PATH=... which tells the dynamic linker where to find the library.
The error in the comments regarding the SQL Connection Manager is one I ran into as well:
[08S01][unixODBC][Pervasive][ODBC Client Interface][Client LNA]The ODBC Client Interface cannot access the data source because SQL Connection Manager is not running at the specified port number. Contact your system administrator for assistance.
I think Pervasive wants its own copy of the odbc.ini in its own etc directory. That dsnadd script probably does that. I didn't have dsnadd in the 64bit install, but I added a symlink from /etc/odbc.ini to /usr/local/psql/etc/odbc.ini and it worked.