[lsb-discuss] LSB SDK automatically dynamic links LSB libs - intended behavior?

[Gregory Fong]

Hi all,

I recently noticed that lsbcc does an interesting thing if you try to
explicitly specify that libraries contained within in the LSB spec
should be statically linked: they get automatically changed to
dynamic.  Below is a small ncurses program and the difference between
compiling with plain gcc and lsbcc.

$ cat foo.c
#include <ncurses.h>

int main()
{
    initscr();
    printw("Hello World !!!!");
    refresh();
    getch();
    endwin();
    return 0;
}

Using gcc:

$ gcc -o foo foo.c -Wl,-Bstatic -lncurses -ltinfo -Wl,-Bdynamic -v
[snip a lot of stuff]
 /usr/lib/gcc/x86_64-linux-gnu/4.7/collect2 --sysroot=/ --build-id
--eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed
-dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro -o foo
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.7/crtbegin.o
-L/usr/lib/gcc/x86_64-linux-gnu/4.7
-L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib
-L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../..
/tmp/ccojkaTc.o -Bstatic -lncurses -ltinfo -Bdynamic -lgcc --as-needed
-lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/x86_64-linux-gnu/4.7/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crtn.o

$ ldd foo
    linux-vdso.so.1 =>  (0x00007fff42ffe000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f06d0947000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f06d0d31000)


Using lsbcc:

$ LSBCC_VERBOSE=1 lsbcc -o foo foo.c -Wl,-Bstatic -lncurses -ltinfo
-Wl,-Bdynamic -v
lsbcc (lsbcc) 4.1.27
cc -v -o foo -I /opt/lsb/include/libpng12 -isystem /opt/lsb/include
foo.c -D__LSB_VERSION__=41 -nodefaultlibs -L /opt/lsb/lib64-4.1
-Wl,-Bstatic -Wl,-Bdynamic -lncurses -Wl,-Bstatic -ltinfo
-Wl,-Bdynamic -lpthread -lpthread_nonshared
-Wl,--dynamic-linker=/lib64/ld-lsb-x86-64.so.3 -fno-stack-protector -L
/usr/lib/gcc/x86_64-linux-gnu/4.7 -Wl,-rpath-link,/opt/lsb/lib64-4.1
-L/lib64 -L/usr/lib64 -Wl,--hash-style=sysv -lgcc -lm -lc
-lc_nonshared -lgcc
[snip a lot of stuff]
 /usr/lib/gcc/x86_64-linux-gnu/4.7/collect2 --sysroot=/ --build-id
--eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed
-dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro -o foo
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.7/crtbegin.o -L/opt/lsb/lib64-4.1
-L/usr/lib/gcc/x86_64-linux-gnu/4.7 -L/lib64 -L/usr/lib64
-L/usr/lib/gcc/x86_64-linux-gnu/4.7
-L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib
-L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.7/../../..
/tmp/ccBC6k7Y.o -Bstatic -Bdynamic -lncurses -Bstatic -ltinfo
-Bdynamic -lpthread -lpthread_nonshared
--dynamic-linker=/lib64/ld-lsb-x86-64.so.3 -rpath-link
/opt/lsb/lib64-4.1 --hash-style=sysv -lgcc -lm -lc -lc_nonshared -lgcc
/usr/lib/gcc/x86_64-linux-gnu/4.7/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../x86_64-linux-gnu/crtn.o

$ ldd foo
    linux-vdso.so.1 =>  (0x00007fff9fffe000)
    libncurses.so.5 => /lib/x86_64-linux-gnu/libncurses.so.5
(0x00007f4e1290f000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4e12547000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4e12342000)
    libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f4e1211a000)
    /lib64/ld-lsb-x86-64.so.3 => /lib64/ld-linux-x86-64.so.2
(0x00007f4e12b52000)


I realize it's hard to see above in the mess, but when using lsbcc,
-Bdynamic ... -Bstatic are automatically wrapped around -lncurses in
the cc line (and subsequent collect2 line), resulting in the program
still needing libncurses at runtime.  This directly contradicts the
intent.

This is a bit of an edge case (after all, since ncurses is part of the
LSB spec, most of the time you probably don't need to statically link
items that the spec requires be provided).  However, I can't find any
documentation of this behavior anywhere---there's plenty explaining
that some libraries that would have been dynamically linked are being
changed to static links to be LSB compliant, and explanations of how
to avoid that or warn if it happens.  However, I can't seem to find
any way to force ncurses to be statically linked with lsbcc.  If
anyone has any insights here, would love to hear!

Thanks and regards,

Gregory