New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Symbol resolution conflict when embeding python in an application using libedit #82815
Comments
See https://bugs.llvm.org/show_bug.cgi?id=43830, but basically the follwing code:
compiled like this:
runs fine:
However the following:
compiles but segfaults at runtime. |
This appears to be essentially a duplicate of bpo-13631 which has long proposed full support of libedit. |
@ned I(d rather see this as an evolution of bpo-13631, as this solves a problem when libreadline and libedit are both loaded in the same executable. As such, using libedit instead of readline wouldn't solve the issue: what if the program Python is embeded in is linked to readline? I find python approach relatively elegant: detect the linked library at runtime and use the ad-hoc implementation based on this. An other option would be to dlopen readline using the RTLD_LOCAL flag, so that we get a better, non intrusive symbol resolution. What do you think? |
Thanks serge-sans-paille for the bug report and the fix! I backported it to 3.8 since it could be automated, but I don't think that it's worth it to backport it to 3.7: |
FWIW I just ran into what I believe to be this bug with the Launchpad test suite on Python 3.6.9. The output shows some normal test output followed by: No entry for terminal type "unknown"; The test suite imports a lot of stuff, but it includes something which links against libLLVM which links against libedit (I haven't worked out exactly what, but probably GTK-related). Then something else much later imports readline - again, I haven't worked out what yet, as it's taken me a day just to set up the exact right environment in which to reproduce this at all and an strace doesn't make the cause of the import especially clear. So I understand why you see this as a rare use case, but it's *extremely* confusing and a massive time sink when you do run across it, as the cause is a long way distant from the effect and it can arise in situations where it is in no way deliberate to have this sort of setup, but rather an emergent effect of several other things. |
Here's a reasonably minimal reproduction recipe reduced from real code in the Launchpad test suite that doesn't require compiling a separate C extension. It fails on Ubuntu 18.04 with the gir1.2-gtk-3.0, python3-gi, and xvfb packages installed. (The xvfb-run part is just so that it works on a headless system; you can omit it if you have a working $DISPLAY.) xvfb-run python3 -c 'from gi.repository import Gtk; import readline' |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: