Summary: | x11-terms/xterm-285 with sys-libs/ncurses[tinfo] - resize.c:(.text.startup+0x127): undefined reference to `tgetent' | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jan Paesmans <jan.paesmans> |
Component: | Current packages | Assignee: | Thomas Dickey <dickey> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | jlec, travisghansen, x11 |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 457530 |
Description
Jan Paesmans
2013-01-30 20:46:33 UTC
This little bug is causing me grief with all kinds of packages. I have issues building: readline texinfo lame speech-tools vim-core procps All of them build fine if I set: LDFLAGS=" -L/lib -lncurses" emerge foo Builds fine here. # ncurses5-config --libs -L/usr/lib64 -lncurses This is the piece of c-code that is used by autoconf: int main() { char buffer[1024]; buffer[0] = 0; tgetent(buffer, "vt100"); return (0); } Autoconf tries to compile with the following cmd-line: x86_64-pc-linux-gnu-gcc -o conftest -march=amdfam10 -O3 -pipe -fomit-frame-pointer -D_GNU_SOURCE -Wl,-O1 -Wl,--as-needed conftest.c -lcurses Resulting in the following error: In function `main': conftest.c:(.text.startup+0x16): undefined reference to `tgetent' collect2: ld returned 1 exit status To successfully compile I need to add -ltinfo. This is where the symbol 'tgetent' is located. Autoconf script doesn't use ncurses5-config and running ncurses5-config gives the following: ncurses5-config --libs -L/usr/lib64 -lncurses -ltinfo This means that adding -ltinfo is needed Using the output of ncurses5-config and setting LDFLAGS="-L/usr/lib64 -lncurses -ltinfo" emerge -v xterm works. A variant to what Travis Hansen suggests. I think there's a deeper issue here as well. Look at the differnces in filesizes: 15z ~ # ls -l /lib64/libncurses.so.5.9 -rwxr-xr-x 1 root root 142816 Jan 17 01:29 /lib64/libncurses.so.5.9 15z ~ # ls -l /usr/lib64/libncurses.so -rwxr-xr-x 1 root root 529 Jan 17 01:29 /usr/lib64/libncurses.so And is it standard procedure to have libs with the same name in different dirs? CC:'ing ncurses maintainers, maybe they can suggest what is the correct way to address this issue. (In reply to comment #6) use ncurses' .pc file rather than -lncurses to link. the ncurses ebuild isn't broken here. As indicated, there is something wrong with the configure script. autoconf tries to check for termcap/curses/ncurses libraries. It does this by testing for each by trying to link the conftest.c file as mentioned after the emerge --info section. This is wrong, autoconf's check for termcap/curses/ncurses is wrong. If it wants to see if libncurses can be used by compiling and linking a test code, that at least for libncurses it must use the proper libraries. This can be done by using pkg-config. If someone tells me that this is not a problem, again try compiling and linking the example code given with the ncurses5.9-r2, than you'll see that the test as preformed by autoconf is _wrong_! Linking rc from openrc suffers from the same problem. Linking with the ncurses5.9-r2 fails. In mk/termcap.mk:2, if you want to link with this ncurses5.9-r2, you need -lncurses -ltinfo, not just -lncurses. This is not automake, so in the future, it might be easier to use ncurses pkg-config there. (In reply to comment #9) file new bugs for new issues. this bug is just for xterm. I think it's time a tracker bug be opened to deal with the packages affected by this issue. + 14 Feb 2013; Justin Lecher <jlec@gentoo.org> xterm-285.ebuild, + xterm-288.ebuild, metadata.xml: + Add Workaround for ncurses[tinfo], #454736; correct HOMEPAGE; improve usage + of EAPI >=4; add missing die + Thomas, could you please make the buildsystem use pkg-config to detect ncurses libs? And while you are at it, I saw you are still using the long deprecated configure.in instead of .ac naming. This will become a problem with next automake release. A simple rename should do it. Thanks Do we have a tracker bug yet for all the packages that have this issue? (In reply to comment #14) Yes, bug 457530 which is already blocked by this bug. |