I'm trying to build a smbclient binary from the latest source using static linking so it can be portable. I'm doing this on a RHEL 7 machine with all the configure dependencies installed already.
I tried the following but ldd still says the binary has dynamic dependencies.
# wget https://www.samba.org/samba/ftp/samba-latest.tar.gz
# tar -zxvf samba-latest.tar.gz
# cd samba-4.5.1/
# ./configure
# make SHARED=0 CC='gcc -static'
# ldd /root/samba-4.5.1/bin/default/source4/client/smbclient4
linux-vdso.so.1 => (0x00007fff3ebb1000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fb7bf35d000)
libcmdline-credentials-samba4.so => /root/samba-4.5.1/bin/shared/private/libcmdline-credentials-samba4.so (0x00007fb7bf159000)
libsmbclient-raw-samba4.so => /root/samba-4.5.1/bin/shared/private/libsmbclient-raw-samba4.so (0x00007fb7bef0e000)
libtalloc.so.2 => /root/samba-4.5.1/bin/shared/private/libtalloc.so.2 (0x00007fb7bed04000)
libsamba-credentials.so.0 => /root/samba-4.5.1/bin/shared/libsamba-credentials.so.0 (0x00007fb7beaef000)
libsamba-errors.so.1 => /root/samba-4.5.1/bin/shared/libsamba-errors.so.1 (0x00007fb7be7a0000)
libsamba-hostconfig.so.0 => /root/samba-4.5.1/bin/shared/libsamba-hostconfig.so.0 (0x00007fb7be56f000)
libsamba-security-samba4.so => /root/samba-4.5.1/bin/shared/private/libsamba-security-samba4.so (0x00007fb7be34b000)
...
I'm not sure if this is because Samba now uses WAF for builds or not. So I'm looking for help on this.
Related
I am currently searching for a way to make a binary that I just compiled, a portable binary for most of all linux environment. I was considering Ermine but it's not free (looking for a free solution right now) and tried also with Statifier but didn't work either. Here is the details on the binary I am trying to make static and portable:
sirius#blackb0x:~/MINING/ARIONUM/ariominer/build$ ldd /home/sirius/MINING/ARIONUM/ariominer/build/ariominer
linux-vdso.so.1 => (0x00007fff692fe000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fdfee979000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fdfee775000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fdfee45f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fdfee159000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fdfedf42000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fdfedb79000)
/lib64/ld-linux-x86-64.so.2 (0x00007fdfeeb97000)
If some could tell me how exactly to link all the libs to the binary so it could run easy on all or almost all linux env (2.6.18 kernels to latest) it would be very appreciated.
Thanks
Rebuild the program and its dependencies from source (while having LIBS set to -static), and make sure to pass --enable-static --disable-shared to their configure scripts.
If that doesn't work, just compile it on a very old machine and provide binaries for glibc and musl.
I am building a shared object on Ubuntu 16.04 which uses libgomp. My goal is to make this final object as portable as possible, by static linking anything not normally in a base distribution (using docker ubuntu or alpine images as a reference baseline). I've been able to do this with my other dependencies pretty easily, but I'm hung up on libgomp.
I can link just fine with the -fopenmp option, and get a dynamic link:
# ldd *.so
linux-vdso.so.1 => (0x00007fff01df4000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9ba59db000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f9ba57b9000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f9ba55a3000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f9ba5386000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9ba4fbc000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9ba6516000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9ba4db8000)
But if I naively add -static before -fopenmp I get:
relocation R_X86_64_32 against `__TMC_END__' can not be used when making a shared object; recompile with -fPIC
Fair enough; with my other dependencies I've just built from source to enable PIC and any other options I needed. When I try to do the same with libgomp, though, I'm not having any luck. I checked out gcc 5.5 from http://gcc.gnu.org/svn/gcc, and tried building from the gcc/libgomp folder. There is a configure script already generated, but running it returns:
./config.status: line 1486: ./../../config-ml.in: No such file or directory
OK, apparently this has something to do with multilibrary support, which I don't believe I need. Running ./configure --help shows that there is an --enable-multilib option with no obvious default, but setting --enable-multilib=no or --disable-multilib still returns the same error. I've also tried running autoreconf -fiv to regenerate the configure script, but I get this error:
configure.ac:5: error: Please use exactly Autoconf 2.64 instead of 2.69.
If I explicitly install and use autoreconf2.64, I get this one:
configure.ac:65: error: Autoconf version 2.65 or higher is required
What am I missing?
What I was missing was the fact that libgomp is not buildable separate from the rest of gcc. It was just a matter of going up a level and running the whole build with -fPIC enabled:
export CFLAGS="-O3 -fPIC"
export CXXFLAGS="-O3 -fPIC"
./configure --disable-multilib --enable-languages=c,c++
make
make install
That gave me a copy of libgomp.a in /usr/local/lib64 ready for linking in to my shared object.
Follow up:
While this worked, at least in a test environment, after the comments above from Jim Cownie we decided to just disable OpenMP support from our library for now.
I'm working with legacy system and I need to statically build ImageMagick (6.9 and/or 7.x), because the one in use is very old and has some bugs fixed by more recent versions (and I need these fixes).
I've checked plenty of resources, all coming with different solutions and they got me confused. I have no idea how to work with make and configure and thus I really need something definitive.
For current version I only have executables (ldd says "not a dynamic executable" for each one of them) and etc directory containing some XML configuration (I assume) files.
I need the same thing, just with more recent ImageMagick version.
UPDATE
Just wanted to say that when I use this command to configure it:
LDFLAGS="-static" ./configure --without-modules --enable-static --enable-delegate-build --disable-shared
I end up with
ldd convert
linux-vdso.so.1 => (0x00007ffc71518000)
libgomp.so.1 => /usr/lib/x86_64-linux-gnu/libgomp.so.1 (0x00007f88f254f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f88f2246000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f88f202f000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f88f1e12000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f88f1a48000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f88f1843000)
/lib64/ld-linux-x86-64.so.2 (0x0000559c6e584000)
Which obviously doesn't work for me, I'd like the whole thing to be statically linked.
I have a Haskell application I can successfully build and run in docker. It was, until recently, working fine in Heroku when deployed with heroku docker:release. However, now when I deploy it, I get segmentation faults when the binary is run in Heroku. This does not occur when I build and run the binary locally, either inside or outside of a Docker container.
I suspect this is due to dynamically linked libraries, which live outside the /app directory. Specifically, the executable links to the following libraries (the output of ldd):
linux-vdso.so.1 => (0x00007ffd1f5ec000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f7119ecf000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f7119cc7000)
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f7119ac3000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f71198bf000)
libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f711963f000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f7119336000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f7119118000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f7118f01000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f7118b36000)
/lib64/ld-linux-x86-64.so.2 (0x000055b23a73b000)
Am I correct in thinking that this is an issue? Is there a good way to resolve this?
If you compile and link in a shared library does it store the soname of the library somewhere in the binary so it knows which one to link to? In other words if I link against a version 1.0.0 of liba.so and then I update my library to 2.0.0 and the ABI/API has changed and now my sym link to liba.so is pointing to the 2.0.0 version will the binary still know to look at liba.so.1? In other words does it store the specific soname of the linked library in the binary
Yes, you can use ldd to view the dependency of a binary.
Try ldd /bin/bash yourself
On my machine it prints
linux-vdso.so.1 => (0x00007fff10dff000)
libncurses.so.5 => /lib/libncurses.so.5 (0x00007f2237acb000)
libdl.so.2 => /lib/libdl.so.2 (0x00007f22378c7000)
libc.so.6 => /lib/libc.so.6 (0x00007f2237564000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2237d25000)