Bug 206302 - [PATCH] dev-libs/newt-0.52.7 fails to compile with uclibc due to missing libintl.h
|
Bug#:
206302
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: embedded@gentoo.org
|
Reported By: natanael.copa@gmail.com
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: [PATCH] dev-libs/newt-0.52.7 fails to compile with uclibc due to missing libintl.h
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2008-01-17 08:43 0000
|
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.
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 an attachment (id=141126) [details]
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
Could we either bump to 0.52.8 or commit this patch? Would be nice to close
this bug.
Thanks!