-1

I have this application that compiles no problem on dynamic linking. When I go to static linking, I try:

g++ -std=c++11 -static -o ../bin/executable executable.o obj1.o obj2.o obj3.o obj4.o ../lib/gzstream/libgzstream.a -lgsl -Wl,-Bstatic -lcurl -Wl,-Bdynamic -Wl,-Bsymbolic-functions -lnghttp2 -lidn2 -lrtmp -lssh -lpsl -lnettle -lgnutls -L/usr/lib/x86_64-linux-gnu/mit-krb5 -Wl,-Bsymbolic-functions -Wl,-z,relro -lgssapi_krb5 -lkrb5 -lk5crypto -lcom_err -llber -lldap -llber -lbrotlidec -lz -lgslcblas -llzma -lbz2 -lz -lpthread

then I call the executable:

../bin/executable

Then I get:

 -bash: ../bin/executable: No such file or directory

but it does exist, ls confirms it:

-rwxr-xr-x 1 username guest ? 7108400 Feb 12 23:07 ../bin/executable

. ldd works also:

ldd ../bin/executable
linux-vdso.so.1 (0x00007ffd432c7000)
libnghttp2.so.14 => /lib/x86_64-linux-gnu/libnghttp2.so.14 (0x00007f0dcc5a4000)
libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x00007f0dcc583000)
librtmp.so.1 => /lib/x86_64-linux-gnu/librtmp.so.1 (0x00007f0dcc563000)
libssh.so.4 => /lib/x86_64-linux-gnu/libssh.so.4 (0x00007f0dcc4f5000)
libpsl.so.5 => /lib/x86_64-linux-gnu/libpsl.so.5 (0x00007f0dcc4e2000)
libnettle.so.7 => /lib/x86_64-linux-gnu/libnettle.so.7 (0x00007f0dcc4a8000)
libgnutls.so.30 => /lib/x86_64-linux-gnu/libgnutls.so.30 (0x00007f0dcc2d0000)
libgssapi_krb5.so.2 => /lib/x86_64-linux-gnu/libgssapi_krb5.so.2 (0x00007f0dcc283000)
liblber-2.4.so.2 => /lib/x86_64-linux-gnu/liblber-2.4.so.2 (0x00007f0dcc272000)
libldap_r-2.4.so.2 => /lib/x86_64-linux-gnu/libldap_r-2.4.so.2 (0x00007f0dcc21c000)
libbrotlidec.so.1 => /lib/x86_64-linux-gnu/libbrotlidec.so.1 (0x00007f0dcc20e000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f0dcc1f2000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f0dcc1c7000)
libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x00007f0dcc1b4000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f0dcc191000)
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f0dcbfaf000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0dcbe60000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0dcbc6e000)
libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2 (0x00007f0dcbaea000)
libhogweed.so.5 => /lib/x86_64-linux-gnu/libhogweed.so.5 (0x00007f0dcbab3000)
libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007f0dcba2f000)
libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f0dcb758000)
/lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x00007f0dcc5eb000)
libp11-kit.so.0 => /lib/x86_64-linux-gnu/libp11-kit.so.0 (0x00007f0dcb622000)
libtasn1.so.6 => /lib/x86_64-linux-gnu/libtasn1.so.6 (0x00007f0dcb60c000)
libkrb5.so.3 => /lib/x86_64-linux-gnu/libkrb5.so.3 (0x00007f0dcb52d000)
libk5crypto.so.3 => /lib/x86_64-linux-gnu/libk5crypto.so.3 (0x00007f0dcb4fc000)
libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2 (0x00007f0dcb4f5000)
libkrb5support.so.0 => /lib/x86_64-linux-gnu/libkrb5support.so.0 (0x00007f0dcb4e6000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f0dcb4ca000)
libsasl2.so.2 => /lib/x86_64-linux-gnu/libsasl2.so.2 (0x00007f0dcb4ad000)
libgssapi.so.3 => /lib/x86_64-linux-gnu/libgssapi.so.3 (0x00007f0dcb466000)
libbrotlicommon.so.1 => /lib/x86_64-linux-gnu/libbrotlicommon.so.1 (0x00007f0dcb443000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f0dcb428000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f0dcb422000)
libffi.so.7 => /lib/x86_64-linux-gnu/libffi.so.7 (0x00007f0dcb416000)
libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1 (0x00007f0dcb40d000)
libheimntlm.so.0 => /lib/x86_64-linux-gnu/libheimntlm.so.0 (0x00007f0dcb401000)
libkrb5.so.26 => /lib/x86_64-linux-gnu/libkrb5.so.26 (0x00007f0dcb36e000)
libasn1.so.8 => /lib/x86_64-linux-gnu/libasn1.so.8 (0x00007f0dcb2c8000)
libhcrypto.so.4 => /lib/x86_64-linux-gnu/libhcrypto.so.4 (0x00007f0dcb290000)
libroken.so.18 => /lib/x86_64-linux-gnu/libroken.so.18 (0x00007f0dcb275000)
libwind.so.0 => /lib/x86_64-linux-gnu/libwind.so.0 (0x00007f0dcb24b000)
libheimbase.so.1 => /lib/x86_64-linux-gnu/libheimbase.so.1 (0x00007f0dcb239000)
libhx509.so.5 => /lib/x86_64-linux-gnu/libhx509.so.5 (0x00007f0dcb1eb000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f0dcb0c2000)
libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1 (0x00007f0dcb087000)

Also, strace with -ff seems to print out the correct message from the executable:

strace -ff /lib64/ld-linux-x86-64.so.2  ../bin/executable

This is the output of readelf:

readelf -h ../bin/executable
ELF Header:
Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
Class:                             ELF64
Data:                              2's complement, little endian
Version:                           1 (current)
OS/ABI:                            UNIX - System V
ABI Version:                       0
Type:                              EXEC (Executable file)
Machine:                           Advanced Micro Devices X86-64
Version:                           0x1
Entry point address:               0x424c40
Start of program headers:          64 (bytes into file)
Start of section headers:          7105840 (bytes into file)
Flags:                             0x0
Size of this header:               64 (bytes)
Size of program headers:           56 (bytes)
Number of program headers:         12
Size of section headers:           64 (bytes)
Number of section headers:         40
Section header string table index: 39
madreblu
  • 373
  • 5
  • 15
  • How did you get that bash error? `g++` should not call bash. – Quimby Feb 12 '23 at 22:35
  • my apologies, I forgot to write, that this occurs when I call the executable, thank you for pointing that out. – madreblu Feb 12 '23 at 22:41
  • 1
    Please add the output of `ls -lZ ..bin/executable` – stark Feb 12 '23 at 22:48
  • 1
    Can you do `readelf -h ../bin/executable`? this error appears if the file is executable but cannot be executed due to e.g. different architecture. – Quimby Feb 12 '23 at 22:48
  • @madreblu Seems alright to me, is it the same if you do dynamic? [relevant](https://askubuntu.com/questions/133389/no-such-file-or-directory-but-the-file-exists), maybe try running `file ../bin/executable`, I guess the loader is just not happy about something. – Quimby Feb 13 '23 at 14:31
  • `strace -ff /lib64/ld-linux-x86-64.so.2` why ld? Have you tried strace without ld with just the binary? No-such-file-on-exec is usually some problem with the loader. – teapot418 Feb 13 '23 at 14:44
  • 1
    @Quimby for the dynamic, it executes fine and I get: "ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=19c43ebc1d38726bc84f89bc1ca76a4457ae9c1f, for GNU/Linux 3.2.0, with debug_info, not stripped" – madreblu Feb 14 '23 at 13:08
  • @teapot418 yes and I get: "execve("../bin/executable", ["../bin/executable"], 0x7ffe0cfa36a0 /* 22 vars */) = -1 ENOENT (No such file or directory) strace: exec: No such file or directory +++ exited with 1 +++ " which is weird because with -ff I get the help menu at least. – madreblu Feb 14 '23 at 13:09
  • @madreblu Looks fine too, unfortunately, I do not know how to help you more without being able to test it on my machine, sorry. – Quimby Feb 14 '23 at 13:27

1 Answers1

1

C++ static linking

You are not doing static linking (because on your command line, you override -static with -Bdynamic).

The error means that the executable is requesting an ELF interpreter which does not exist on your system. Running readelf -Wl ../bin/executable will show you which ELF interpreter that is. Look for lines like this:

  INTERP         0x000318 0x0000000000000318 0x0000000000000318 0x00001c 0x00001c R   0x1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]

The ldd output shows that the actual ELF interpreter in your binary is /lib/ld64.so.1, and the reason for that interpreter is probably that GCC got confused by -static (a GCC flag) and -Wl,-Bdynamic (a flag that is not visible to the GCC driver, but is passed directly to ld) mixture.

This is also why invoking the binary via correct ELF interpreter: /lib64/ld-linux-x86-64.so.2 ../bin/executable works -- in that case the interpreter inside the executable is ignored.

Since you are not actually doing a -static link, I suspect that removing -static will fix the problem.

If you do want a fully-static link, then you should drop all the -Wl,... flags you currently have, and also note that your binary will likely not run (at least not correctly) on any system other than the one it was linked on. See this answer.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • thanks a lot!! I got rid of the problem because the program used libcurl. however, it seems that there is static binary. – madreblu Feb 16 '23 at 10:50
  • I managed to solved the problem somehow, I compiled the library I was using without libcurl and managed to get a static binary. thank you @Employed Russian and @Quimby! – madreblu Feb 19 '23 at 10:01