In the widec phase of the ncurses build, the local (CBUILD) compiler is called to compile the make_hash helper program. Since the local compiler uses a different set of CPPFLAGS than the target compiler, the cc call is missing -D_GNU_SOURCE, resulting in errors because of cchar_t not being defined. This patch fixes that by adding the target CPPFLAGS to those used by the local compiler.
Created attachment 147222 [details, diff] patch to fix cross compilation of widec ncurses
Comment on attachment 147222 [details, diff] patch to fix cross compilation of widec ncurses let's not go this route ... please locate the place where -D_GNU_SOURCE gets added to CPPFLAGS and simply update it to also add it to BUILD_CPPFLAGS
The reason I didn't do that is that -D_GNU_SOURCE is added by the CF_XOPEN_SOURCE macro (aclocal.m4:4898), which (rightly afaict) doesn't care whether or not the BUILD_CPPFLAGS variable even exists, which it wouldn't in packages that don't use CF_BUILD_CC to configure a build compiler.
hrm ... just adding CPPFLAGS to BUILD_CPPFLAGS really only works when the $build is relatively close to $host ... maybe just ask upstream about the issue and see what they want to do about it ...
Thomas: any thoughts on how you'd like to address this ?
I hadn't considered this (since my testing with djgpp won't build wide). Just adding CPPFLAGS does have drawbacks - will investigate.
*** Bug 234681 has been marked as a duplicate of this bug. ***
There is a non-upstream patch: http://svn.exactcode.de/t2/trunk/package/base/ncurses/cross-build.patch It may help someone sticking with this bug.
*** Bug 252530 has been marked as a duplicate of this bug. ***
Can this patch be pooled to portage upstream? It is really important for cross compiling with USE="nls unicode" --- a/sys-libs/ncurses/ncurses-5.7.ebuild +++ b/sys-libs/ncurses/ncurses-5.7.ebuild @@ -26,10 +26,12 @@ src_unpack() { cd "${S}" [[ -n ${PV_SNAP} ]] && epatch "${WORKDIR}"/${MY_P}-${PV_SNAP}-patch.sh epatch "${FILESDIR}"/${PN}-5.6-gfbsd.patch + epatch "${FILESDIR}"/cross-build.patch } src_compile() {
i can confirm this bug as well, i am cross-compiling for armv4tl-softfloat-linux-gnueabi
Created attachment 181230 [details] build log In reply to comments #8 and #10, build fails with this error. Compiling for armv4tl-softfloat-linux-gnueabi using crossdev-wrappers.
The place to change is not in the ncurses source, but in the ebuild script. I'd add this to the configure flags --with-build-cppflags=-D_GNU_SOURCE
I'd be happy to test, but i can't figure out where to add that, could you please enlighten me? (In reply to comment #13) > The place to change is not in the ncurses source, but in the ebuild script. > > I'd add this to the configure flags > > --with-build-cppflags=-D_GNU_SOURCE >
okay, works, here is what i did: sys-libs/ncurses/ncurses-5.6-r2.ebuild: instead of local myconf="" i did local myconf="--with-build-cppflags=-D_GNU_SOURCE" and emerged it, it woked nicely, the same thing doesn't work for ncurses-5.7 though. (In reply to comment #14) > I'd be happy to test, but i can't figure out where to add that, could you > please enlighten me? > > (In reply to comment #13) > > The place to change is not in the ncurses source, but in the ebuild script. > > > > I'd add this to the configure flags > > > > --with-build-cppflags=-D_GNU_SOURCE > > >
your /usr/arm/glibc or cross/glibc compiled without nls support. I don't known exactly but I think you should recompile your /usr/arm/glibc with USE="nls" flag. May be you have "gettext" dependency problem - don't afraid use built_in gettext in glibc (--nodeps).
(In reply to comment #14) Previous message is replying to comment #14.
(In reply to comment #13) Thanks for the suggestion. People wanting to test -- this change is only needed when cross-compiling, so what you want to add is something like this: # add flags for native build, bug 214642 tc-is-cross-compiler && myconf="${myconf} --with-build-cppflags=-D_GNU_SOURCE" somewhere between the declaration of myconf and where the compiling begins. The ebuild already inherits toolchain-funcs so no additional inherit is needed. (In reply to comment #15) > it woked nicely, the same thing doesn't work for ncurses-5.7 though. In what way did it not work?
This bug is now 4 months old and there seems to be a solution - why doesn't this go upstream? Is it because someone reported a (most likely non-existent) bug which he didn't comment at all?
(In reply to comment #18) > In what way did it not work? ncurses-5.7: I don't know why, but it doesn't work. Patch in comment #10 (little bit reworked - works) What should be done, to get it upstream?
Sorry, forgot to mention, I built ncurses-5.7 with the fix on armv4t (crosscompiler on amd64) and it worked just fine.
the fix in comment #18 (the fix recommended by ncurses upstream in comment #13) is the one that should be applied, not any patch to ncurses source. it has not been applied in portage because no one has tested it and reported back here.
In reply to #22: To clarify: The ebuild-fix (#18) was the one I applied, WORKSFORME. If it doesn't fail for anyone please take it upstream.
(In reply to comment #23) > The ebuild-fix (#18) was the one I applied, WORKSFORME. thank you. base-system, anything else stopping this from going in-tree?
should be fixed with ncurses-5.7-r1
