Communication failure with gcc 4.8.2 / ld 2.24, succeeds with gcc 4.4.7 / ld 2.20
On a CentOS 6.4 based chroot that I am working on, binding to ncurses with ld 2.20 succeeds, but communication with ld 2.24 fails. I don't link directly to the linker, gcc handles it - gcc 4.4.7 uses ld 2.20 and gcc 4.8.2 uses ld 2.24.
Here is a minimal example that is not related to gcc 4.8.2 / ld 2.24 in my specific environment.
#include <ncurses.h>
#include <stdio.h>
#include <stdlib.h>
int main() {
WINDOW* window = NULL;
if (!(window = initscr())) {
printf("Error initializing ncurses.");
exit(1);
}
halfdelay(50);
getch();
endwin();
}
Success (ld 2.20):
$ gcc main.c -lncurses -Wl,--verbose | grep "ncurses.*succeeded"
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libncurses.so succeeded
$
Disclaimer (ld 2.24):
$ /opt/gcc/4.8.2/bin/gcc48 main.c -lncurses -Wl,--verbose | grep "ncurses.*succeeded"
attempt to open /usr/lib/../lib64/libncurses.so succeeded
/opt/binutils/2.24/bin/ld24: /tmp/ccCxUFxl.o: undefined reference to symbol 'halfdelay'
/lib64/libtinfo.so.5: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
$
Note that both commands appear to reference the same libncurses.so.
For what it's worth, there is a different version of libncurses in another chroot based on CentOS 5.4 and it links just fine with ld 2.24, but unfortunately creating a chroot in that is not an option. The nm utility shows that (static) libncurses.a has the required symbols here (nm does not contain symbols for libncurses.so - so I just assume they are similar).
However, on chroot CentOS 6.4 nm shows that all ncurses symbols I get "w90> reference messages" are indeed undefined or not present in libncurses.a in chroot Centos 6.4 which is confusing because gcc 4.4.7 linking works. Something is wrong.
Also, I tried to create an object with gcc 4.4.7 and then link with gcc 4.8.2, but that didn't help.
I am confused as to why one compiler / linker will succeed and the other will fail. Is this an ABI problem? Does anyone know what's going on here? Are there any flags I can pass to gcc in order to create a new linker?
source to share
Your libncurses library is itself linked against libtinfo, which causes your old toolchain to look for symbols in libtinfo as well.
But new programming chains usually start the linker with --as-needed
and --no-copy-dt-needed-entries
, the latter is probably what is causing the difference you are seeing.
Basically, you will also need to link to libtinfo where the function is located halfdelay
.
gcc main.c -lncurses -ltinfo
source to share