| Summary: | dev-libs/libxml2-2.9.10-r4::gentoo_prefix fails to build with Python errors | ||
|---|---|---|---|
| Product: | Gentoo/Alt | Reporter: | iloveosxzfs |
| Component: | Prefix Support | Assignee: | Gentoo Prefix <prefix> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | sam |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | OS X | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | build log | ||
|
Description
iloveosxzfs
2020-12-05 00:22:27 UTC
I suspect it's more of an issue with Python 3.8 too (or the change, w/e) than r3 -> r4 as that was just a trivial crash fix. Created attachment 676720 [details]
build log
Undefined symbols for architecture x86_64:
"_PyArg_ParseTuple", referenced from:
_libxml_xmlDebugMemory in libxml.o
_libxml_xmlParserCtxtGetErrorHandler in libxml.o
_libxml_xmlCreateOutputBuffer in libxml.o
_libxml_xmlCreateInputBuffer in libxml.o
_libxml_xmlRegisterInputCallback in libxml.o
_libxml_xmlCreatePushParser in libxml.o
_libxml_htmlCreatePushParser in libxml.o
...
"_PyBool_Type", referenced from:
_libxml_xmlXPathObjectPtrConvert in types.o
"_PyBytes_AsString", referenced from:
_xmlPythonFileRead in libxml.o
_xmlPythonFileReadRaw in libxml.o
_PystringSet_Convert in libxml.o
etc.
I think python3.8's config is messed up: Josephs-MacBook-Pro-2% python3.8-config --libs -lintl -ldl -framework CoreFoundation Josephs-MacBook-Pro-2% python3.7-config --libs -lpython3.7m -lintl -ldl -framework CoreFoundation Josephs-MacBook-Pro-2% Ditto ldflags. Adding -lpython3.8 to PYTHON_LIBS in $EPREFIX/var/tmp/portage/dev-libs/libxml2-2.9.10-r4/work/libxml2-2.9.10-abi_x86_64.amd64-python3_8/python/Makefile gets it to build. In general, I think the python upgrade that was done is extremely messy, because it just swaps out 3.7 for 3.8, leaving no hybrid/upgrade path. I think in your case you'll find (like me) that eselect python show results in 3.7, while only 3.8 is being built. E.g. 3.8 needs to be made python's default. We need a fixed Portage, then bootstrap with 3.8 and snapshot upgrade, to make sure 3.7 isn't in play at all during a bootstrap. (In reply to iloveosxzfs from comment #3) > I think python3.8's config is messed up: > > Josephs-MacBook-Pro-2% python3.8-config --libs > -lintl -ldl -framework CoreFoundation > Josephs-MacBook-Pro-2% python3.7-config --libs > -lpython3.7m -lintl -ldl -framework CoreFoundation > Josephs-MacBook-Pro-2% > > Ditto ldflags. > > > Adding -lpython3.8 to PYTHON_LIBS in > $EPREFIX/var/tmp/portage/dev-libs/libxml2-2.9.10-r4/work/libxml2-2.9.10- > abi_x86_64.amd64-python3_8/python/Makefile gets it to build. you're right, we probably have a messed up python. Dropping gnome@, this has nothign to do with libxml2. python3.8-config actually does this on purpose :/ % python3.8-config --libs --embed -lpython3.8 -lintl -ldl -framework CoreFoundation Linux seems to do exactly the same here. Getting confused. I think the difference here is that the darwin linker doesn't like unresolved symbols also on shared objects, unlike GNU ld. Normally the runtime link, will resolve the python symbols, it's a python module after all, thus run from the python interpreter. I think we better add -lpythonX.X back to libs, e.g. defaulting to --embed. I actually think this is a libtool problem, it should add -undefined dynamic_lookup when using -module, but it seems not to do this oh this is because of darwin20, 11.x. dang! With corresponding configure patches as well: https://raw.githubusercontent.com/Homebrew/formula-patches/e5fbd46a25e35663059296833568667c7b572d9a/libtool/dynamic_lookup-11.patch The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/elt-patches.git/commit/?id=f682fed75c79293cebc23e5c0e0d9cf4255dd541 commit f682fed75c79293cebc23e5c0e0d9cf4255dd541 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2020-12-05 13:45:55 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2020-12-05 13:45:55 +0000 darwin20-conf: add patch for detection of newer macOS Make sure we act like previous release on darwin20, a.k.a. Big Sur 11.0. Bug: https://bugs.gentoo.org/758473 Signed-off-by: Fabian Groffen <grobian@gentoo.org> eltpatch.in | 4 ++-- patches/darwin20-conf/2.4.6 | 13 +++++++++++++ 2 files changed, 15 insertions(+), 2 deletions(-) Unfortunately, I don't think upstream has done anything with the patch submitted by Jeremy Huddleston Sequoia in https://lists.gnu.org/archive/html/libtool-patches/2020-06/msg00001.html Fabian Groffen, so I think that your patch leaves libtool-9999.ebuild still broken, since unlike in the patch submitted upstream, you didn't change the m4 file as well. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bb38524702384def9d248bfdc092b44537b1eef8 commit bb38524702384def9d248bfdc092b44537b1eef8 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2020-12-05 15:18:07 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2020-12-05 15:18:18 +0000 app-portage/elt-patches-20201205: version bump for macOS Big Sur fix Closes: https://bugs.gentoo.org/758473 Package-Manager: Portage-3.0.9, Repoman-3.0.2 Signed-off-by: Fabian Groffen <grobian@gentoo.org> app-portage/elt-patches/Manifest | 1 + .../elt-patches/elt-patches-20201205.ebuild | 24 ++++++++++++++++++++++ 2 files changed, 25 insertions(+) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=058248dc0b88843d3537eeefe1a161b973490907 commit 058248dc0b88843d3537eeefe1a161b973490907 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2020-12-05 13:18:51 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2020-12-05 15:18:18 +0000 sys-devel/libtool-2.4.6: add macOS Big Sur patch Not rev-bumping because this rarely hits, instead elt-patches is solving this. Bug: https://bugs.gentoo.org/758473 Package-Manager: Portage-3.0.9, Repoman-3.0.2 Signed-off-by: Fabian Groffen <grobian@gentoo.org> sys-devel/libtool/files/libtool-2.4.6-darwin20.patch | 13 +++++++++++++ sys-devel/libtool/libtool-2.4.6-r6.ebuild | 1 + 2 files changed, 14 insertions(+) (In reply to iloveosxzfs from comment #13) > Unfortunately, I don't think upstream has done anything with the patch > submitted by Jeremy Huddleston Sequoia in > https://lists.gnu.org/archive/html/libtool-patches/2020-06/msg00001.html > > > Fabian Groffen, so I think that your patch leaves libtool-9999.ebuild still > broken, since unlike in the patch submitted upstream, you didn't change the > m4 file as well. Yeah, but 9999 will be just broken for us. In general the 9999 versions shouldn't be used, and I don't want to risk a patch failure, if they do commit something. In other words, this was sort of intended. The elt-patches should take care of most of the scenarios we'd see this going wrong (as most notably, this libxml2). |
