GDB static build result in dynamic binary

[moritz-meier]

I am trying to build a static toolchain (arm-unknown-linux-gnueabi), but the resulting gdb binary is still dynamically linked.
All other binaries are static.

Here is my config:

CT_CONFIG_VERSION="4"

CT_TOOLCHAIN_PKGVERSION="v13"

# Target
CT_ARCH_ARM=y

# Toolchain
CT_STATIC_TOOLCHAIN=y

# Operating System
CT_KERNEL_LINUX=y
CT_LINUX_V_6_4=y

# Binutils
CT_BINUTILS_V_2_40=y

# C Library
CT_GLIBC_V_2_37=y

# C Compiler
CT_CC_LANG_CXX=y
CT_GCC_V_13=y

# Debug
CT_DEBUG_GDB=y
CT_GDB_NATIVE=y
CT_GDB_NATIVE_STATIC=y
CT_GDB_V_13=y

.config

Environment is a fedora-toolbox:39 with these packages:

autoconf automake gcc gcc-c++ flex bison texinfo help2man file patch libtool ncurses-devel glibc glibc-static libstdc++ libstdc++-static

Build log:
build.zip

I guess it is related to #2056
In the build.log i found that only the binutils build uses the "-all-static" option, but gdb apparently only uses "-static"?

crosstool-ng: 1.26.0.69_95a41fb (current main branch)

[cpackham]

Would you be able to run ldd on the resulting gdb? I have a feeling it might actually be related to libexpat.

[moritz-meier]

ldd arm-unknown-linux-gnueabi/bin/arm-unknown-linux-gnueabi-gdb:
        linux-vdso.so.1 (0x00007ffc8d7ee000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fe2ba906000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fe2ba724000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fe2ba9ed000)

[cpackham]

Hmm OK so just libc stuff. I take it libc.a and libm.a are available on your machine?

[moritz-meier]

Yes, it runs without a problem.

[cpackham]

I have a vague feeling that there is some special libtool thing for using a static libc. We might need that in addition to the other flags.