i386-gentoo-linux-uclibc-gcc -march=i386 -Os -pipe -fomit-frame-pointer -D_GNU_SOURCE -I/usr/include/slang -c -o test.o test.c i386-gentoo-linux-uclibc-gcc -march=i386 -Os -pipe -fomit-frame-pointer -D_GNU_SOURCE -I/usr/include/slang -c -o newt.o newt.c i386-gentoo-linux-uclibc-gcc -march=i386 -Os -pipe -fomit-frame-pointer -D_GNU_SOURCE -I/usr/include/slang -c -o button.o button.c In file included from whiptail.c:12: nls.h:9:22: libintl.h: No such file or directory In file included from dialogboxes.c:12: nls.h:9:22: libintl.h: No such file or directory i386-gentoo-linux-uclibc-gcc -march=i386 -Os -pipe -fomit-frame-pointer -D_GNU_SOURCE -I/usr/include/slang -c -o form.o form.c i386-gentoo-linux-uclibc-gcc -march=i386 -Os -pipe -fomit-frame-pointer -D_GNU_SOURCE -I/usr/include/slang -c -o checkbox.o checkbox.c make: *** [depend] Error 1 make: *** Waiting for unfinished jobs.... NOTE: patches from #206088 needs to be applied first to be able to reproduce.
Created attachment 141111 [details, diff] newt-0.52.7-nonls.patch Attatched patch fixes the problem. ... IUSE="gpm nls tcl" ... use nls || epatch "${FILESDIR}"/${P}-nonls.patch
there's no need to hack it out like that ... if it doesnt already have a standard --disable-nls option to key off of, add one and wrap the header logic in that
(In reply to comment #2) > there's no need to hack it out like that ... if it doesnt already have a > standard --disable-nls option to key off of, add one and wrap the header logic > in that > It does not have a standard --disable-nls option. Adding it would require gettext.m4 which is provided in gettext which is masked on uclibc. If upstream would do that for next release problem would be solved. There was no easy way to find out how to report things upstream (HOMEPAGE points to a major Linux distribution/vendor rather than a project page for newt) I went for the quick and dirty solution and moved on.
Got contact with upstream developer, mlichvar at redhat. Package uses autoconf but not automake so AM_GNU_GETTEXT will not work.
sorry, when i said "standard" i was merely referring to the user interface for building the package so you'd do AC_ARG_ENABLE(....nls..........) and handle the enable/disable stuff yourself rather than relying on adding gettext cruft does that make sense ?
(In reply to comment #5) > sorry, when i said "standard" i was merely referring to the user interface for > building the package > > so you'd do AC_ARG_ENABLE(....nls..........) and handle the enable/disable > stuff yourself rather than relying on adding gettext cruft > > does that make sense ? > yes. thanks!
Created attachment 141126 [details, diff] newt-0.52.7-nonls.patch adds a standard --disable-nls option to the configure script. tested on uclibc x86 (without nls) and glibc amd64 (with nls). patch is submitted to upstream maintainer.
usually people macro away all functions when !NLS: # define setlocale(category,locale # define bindtextdomain(domainname, dirname) .... that way people dont need to sprinkle #ifdef checks throughout their code you should use AC_HELP_STRING([--disable-nls],[compile without NLS support]) otherwise i think this looks good and can be submitted upstream to see how they feel about it
(In reply to comment #8) > usually people macro away all functions when !NLS: > # define setlocale(category,locale > # define bindtextdomain(domainname, dirname) > .... > > that way people dont need to sprinkle #ifdef checks throughout their code Thanks for the tip! Will do this next time. > > you should use AC_HELP_STRING([--disable-nls],[compile without NLS support]) Don't think this is needed. It is already listed under "Optional Features" help text. > > otherwise i think this looks good and can be submitted upstream to see how they > feel about it > I already submitted upstream and he said he would apply it to his CVS. Thanks!
i'm not saying AC_HELP_STRING() will make any practical difference at all ... i'm saying that is the correct way for generating help strings in autotools rather than padding it with whitespace yourself
The patch is included in newt-0.52.8. http://koji.fedoraproject.org/koji/buildinfo?buildID=32661
Could we either bump to 0.52.8 or commit this patch? Would be nice to close this bug. Thanks!
0.52.8 in cvs