CT_GDB_NATIVE_STATIC and CT_GDB_GDBSERVER_STATIC no longer work

[nyetwurk]

As of f7c9ab3
Host:
Linux 4.9.0-3-amd64 #1 SMP Debian 4.9.30-1 (2017-06-04) x86_64 GNU/Linux
Building ARM target

gdb and gdbserver can no longer be built static

$ ldd /usr/bin/gdbserver 
        libdl.so.2 => /lib/libdl.so.2 (0x400dc000)
        libstdc++.so.6 => /lib/libstdc++.so.6 (0x400ef000)
        libm.so.6 => /lib/libm.so.6 (0x4027c000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x4007b000)
        libc.so.6 => /lib/libc.so.6 (0x40341000)
        /lib/ld-linux.so.3 (0x4004a000)

config.zip

[stilor]

Did you enable CT_EXPERIMENTAL? These options have been marked experimental for a reason, see the help message for them. With recent binutils, these options now produce invalid binaries for several architectures.

Note that if you just copied a previous .config, you should have done ct-ng oldconfig and that would've removed these options if CT_EXPERIMENTAL is not set.

Also note how the second of the binutils bugs [1] was "fixed". IIUC, static GDB build will break once binutils 2.29 is released (unless GDB is changed accordingly).

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=21086

[nyetwurk]

Yes. I have EXPERIMENTAL marked. I really wanted a static version of gdbserver because I don't need libstdc++ but do want gdbserver) on the target. That said, I suppose I can just disable c++ support in gdbserver via --disable-libstdcxx?

Or is that something else?

[stilor]

It has nothing to do with C++ support. It is rather that new versions of binutils (since 2.25 or 2.26, AFAIR) have started to make the resulting binary dynamic, and it requests an invalid program interpreter (ld.so). Basically, with the command line that GDB uses to build gdbserver or native gdb, the compiler does not pass the path to ld.so - but ld decides it needs to create a dynamic binary and makes it request a non-existent default /usr/lib/ld.so.1 runtime linker.

Read the links in the help message for these options, they are... educational.

[nyetwurk]

No, I understand that.. Just saying the reason I need a static gdbserver is because I don't want to require libstdc++.so on the target.

Is there a way to remove gdbserver's reliance on libstdc++.so? I realize this is an offtopic question to some extent.

[stilor]

I thought even static gdb would require libstdc++ (albeit static one). But yes, it is better asked on gdb's mailing lists, I doubt you'll find a lot of experts here.

Anyway, back to this issue: can you check if readelf -d reports any NEEDED entries in gdb/gdbserver? I tried with your config, the resulting binaries had .dynamic section but no library dependencies:

$ readelf -d ~/x/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/debug-root/usr/bin/gdbserver 
Dynamic section at offset 0x1a7f38 contains 20 entries:
  Tag        Type                         Name/Value
 0x0000000c (INIT)                       0x161fc
 0x0000000d (FINI)                       0x178150
 0x00000019 (INIT_ARRAY)                 0x1c5048
 0x0000001b (INIT_ARRAYSZ)               52 (bytes)
 0x0000001a (FINI_ARRAY)                 0x1c507c
 0x0000001c (FINI_ARRAYSZ)               8 (bytes)
 0x00000004 (HASH)                       0x101a8
 0x00000005 (STRTAB)                     0x126b0
 0x00000006 (SYMTAB)                     0x10c60
 0x0000000a (STRSZ)                      14708 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000015 (DEBUG)                      0x0
 0x00000003 (PLTGOT)                     0x1c8000
 0x00000002 (PLTRELSZ)                   288 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x160dc
 0x00000011 (REL)                        0x16024
 0x00000012 (RELSZ)                      184 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x00000000 (NULL)                       0x0

On the other hand, they requested /usr/lib/ld.so.1:

$ readelf -Wl ~/x/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/debug-root/usr/bin/gdbserver 

Elf file type is EXEC (Executable file)
Entry point 0x172fc
There are 10 program headers, starting at offset 52

Program Headers:
...
  INTERP         0x000174 0x00010174 0x00010174 0x00011 0x00011 R   0x1
      [Requesting program interpreter: /usr/lib/ld.so.1]

but the actual name of the ld.so is /lib/ld-linux.so.3.

[nyetwurk]

$ bin/arm-unknown-linux-gnueabi-readelf -d arm-unknown-linux-gnueabi/debug-root/usr/bin/gdbserver

Dynamic section at offset 0x1a7f38 contains 20 entries:
  Tag        Type                         Name/Value
 0x0000000c (INIT)                       0x161fc
 0x0000000d (FINI)                       0x178150
 0x00000019 (INIT_ARRAY)                 0x1c5048
 0x0000001b (INIT_ARRAYSZ)               52 (bytes)
 0x0000001a (FINI_ARRAY)                 0x1c507c
 0x0000001c (FINI_ARRAYSZ)               8 (bytes)
 0x00000004 (HASH)                       0x101a8
 0x00000005 (STRTAB)                     0x126b0
 0x00000006 (SYMTAB)                     0x10c60
 0x0000000a (STRSZ)                      14708 (bytes)
 0x0000000b (SYMENT)                     16 (bytes)
 0x00000015 (DEBUG)                      0x0
 0x00000003 (PLTGOT)                     0x1c8000
 0x00000002 (PLTRELSZ)                   288 (bytes)
 0x00000014 (PLTREL)                     REL
 0x00000017 (JMPREL)                     0x160dc
 0x00000011 (REL)                        0x16024
 0x00000012 (RELSZ)                      184 (bytes)
 0x00000013 (RELENT)                     8 (bytes)
 0x00000000 (NULL)                       0x0

yet on the target

# ldd /usr/bin/gdbserver
        libdl.so.2 => /lib/libdl.so.2 (0x400f3000)
        libstdc++.so.6 => /lib/libstdc++.so.6 (0x40106000)
        libm.so.6 => /lib/libm.so.6 (0x40293000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x40358000)
        libc.so.6 => /lib/libc.so.6 (0x40388000)
        /lib/ld-linux.so.3 (0x4007e000)

and if i move libstdc++ out of the way

# /usr/bin/gdbserver
/usr/bin/gdbserver: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory

[nyetwurk]

Possibly related:

[ALL  ]    /local/nyeth-build/crosstool-ng/targets/src/gdb-8.0/gdb/gdbserver/thread-db.c:574: warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
[ALL  ]    linux-osdata.o: In function `group_from_gid(char*, int, unsigned int) [clone .constprop.1]':
[ALL  ]    /local/nyeth-build/crosstool-ng/targets/src/gdb-8.0/gdb/gdbserver/../nat/linux-osdata.c:1141: warning: Using 'getgrgid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
[ALL  ]    linux-osdata.o: In function `user_from_uid(char*, int, unsigned int) [clone .constprop.4]':
[ALL  ]    /local/nyeth-build/crosstool-ng/targets/src/gdb-8.0/gdb/gdbserver/../nat/linux-osdata.c:217: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

I am going to try to avoid -static and maybe just use -static-libstdc++ by itself.

[nyetwurk]

-static-libstdc++ without -static seems to work.

I will issue a PR after more testing.

[stilor]

Worked around by the above PR, building statically is known broken (at least with current binutils).