Is there any reason why ncurses is not building the libtinfo. so lib? Latest cuda binary stuff is linked against that library which can be easily being build by adding --with-termlib to the configure line. Please include this.
(In reply to comment #0) > Is there any reason why ncurses is not building the libtinfo. so lib? > > Latest cuda binary stuff is linked against that library which can be easily > being build by adding --with-termlib to the configure line. > Please include this. I'm pretty sure all the symbols within libtinfo.so are in our libncurses.so and there is no point of having separate library for it at all
(In reply to comment #1) > (In reply to comment #0) > > Is there any reason why ncurses is not building the libtinfo. so lib? > > > > Latest cuda binary stuff is linked against that library which can be easily > > being build by adding --with-termlib to the configure line. > > Please include this. > > I'm pretty sure all the symbols within libtinfo.so are in our libncurses.so > and there is no point of having separate library for it at all So what should I do with bin-only packages? Install a symlink in that package?
Isn't cuda installed in /opt anyway? You could create the symlink there, or make it some dummy library with a little of C. Then it shouldn't be a problem for other packages (some packages have AC_CHECK_LIB for it, and fallback to plain ncurses like we install it)
How about a try wide dummy package installing a linker script pointing to libcurses.so?
(In reply to comment #4) > How about a try wide dummy package installing a linker script pointing to > libcurses.so? sounds good to me. I want to hear what Mike has to say about this though
(In reply to comment #5) presumably this is for binary only packages ? a linker script wouldn't help there. if it's for building new packages, then i don't see why you couldn't use -lcurses ... that's pretty standard nowadays.
(In reply to comment #6) > (In reply to comment #5) > > presumably this is for binary only packages ? a linker script wouldn't help > there. So what is your suggestion for binary packages?
(In reply to comment #7) we can add a USE=tinfo flag to ncurses. considering this is the first request in a decade, clearly very few people care about it.
should be all set now in the tree; thanks for the report! Commit message: Add USE=tinfo to enable building of sep libtinfo for binary packages http://sources.gentoo.org/sys-libs/ncurses/metadata.xml?r1=1.4&r2=1.5 http://sources.gentoo.org/sys-libs/ncurses/ncurses-5.9-r2.ebuild?r1=1.16&r2=1.17
(In reply to comment #9) > should be all set now in the tree; thanks for the report! > Perfect, thanks for the quick fix.
(In reply to comment #9) > should be all set now in the tree; thanks for the report! > > Commit message: Add USE=tinfo to enable building of sep libtinfo for binary > packages > http://sources.gentoo.org/sys-libs/ncurses/metadata.xml?r1=1.4&r2=1.5 > http://sources.gentoo.org/sys-libs/ncurses/ncurses-5.9-r2.ebuild?r1=1. > 16&r2=1.17 That doesn't work, because it moves symbols out of libcurses.so: libtool: link: x86_64-pc-linux-gnu-gcc -O2 -pipe -ftracer -march=corei7-avx -mtune=corei7-avx -mcx16 -msahf -mno-movbe -maes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=8192 -frecord-gcc-switches -g -Wimplicit-function-declaration -Wall -Wchar-subscripts -Wmissing-prototypes -Wmissing-declarations -Wunused -Wpointer-arith -Wwrite-strings -Wnested-externs -Wno-sign-compare -Wl,-O1 -Wl,--as-needed -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -o .libs/cdda-player cdda-player.o cddb.o getopt.o getopt1.o ../lib/driver/.libs/libcdio.so -lncurses -lm cdda-player.c:227: error: undefined reference to 'cbreak' cdda-player.c:228: error: undefined reference to 'stdscr' cdda-player.c:231: error: undefined reference to 'stdscr' cdda-player.c:231: error: undefined reference to 'keypad' cdda-player.c:233: error: undefined reference to 'stdscr' cdda-player.c:296: error: undefined reference to 'stdscr' collect2: error: ld returned 1 exit status
probably we should simply also add libtinfo.so to the linker script.
Confirmed that works.
(In reply to comment #11) libcurses links against libtinfo already, so runtime ABI is unaffected as symbols will still be found i don't think updating the linker script is correct. the .pc files already declare the -ltinfo dependency. so consider this incentive to fix packages not using pkg-config to look up ncurses dependencies.
The problem now is an ABI expected from ncurses package. Now we need to make sure to build bootstrap binaries (like dev-lang/ghc) against 'USE=-tinfo ncurses' otherwise the beast will link against libtinfo.so, right? May I ask you to set a SONAME for libtinfo.so.5 to libncurses.so.5 if they are expected to have stable ABI for both USE=tinfo/-tinfo. Thanks :]
(In reply to comment #15) > Now we need to make sure to build bootstrap binaries (like dev-lang/ghc) > against 'USE=-tinfo ncurses' otherwise the beast will link against > libtinfo.so, right? What's the difference between 'bootstrap' and "non-bootstrap" binaries? In general you should try to use pkg-config and you are fine, aren't you?
(In reply to comment #16) > (In reply to comment #15) > > Now we need to make sure to build bootstrap binaries (like dev-lang/ghc) > > against 'USE=-tinfo ncurses' otherwise the beast will link against > > libtinfo.so, right? > > What's the difference between 'bootstrap' and "non-bootstrap" binaries? In > general you should try to use pkg-config and you are fine, aren't you? Bootstrap binary is built by me like gentoo's stages are built by gentoo. It it used to build ghc by users. ghc's binary is not selfsufficient and is pinned by glibc, ncurses, gmp and other libs it is built against. Yes, it breaks every time someone bumps soname and users can't install older ghcs without hacks. But with this ncurses change things go even worse. We don't copy those libs to final tarball yet, but looks like we will have to.
Okay got it. So build it with -tinfo. This should be what your find on users systems anyways. there is only one consumer of libtinfo right now in the tree.
I'm not really convinced that having such a big library API/ABI change under an USE flag is really a good idea. I've just noticed that new pypy-bin packages are broken because the builder had ncurses[tinfo].
(In reply to Samuli Suominen from comment #3) > Isn't cuda installed in /opt anyway? You could create the symlink there, or > make it some dummy library with a little of C. Then it shouldn't be a > problem for other packages (some packages have AC_CHECK_LIB for it, and > fallback to plain ncurses like we install it) This might be a better solution. I have to agree that changing ABI on use flag switches is rather dangerous since we really don't have a way to detect/rebuild based on it.
see bug 487844 where you already posted the same thing
