Summary: | dev-lang/python: wrong --host for cross compilation | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Janpieter Sollie <janpieter.sollie> |
Component: | Current packages | Assignee: | Python Gentoo Team <python> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | ionen, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=880059 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
env file config.log build log with no cflags config.log with no clfags |
Description
Janpieter Sollie
2022-11-07 07:45:47 UTC
Please always include the full build.log and config.log. I'm not sure what you mean by "unwanted" but it's unavoidable if you read the details as to why we added it. Probably a dupe of bug 880059. *** This bug has been marked as a duplicate of bug 880059 *** Created attachment 828215 [details]
build.log
Created attachment 828217 [details]
env file
(In reply to Sam James from comment #1) > Please always include the full build.log and config.log. I'm not sure what > you mean by "unwanted" but it's unavoidable if you read the details as to > why we added it. > > Probably a dupe of bug 880059. > > *** This bug has been marked as a duplicate of bug 880059 *** when you see in the configure parameters, you'll notice --build and --host are included twice, the second one specifying the wrong chost (In reply to Janpieter Sollie from comment #4) > (In reply to Sam James from comment #1) > > Please always include the full build.log and config.log. I'm not sure what > > you mean by "unwanted" but it's unavoidable if you read the details as to > > why we added it. > > > > Probably a dupe of bug 880059. > > > > *** This bug has been marked as a duplicate of bug 880059 *** > > when you see in the configure parameters, you'll notice --build and --host > are included twice, the second one specifying the wrong chost Please share config.log too. And yes, that's fine, because the *first* built Python must be for CBUILD and have CBUILD==CHOST. It then builds another one later. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e5cb1ccc95873d55f9f643b043f3f7493fd31eee commit e5cb1ccc95873d55f9f643b043f3f7493fd31eee Author: Sam James <sam@gentoo.org> AuthorDate: 2022-11-07 07:57:49 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-11-07 07:57:49 +0000 dev-lang/python: append ncurses include path after CBUILD Python is built We don't want to contaminate the mini CBUILD Python cross build with paths in SYSROOT. Bug: https://bugs.gentoo.org/880059 Bug: https://bugs.gentoo.org/880137 Signed-off-by: Sam James <sam@gentoo.org> dev-lang/python/python-3.10.8_p2.ebuild | 10 +++++----- dev-lang/python/python-3.11.0_p1.ebuild | 10 +++++----- dev-lang/python/python-3.12.0_alpha1_p1.ebuild | 10 +++++----- dev-lang/python/python-3.8.15_p2.ebuild | 10 +++++----- dev-lang/python/python-3.9.15_p2.ebuild | 10 +++++----- 5 files changed, 25 insertions(+), 25 deletions(-) Created attachment 828219 [details]
config.log
thanks, I'll look at it more later today (In reply to Sam James from comment #8) > thanks, I'll look at it more later today in reply of your remark at bug 880059: > --- Comment #6 from Sam James <sam@gentoo.org> --- > I don't think the ncurses bit is sufficient, just a start. Can you share the config.logs? I tried to build it using `USE="-ncurses" aarch64-unknown-gnu-emerge` but the error message stays the same Yeah, I need the two config.logs for tt_1s bug. Not related to this one I think now. as a workaround for now: drop znver from cflags (In reply to Sam James from comment #11) > as a workaround for now: drop znver from cflags nope, didn't work. Configure fails again. I'll add the second config.log and build.log Created attachment 828225 [details]
build log with no cflags
Created attachment 828239 [details]
config.log with no clfags
Are you setting CC explicitly somewhere in your environment, ditto HOSTCC? (setting CC by itself is OK for me, it seems) (In reply to Sam James from comment #15) > Are you setting CC explicitly somewhere in your environment, ditto HOSTCC? > (setting CC by itself is OK for me, it seems) This could be, I'm experimenting a lot with different compilers these days, it might be some leftover I forgot. Nonetherless, shouldn't you see this in the environment file I attached? (In reply to Janpieter Sollie from comment #16) > (In reply to Sam James from comment #15) > > Are you setting CC explicitly somewhere in your environment, ditto HOSTCC? > > (setting CC by itself is OK for me, it seems) > This could be, I'm experimenting a lot with different compilers these days, > it might be some leftover I forgot. > Nonetherless, shouldn't you see this in the environment file I attached? The question is whether you're setting it as a human or if it's accidental, and also why. In case unclear, HOSTCC being set is overriding the right CC value that it's supposed to use at this step. ebuilds typically don't control variables meant to override things, so it's on you to clear it up /if/ it was actually set by you (e.g. some make.conf or package.env files) environment file just says that it is set, but it doesn't really say where it's from your idea actually fixes the issue: I used grep -R "HOSTCC" in /etc and /usr/aarch64-unknown-linux-gnu/etc, and found I set it in /usr/aarch64-unknown-linux-gnu/etc/portage/make.conf, in a desperate attempt to compile something which reverted to the wrong compiler. Commenting out everything fixed it. Sorry for reporting a bug that was a feature :( |