sys-libs/ncurses-5.7 needs the patches below to compile on IRIX. However, even when this is complete, the install process gets stuck when running 'tic'. The output is: DESTDIR=/usr/opt/gentoo/var/tmp/portage/sys-libs/ncurses-5.7/image/ \ prefix=/opt/gentoo/usr \ exec_prefix=/opt/gentoo/usr \ bindir=/opt/gentoo/usr/bin \ top_srcdir=/usr/opt/gentoo/var/tmp/portage/sys-libs/ncurses-5.7/work/ncurses-5.7 \ srcdir=/usr/opt/gentoo/var/tmp/portage/sys-libs/ncurses-5.7/work/ncurses-5.7/misc \ datadir=/opt/gentoo/usr/share \ ticdir=/opt/gentoo/usr/share/terminfo \ source=terminfo.tmp \ THIS_CC="cc" \ THAT_CC="cc" \ /opt/gentoo/bin/bash ./run_tic.sh ** Building terminfo database, please wait... Running tic to install /usr/opt/gentoo/var/tmp/portage/sys-libs/ncurses-5.7/image//opt/gentoo/usr/share/terminfo ... You may see messages regarding extended capabilities, e.g., AX. These are extended terminal capabilities which are compiled using tic -x If you have ncurses 4.2 applications, you should read the INSTALL document, and install the terminfo without the -x option. ... at which point nothing else happens. Tracing the running 'tic' process shows no system calls being made whilst processor utilisation is close to 100% on one CPU. It has been in this state for many hours, and this failure is repeatable. sys-libs/ncurses-5.6-r2 is unaffected and builds and installs correctly. However, altering run_tic.sh or invoking the command manually with ncurses-5.6-r2's (installed) tic binary also stops in the same way - suggesting that there is problem with the data or with tic itself which didn't get triggered in ncurses-5.6-r2. Are any other platforms affected?
Created attachment 184678 [details, diff] sys-libs/ncurses-5.7 patch for narrowc and widec Makefile As supplied, the Makefile doesn't pull in the right objects for the tests to compile. This patch needs to be placed in the ebuild 'files' directory and applied to both narrowc and widec as these are compiled - the actual Makefile is mostly auto-generated from 'programs' and 'modules', and I can't work out how to alter these to make the necessary changes globally.
The ebuild can then be modified with: @@ -130,6 +130,8 @@ do_compile() { [[ ${CHOST} == *-aix* ]] || sed -i -e '/^libdir/s:/usr/lib\(64\|\)$:/lib\1:' ncurses/Makefile || die "nlibdir" + epatch "${FILESDIR}"/${PN}-5.7-Makefile.patch + # A little hack to fix parallel builds ... they break when # generating sources so if we generate the sources first (in # non-parallel), we can then build the rest of the package This could be guarded with a "[[ ${CHOST == *-irix* ]] &&", but I don't think that the changes would adversely affect other platforms...
Created attachment 184690 [details, diff] sys-libs/ncurses-5.7 patch for narrowc and widec Makefile Let's try that again with the right patch...
(In reply to comment #0) > However, altering run_tic.sh or invoking the command manually with > ncurses-5.6-r2's (installed) tic binary also stops in the same way - suggesting > that there is problem with the data or with tic itself which didn't get > triggered in ncurses-5.6-r2. > > Are any other platforms affected? > Yes, I had to remove ncurses-5.6 and then install 5.7 from new. I suspected that everything would break (bash needs ncurses) but it continued on. See related bug 249363 which had no working solution for me.
(In reply to comment #4) > > Yes, I had to remove ncurses-5.6 and then install 5.7 from new. I suspected > that everything would break (bash needs ncurses) but it continued on. See > related bug 249363 which had no working solution for me. > Confirmed - I wasn't able to remove ncurses since, as you say, bash has it as a dependency. However, once the build process stopped when running 'tic' I overwrote the installed ncurses libraries with the 5.7 ones from the build directory, and everything was able to complete correctly. (The above patch is still required, however) As a side question: If a binary has a hard-coded rpath, does this override any LD_LIBRARY*_PATH variable that is set?
(In reply to comment #5) > (The above patch is still required, however) applied > As a side question: If a binary has a hard-coded rpath, does this override any > LD_LIBRARY*_PATH variable that is set? nope, LD_LIBRARY_PATH overrides everything
> > As a side question: If a binary has a hard-coded rpath, does this override any > > LD_LIBRARY*_PATH variable that is set? > > nope, LD_LIBRARY_PATH overrides everything > That's what I thought... but setting LD_LIBRARYN32_PATH to the build directory still resulted in 'tic' hanging: I only got it to work by copying the build libncurses*.so DSOs into ${EPREFIX}/lib/ (Yes, this is the correct variable for IRIX: only o32 binaries use LD_LIBRARY_PATH, n32 binaries use LD_LIBRARYN32_PATH, and 64bit binaries use LD_LIBRARY64_PATH. Probably a flexible solution, but potentially confusing. Do other non-Linux 64bit OS have a similar setup?)
I'm not sure if dlopen uses LD_LIBRARY*_PATH. I think IRIX is unique in distinguishing between 32 and 64-bits here.
(In reply to comment #6) > > As a side question: If a binary has a hard-coded rpath, does this override any > > LD_LIBRARY*_PATH variable that is set? > > nope, LD_LIBRARY_PATH overrides everything Err: When an ELF binary does have RPATH, but not RUNPATH, LD_LIBRARY_PATH is ignored. When it does have RUNPATH, LD_LIBRARY_PATH is searched first, and RPATH is ignored, which is the problem in Prefix: Bug#267629
