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?
Related
raco exe makes dynamic executables, and raco distribute doesn't change that:
$ ldd ./tst
linux-vdso.so.1 (0x00007ffc9ed46000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fbeb4c09000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbeb4a18000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbeb4c67000)
On windows, it looks like one can --embed-dlls, which is kindof what I want, but for all platforms.
I'd like to compile statically for ease of distribution and deployment. Is this possible?
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'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.
Recently, when compiling with '-fsanitize=address' I am getting
an execution exception when running an application with valgrind
namely
"ASan runtime does not come first in initial library list"
I am a little clueless what valgrind actually does. The command
'ldd file.exe' delivers
linux-gate.so.1 => (0xb7755000)
libasan.so.3 => /usr/lib/i386-linux-gnu/libasan.so.3 (0xb7199000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb6fdf000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb6fd8000)
librt.so.1 => /lib/i386-linux-gnu/librt.so.1 (0xb6fcf000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb6fb2000)
libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xb6f5c000)
/lib/ld-linux.so.2 (0x80092000)
libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xb6f3e000)
Any hints?
You won't be able to run sanitized code under Valgrind. Even if you get past the problem with preloading libasan, you'll run into conflicting address space requirements (i.e. upon start Valgrind reserves region of memory which is also required by Asan shadow memory) and this can't be worked around as both addresses are hard-coded in Valgrind and libasan. Similar issues exist for Asan and Tsan or Asan and Msan (i.e. they can't be enabled simultaneously). It's unlikely to be fixed as sanitizers are highly specialized to achieve their impressive performance numbers.
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.