Summary: | =sys-apps/portage/-2.3.62-r1 segfaults on all merges | ||
---|---|---|---|
Product: | Portage Development | Reporter: | matoro <matoro_gentoo> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED INVALID | ||
Severity: | major | CC: | matoro_gentoo |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | backtrace |
Description
matoro
2019-04-12 15:28:48 UTC
Created attachment 572600 [details]
backtrace
You can try this to see if it also affects the python2 interpreter: python2 /usr/bin/emerge [args] I have python2 installed, but do not have portage built for it. So I only get the following message: /usr/lib/python-exec/python2.7/emerge: this Python implementation (python2.7) is not supported by the script. Since portage is not built for python2, you can `git clone https://anongit.gentoo.org/git/proj/portage.git` or unpack http://distfiles.gentoo.org/distfiles/portage-2.3.62.tar.bz2, and then use the PYTHONPATH/PATH approach described here: https://wiki.gentoo.org/wiki/Project:Portage#Testing_Portage Use: python2 /checkouts/portage/bin/emerge [arg]... Thank you! That was able to rescue my portage build. I rebuild both python and portage, though the most likely suspect is the native-extensions module. Unsure of how it got in this state - should dev-libs/isl bumps force a sys-apps/portage rebuild in the future? From the backtrace it looks like an issue with library loading via ctypes, so maybe just a python rebuild would have been enough? @zmedico: The issue popped up again for me, and now that I had a way to fix it I was able to do some more tests. Surprisingly, it actually seems to be openssl-related. I found that I had been downgraded to a 1.1.0x version of openssl due to some dependency, as opposed to the 1.1.1 version the system was built against. Using python2 to reinstall the 1.1.1 binary package makes the installed portage functional again, no rebuild necessary. I am not quite sure of the answers to a number of questions, namely: - Why does python2 work but python3 does not, when they are both built against openssl-1.1.1? - Why does the segfault only occur when merging a package, and not immediately upon startup of the python interpreter? Is this because it is related to a native module, and python loads them dynamically? - If that's the case, what does openssl have to do with the portage native module? Isn't it only used for filesystem operations? I don't know if any of these questions will ever get answered, but for now I've hopefully put it to rest by tightening up my version masks on dev-libs/openssl and enabling splitdebug features on this system. Thank you for the help. The openssl-1.1 libraries should have different sonames from the openssl-1.0 libraries, so FEATURES=preserve-libs should preserve the openssl-1.1 libraries when necessary, and things should keep working. |