When I compile and link a .so file on my machine, it works. When I try to distribute the file to someone, they are getting errors.
To be more specific, I am building on:
-bash-3.00# uname -a
SunOS bob 5.10 Generic_127127-11 sun4u sparc SUNW,Sun-Blade-1000
-bash-3.00# CC -V
CC: Sun C++ 5.9 SunOS_sparc Patch 124863-01 2007/07/25
In the makefile, I am using these flags:
CFLAGS=-m64 -library=stlport4 -KPIC
LDFLAGS=-m64 -L/usr/lib/sparcv9 -lCrun -library=stlport4 -G
I am not seeing any errors on my machine, but this error is being report
ld.so.1: batch: fatal: relocation error: file lqtbatch: symbol __1cDstdMbasic_string4Ccn0ALchar_traits4Cc__n0AJallocator4Cc___2G6Mpkc_r1_: referenced symbol not found
Having a little trouble tracking down the reason, but here are a few differences I am seeing. On my machine, ldd -r batch:
ldd -r batch
libstlport.so.1 => /opt/SUNWspro/lib/stlport4/v9/libstlport.so.1
librt.so.1 => /lib/sparcv9/librt.so.1
libCrun.so.1 => /opt/SUNWspro/prod/lib/stlport4/v9/../../../usr/lib/v9/libCrun.so.1
libm.so.1 => /lib/64/libm.so.1
libc.so.1 => /lib/64/libc.so.1
libaio.so.1 => /lib/64/libaio.so.1
libmd.so.1 => /lib/64/libmd.so.1
/platform/SUNW,Sun-Blade-1000/lib/sparcv9/libc_psr.so.1
libm.so.2 => /lib/64/libm.so.2
/platform/SUNW,Sun-Blade-1000/lib/sparcv9/libmd_psr.so.1
Others are seeing this on the ldd -r command
libstlport.so.1 => /opt/SUNWspro/lib/stlport4/v9/libstlport.so.1
librt.so.1 => /lib/sparcv9/librt.so.1
libm.so.1 => /lib/64/libm.so.1
libc.so.1 => /lib/64/libc.so.1
libaio.so.1 => /lib/64/libaio.so.1
libmd.so.1 => /lib/64/libmd.so.1
symbol not found: __1cG__CrunKpure_error6F_v_ (./liblqtcr.so)
symbol not found: __1cG__CrunKpure_error6F_v_ (./liblqtcr.so)
...many of these...
symbol not found: __1cG__CrunKpure_error6F_v_ (./liblqtcr.so)
/platform/SUNW,SPARC-Enterprise-T2000/lib/sparcv9/libc_psr.so.1
symbol not found: __1cDstdMbasic_string4Ccn0ALchar_traits4Cc__n0AJallocator4Cc___2G6Mpkc_r1_ (./liblqtcr.so)
symbol not found: __1cDstdMbasic_string4Ccn0ALchar_traits4Cc__n0AJallocator4Cc___Gsubstr6kMLL_1_ (./liblqtcr.so)
libm.so.2 => /lib/64/libm.so.2
symbol not found: __1cDstdMbasic_string4Ccn0ALchar_traits4Cc__n0AJallocator4Cc___2G6Mrk1_r1_ (./liblqtcr.so)
symbol not found: __1cDstdMbasic_string4Ccn0ALchar_traits4Cc__n0AJallocator4Cc___Hreplace6MLLrk1_r1_ (./liblqtcr.so)
symbol not found: __1cDstdK_M_put_num4Ccn0ALchar_traits4Cc__Cb_6Frn0ANbasic_ostream3CTACTB__TC_4_ (./liblqtcr.so)
symbol not found: __1cDstdMbasic_string4Ccn0ALchar_traits4Cc__n0AJallocator4Cc___Gassign6MpkcL_r1_ (./liblqtcr.so)
/platform/SUNW,SPARC-Enterprise-T2000/lib/sparcv9/libmd_psr.so.1
My assumption is that I am incorrectly linking libCrun.so.1 which is causing these errors and causing the error on other machines.
Any help would be appreciated
LDFLAGS=-m64 -L/usr/lib/sparcv9 -lCrun ...
You should remove both the -L/usr/lib/sparcv9 and -lCrun from your LDFLAGS -- SunStudio will add them correctly all on its own.
My assumption is that I am incorrectly linking libCrun.so.1
No: you are linking with it correctly. The problem is that on the problem machine libCrun.so.1 is (apparently) not installed at all. That library should be installed by default -- no C++ application would normally run without it. You should find out what package libCrun.so.1 belongs to, and ask your client/customer to install it.
Related
Here's a simple hello world sha1-hasher that's using the openssl library.
#include <openssl/sha.h>
#include <stdio.h>
#include <stdlib.h>
int main()
{
system("printf '%s' 'hello world' | sha1sum");
unsigned char digest[SHA_DIGEST_LENGTH];
char digest_pr[(SHA_DIGEST_LENGTH)*2+1];
SHA_CTX ctx;
if(!SHA1_Init(&ctx)) return 1;
#define STR_STRLEN(A) A, (sizeof(A)/sizeof(*(A))-1)
if(!SHA1_Update(&ctx,STR_STRLEN("hello"))) return EXIT_FAILURE;
if(!SHA1_Update(&ctx,STR_STRLEN(" world"))) return EXIT_FAILURE;
if(!SHA1_Final(digest,&ctx)) return EXIT_FAILURE;
#define DIGITS "0123456789abcdef"
for(size_t i=0;i<sizeof(digest);i++){
digest_pr[i*2+0]=DIGITS[digest[i]/16];
digest_pr[i*2+1]=DIGITS[digest[i]%16];
}
digest_pr[(SHA_DIGEST_LENGTH)*2]='\0';
puts(digest_pr);
}
On a Mint/Ubuntu with libssl-dev installed, I can compile and link it with $CC sha.c (where CC is one of gcc, tcc, or clang) and then successfully run it, but this didn't work with musl so I grabbed the openssl source (git clone https://github.com/openssl/openssl), configured it with ./config --prefix=/usr/local/musl, built it and installed it and now musl-gcc sha.c -lcrypto works but running LD_LIBRARY_PATH=/usr/local/musl/lib a.out gets me:
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: __fprintf_chk: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: makecontext: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: setcontext: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: __register_atfork: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: __memcpy_chk: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: __strcat_chk: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: secure_getenv: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: __vfprintf_chk: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: __syslog_chk: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: __memset_chk: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: __fread_chk: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: getcontext: symbol not found
Error relocating /usr/local/musl/lib/libcrypto.so.1.1: __sprintf_chk: symbol not found
What's causing this and how can I fix it?
It seems that your OpenSSL is not built against musl-libc.
The musl-libc has its own dynamic linker (see https://wiki.musl-libc.org/faq.html), we could create a soft link for the musl dynamic linker. (-syslibdir is the directory in which the dynamic library, e.g. ld-musl-x86_64.so.1, is, see https://wiki.musl-libc.org/getting-started.html)
sudo ln -sf <YOUR-MUSL-LIBC-syslibdir/ld-musl-x86_64.so.1> /usr/bin/musl-ldd
Then you could see whether openssl is built against musl-libc. When I build OpenSSL using glibc, it shows the following error
$ musl-ldd <YOUR-OPENSSL-SRC>/libcrypto.so.1.1
musl-ldd (0x7fcd5a749000)
libdl.so.2 => musl-ldd (0x7fcd5a749000)
libpthread.so.0 => musl-ldd (0x7fcd5a749000)
libc.so.6 => musl-ldd (0x7fcd5a749000)
Error relocating ./libcrypto.so.1.1: makecontext: symbol not found
Error relocating ./libcrypto.so.1.1: setcontext: symbol not found
Error relocating ./libcrypto.so.1.1: __register_atfork: symbol not found
Error relocating ./libcrypto.so.1.1: getcontext: symbol not found
And the glib dynamic linker works fine,
$ ldd <YOUR-OPENSSL-SRC>/libcrypto.so.1.1
linux-vdso.so.1 (0x00007ffd395a6000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff6e6e64000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff6e6e41000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff6e6c4f000)
/lib64/ld-linux-x86-64.so.2 (0x00007ff6e71d7000)
To build OpenSSL using musl-libc, we have to also specify the location of linux headers to avoid errors like <linux/mman.h>
I only have attempted to build OpenSSL using Clang and Musl-libc, here is the clang wrapper I used https://gist.github.com/randoruf/d1aa4e8acb0a852addcd2b84fc003719.
(taken from https://qiita.com/kakinaguru_zo/items/399ab7ea716a56aef50c which is written by kakinaguru_zo)
But there are still a few issues in the clang-wrapper.
This wrapper will link the startfile (e.g. Scrt1.o) regardless of building libraries or executables. Apparently, only executables need startfile. Hence, if you use this wrapper, you may encounter the following strange error (main symbol not found):
$ musl-clang mylibrary.c -shared -fPIC -o libmylibrary.so
$ musl-ldd libmylibrary.so
ld-musl-x86_64.so.1 (0x7f49faef7000)
libc.so => ld-musl-x86_64.so.1 (0x7f49faef7000)
Error relocating libmylibrary.so: main: symbol not found
If the library has the startfile, it may have an entry to main. This is the reason why the main symbol is not found.
The solution is not to include startfile for shared libraries (the new clang wrapper should fix the problem).
Another issue is that test_errstr, test_ca, test_ssl_new will not pass due to the fact that the operating system and its software are built against glibc.
Details are posted on my blog https://randoruf.github.io/2022/08/23/musl-libc-ubuntu.html#about-the-test-case-in-openssl
The final issue is that this wrapper only supports c language. Another wrapper may be helpful see https://github.com/esjeon/musl-clang/blob/master/musl-clang
I compiled the original cwm tgz package (not the netbsd one) with
./configure
make
which works without error. After starting cwm with
./cwm
the error
Shared object "libX11.so.7" not found
appears. The ldd output is:
-lXft.2 => /usr/pkg/lib/libXft.so.2
-lfontconfig.1 => /usr/pkg/lib/libfontconfig.so.1
-lfreetype.7 => /usr/X11R7/lib/libfreetype.so.7
-lz.1 => /usr/lib/libz.so.1
-lgcc_s.1 => /usr/lib/libgcc_s.so.1
-lc.12 => /usr/lib/libc.so.12
-lbz2.1 => /usr/lib/libbz2.so.1
-lexpat.2 => /usr/lib/libexpat.so.2
-lXrender.2 => /usr/X11R7/lib/libXrender.so.2
-lXext.7 => /usr/X11R7/lib/libXext.so.7
-lX11.7 => /usr/X11R7/lib/libX11.so.7
-lxcb.1 => /usr/X11R7/lib/libxcb.so.1
-lXau.7 => /usr/X11R7/lib/libXau.so.7
-lXdmcp.7 => /usr/X11R7/lib/libXdmcp.so.7
-lX11.7 => not found
-lXext.7 => not found
where the "not founds" refer to the cwm binary directly. It has been linked with the command
gcc -Wall -Icompat -D_REENTRANT -I/usr/pkg/include\
-I/usr/X11R7/include/freetype2 -I/usr/X11R7/include\
-I/usr/X11R7/include/freetype2 -I/usr/X11R7/include -g -O2\
-I/usr/X11R7/include -o cwm calmwm.o draw.o screen.o xmalloc.o\
client.o grab.o search.o util.o xutil.o conf.o input.o xevents.o\
group.o geographic.o kbfunc.o cursor.o font.o -L/usr/pkg/lib\
-Wl,-R/usr/pkg/lib -lXft -L/usr/X11R7/lib -lX11 -lXext
so the linker should find libX11 and libXext.
Why does the loader complain?
The obvious portion is that ``-Wl,-R/usr/X11R7/lib'' was not included on the loader command line at link time.
NetBSD's runtime loader (/libexec/ld.elf_so) has only the runtime library search path of ``/lib:/usr/lib'' compiled in, so any executable needing additional elements on the search path needs to explicitly add them at compile time. (like the entry for /usr/pkg/lib.)
I installed glibc-2.18 into my home directory and want to link an application against it:
$ g++ -pthread -o tsx_test tsx_test.cpp -Wl,--rpath=/home/hl/lib/ \
-Wl,--dynamic-linker=/home/hl/lib/ld-linux-x86-64.so.2
Compiling and linking works fine using g++4.7.3, however, fails when executing it:
$ ./tsx_test
./tsx_test: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
/usr/lib/x86_64-linux-gnu/libstdc++.so.6 definitely exists, when I compile without "--rpath" the same libstdc++.so.6 is linked and everything works fine.
$ ldd tsx_test
linux-vdso.so.1 => (0x00007fff42bd4000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f42aa3aa000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f42aa194000)
libpthread.so.0 => /home/hl/lib/libpthread.so.0 (0x00007f42a9f75000)
libc.so.6 => /home/hl/lib/libc.so.6 (0x00007f42a9bc8000)
libm.so.6 => /home/hl/lib/libm.so.6 (0x00007f42a98c5000)
/home/hl/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f42aa6c9000)
/usr/lib/x86_64-linux-gnu/libstdc++.so.6 definitely exists
... but your libc doesn't look there.
You can set your RPATH like so: -Wl,-rpath=/home/hl/lib:/usr/lib, or you can edit /home/hl/etc/ld.so.conf and tell your libc to look in /usr/lib (after /home/hl/lib).j
Is it a permission problem, can't I mix root owned and user owned libs?
No. You can definitely mix and match root-owned and user-owned libraries.
So maybe this is me exposing my naivety in terms of linking and compiling.
I'm trying to compile some Fortran code such that it can run as a stand alone binary. One issue (among several) is that I want to compile on a system with GLIBC 2.14 but run on one with 2.11. Is it possible to statically link in libraries like GLIBC, or is that impossible because of the library's size?
My Makefile uses -static, -static-libgcc, and -static-libgfortran flags and the following compiler flags
-c -cpp -fall-intrinsics -ffpe-trap=invalid,zero -std=f2003
However, when I use ldd on the output, I get
linux-vdso.so.1 => (0x00007fff13b63000)
libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00007febfd7cf000)
libm.so.6 => /lib64/libm.so.6 (0x00007febfd578000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007febfd362000)
libquadmath.so.0 => /usr/lib64/libquadmath.so.0 (0x00007febfd12c000)
libc.so.6 => /lib64/libc.so.6 (0x00007febfcd9c000)
/lib64/ld-linux-x86-64.so.2 (0x00007febfdae7000)
Update
The machine I'm compiling on is running openSUSE 12.2:
Linux 3.4.33-2.24-desktop #1 SMP PREEMPT x86_64 x86_64 x86_64 GNU/Linux
While the machine I'm trying to execute on is openSUSE 11.4:
Linux 2.6.37.6-24-desktop #1 SMP PREEMPT x86_64 x86_64 x86_64 GNU/Linux
Update 2
I've re-written the makefile, and I'm trying to compile with ifort (the intel compiler) because it provides the static-intel flag which reduces some of the dependencies.
My ldd output is now
linux-vdso.so.1 => (0x00007fff381ff000)
libm.so.6 => /lib64/libm.so.6 (0x00007f89b07cf000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f89b05b2000)
libc.so.6 => /lib64/libc.so.6 (0x00007f89b0222000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f89b001e000)
/lib64/ld-linux-x86-64.so.2 (0x00007f89b0a26000)
Using the following compiler flags
FCFLAGS = -cpp -static-intel -static-libgcc
The problem is if I do just -static (or -static-intel -static) then I get
ld: cannot find -lm
ld: cannot find -lpthread
ld: cannot find -lc
ld: cannot find -ldl
ld: cannot find -lc
make: *** [IDP] Error 1
Which I believe is because I don't have static versions of these libraries on my system
UPDATE 3
I also tried the approach of providing the shared objects in a library (as suggested by [this post])(https://stackoverflow.com/a/3214232/615257) but it just segmentation faults.
This is a common problem. All the later distributions from 2011 onwards do not have static versions of the 64-bit libraries. They ship with the 32-bit versions but not with 64. You just have to use the shared lib versions of libm, libc etc.
I'm trying to compile samtools on a Solaris server where I do not have root. Samtools depends on zlib. The system zlib on this machine is not compiled with large file support, so compiling samtools against this version has the expected effect: samtools only handle small files. I need it to be able to handle large files. Luckily, there is a version of zlib compiled by the admin in /usr/local/apps/zlib-1.2.5/ with large file support. I can compile against this by adding -R /usr/local/apps/zlib-1.2.5/lib to CFLAGS, but this seems not to work. The symptoms are as follows:
When I try to run samtools, it crashes with this error:
ld.so.1: samtools: fatal: relocation error: file samtools: symbol gzopen64: referenced symbol not found
If I add /usr/local/apps/zlib-1.2.5/ to LD_LIBRARY_PATH, then samtools works fine.
Analyzing samtools with ldd and readelf yields the following:
$ ldd -r samtools
libnsl.so.1 => /usr/lib/libnsl.so.1
libsocket.so.1 => /usr/lib/libsocket.so.1
libresolv.so.2 => /usr/lib/libresolv.so.2
libm.so.2 => /usr/lib/libm.so.2
libcurses.so.1 => /usr/lib/libcurses.so.1
libz.so => /usr/lib/libz.so
libc.so.1 => /usr/lib/libc.so.1
libmp.so.2 => /usr/lib/libmp.so.2
libmd.so.1 => /usr/lib/libmd.so.1
libscf.so.1 => /usr/lib/libscf.so.1
libdoor.so.1 => /usr/lib/libdoor.so.1
libuutil.so.1 => /usr/lib/libuutil.so.1
libgen.so.1 => /usr/lib/libgen.so.1
symbol not found: gzopen64 (samtools)
$ ldd -s samtools
...(snip)...
find object=libz.so; required by samtools
search path=/usr/lib:/usr/openwin/lib:/usr/dt/lib:/usr/local/lib (LD_LIBRARY_PATH)
trying path=/usr/lib/libz.so
libz.so => /usr/lib/libz.so
...(snip)...
$ readelf -d samtools | grep RPATH
0x0000000f (RPATH) Library rpath: [/usr/local/apps/zlib-1.2.5/lib:/usr/local/apps/gcc-4.5.1/lib]
So /usr/local/apps/zlib-1.2.5/lib is clearly in the binary's RPATH, which I understand is supposed to be searched at runtime for shared libraries. However, ldd -s shows that this directory is never searched. Adding this path to LD_LIBRARY_PATH and re-running the ldd commands has the expected effect: the directory is searched and the correct version of libz is found.
So how can I force samtools to search in /usr/local/apps/zlib-1.2.5/lib at runtime without using LD_LIBRARY_PATH?
Edit: The documentation here would seem to indicate that the -R option is the correct thing to do. But it doesn't work.
I'm by no means a Solaris expert, but this line:
find object=libz.so; required by samtools
search path=/usr/lib:/usr/openwin/lib:/usr/dt/lib:/usr/local/lib (LD_LIBRARY_PATH)
seems to indicate to me that LD_LIBRARY_PATH is already set, and the /usr/lib path in it is taking precedence over any runtime linker paths. Can you unset LD_LIBRARY_PATH if it is in fact present and see if that resolves it?