Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 674070 - dev-lang/python-3.7.0: Fails to cross-compile because wrong ncurses headers are used
Summary: dev-lang/python-3.7.0: Fails to cross-compile because wrong ncurses headers a...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Python Gentoo Team
URL: https://bugs.python.org/issue28190
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-30 10:35 UTC by James Le Cuirot
Modified: 2019-05-02 20:54 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James Le Cuirot gentoo-dev 2018-12-30 10:35:11 UTC
The precise nature of this changed in 3.6.1 and again in 3.7.0, where it finally caused the build to fail.

Before 3.6.1, configure.ac and setup.py unconditionally added -I/usr/include/ncursesw to CPPFLAGS. This was bad but usually worked.

In 3.6.1, they changed this to only happen when not cross-compiling. The build would pass but with implicit declaration warnings. It didn't fail outright because #include <ncurses.h> would pick up /usr/include/ncurses.h instead, which is the non-unicode version.

In 3.7.0, they added -Werror=implicit-function-declaration, causing it to actually fail.

This can also potentially affect prefix systems as obviously /usr/include/ncursesw is not correct there either though there is a chance it will be present anyway.

I wanted to have this addressed upstream. I had hoped to use libtool's ${lt_sysroot} variable but it turns out Python doesn't use libtool. configure.ac already uses pkg-config so I attempted to use this instead. That's when I discovered that configure.ac actually throws the ncurses CPPFLAGS away after doing some checks. It is setup.py that actually adds the flag used when building the module later on. That script doesn't use pkg-config at all and I think I'd have a hard time convincing upstream to do so, especially when you would still need a correctly configured environment for pkg-config to work. They have already said that they expect users attempting to cross-compile to set their own CPPFLAGS manually.

This ultimately leads to a couple of extra lines in the ebuild:

  use ncurses &&
      append-cppflags -I${ESYSROOT}/usr/include/ncursesw

Ideally we would use ${ESYSROOT} as above but that requires EAPI 7. Is there any particular reason why it's not been applied yet? All the applicable eclasses support it now. Failing that, ${SYSROOT}${EPREFIX} would be close enough in the short term.

Please let me know how you'd like to proceed and I can do the work myself. This could be applied to just 3.7 but perhaps 3.6 would be a good idea too.
Comment 1 Larry the Git Cow gentoo-dev 2019-05-02 20:54:50 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=09c5b2bd7725ac3d7604a97987553c134465bdf8

commit 09c5b2bd7725ac3d7604a97987553c134465bdf8
Author:     James Le Cuirot <chewi@gentoo.org>
AuthorDate: 2019-05-02 20:53:17 +0000
Commit:     James Le Cuirot <chewi@gentoo.org>
CommitDate: 2019-05-02 20:54:34 +0000

    dev-lang/python: Fix implicit ncurses declarations in 3.7.3
    
    Closes: https://bugs.gentoo.org/674070
    Package-Manager: Portage-2.3.66, Repoman-2.3.12
    Signed-off-by: James Le Cuirot <chewi@gentoo.org>

 dev-lang/python/python-3.7.3.ebuild | 3 +++
 1 file changed, 3 insertions(+)