[issue38634] Symbol resolution conflict when embeding python in an application using libedit
New submission from serge-sans-paille :
See https://bugs.llvm.org/show_bug.cgi?id=43830, but basically the follwing
code:
```
// a.c
#include
int main() {
Py_Initialize();
PyRun_SimpleString("import readline; print(readline.__doc__)");
return 0;
}
```
compiled like this:
```
% gcc a.c `./install/bin/python3-config --cflags --ldflags --libs` -lpython3.9
```
runs fine:
```
% ./a.out
Importing this module enables command line editing using GNU readline.
```
However the following:
```
% gcc a.c `./install/bin/python3-config --cflags --ldflags --libs` -ledit
-lpython3.9
```
compiles but segfaults at runtime.
--
messages: 355656
nosy: serge-sans-paille
priority: normal
severity: normal
status: open
title: Symbol resolution conflict when embeding python in an application using
libedit
type: crash
___
Python tracker
<https://bugs.python.org/issue38634>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38634] Symbol resolution conflict when embeding python in an application using libedit
Change by serge-sans-paille : -- keywords: +patch pull_requests: +16512 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16986 ___ Python tracker <https://bugs.python.org/issue38634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13501] Make libedit support more generic; port readline / libedit to FreeBSD
Change by serge-sans-paille : -- pull_requests: +16513 pull_request: https://github.com/python/cpython/pull/16986 ___ Python tracker <https://bugs.python.org/issue13501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38634] Symbol resolution conflict when embeding python in an application using libedit
serge-sans-paille added the comment: @ned I(d rather see this as an evolution of Issue13631, 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? -- ___ Python tracker <https://bugs.python.org/issue38634> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42207] Python 3.9 testing fails when building with clang and optimizations are enabled
New submission from serge-sans-paille : How to reproduce: ``` git clone https://github.com/python/cpython && cd cpython mkdir -p _build/optimized cd _build/optimized ../../configure --enable-optimizations CC=clang make cd .. ./optimized/python -m test.regrtest -wW --slowest -j0 --timeout=1800 2>&1 | grep "error: Could not read profile code.profclangd" ``` This bug no longer happens on master branch because it's related to test_peg_generator. -- components: Build messages: 379972 nosy: serge-sans-paille priority: normal severity: normal status: open title: Python 3.9 testing fails when building with clang and optimizations are enabled versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue42207> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42207] Python 3.9 testing fails when building with clang and optimizations are enabled
Change by serge-sans-paille : -- keywords: +patch pull_requests: +21955 stage: -> patch review pull_request: https://github.com/python/cpython/pull/23037 ___ Python tracker <https://bugs.python.org/issue42207> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42207] Python 3.9 testing fails when building with clang and optimizations are enabled
Change by serge-sans-paille : -- pull_requests: +22054 pull_request: https://github.com/python/cpython/pull/23141 ___ Python tracker <https://bugs.python.org/issue42207> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37140] ctypes change made clang fail to build
Change by serge-sans-paille : -- nosy: +serge-sans-paille ___ Python tracker <https://bugs.python.org/issue37140> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37140] ctypes change made clang fail to build
serge-sans-paille added the comment: @vstinner: to reproduce the issue ``` git clone https://github.com/llvm/llvm-project.git cd llvm-project mkdir _build cd _build cmake3 ../llvm -DLLVM_ENABLE_PROJECTS="clang;clang-tools-extra" -DBUILD_SHARED_LIBS=ON -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=$PWD/install -DPYTHON_EXECUTABLE=$HOME/sources/cpython/_build/install/bin/python3 make -j4 ``` -- ___ Python tracker <https://bugs.python.org/issue37140> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36618] clang expects memory aligned on 16 bytes, but pymalloc aligns to 8 bytes
serge-sans-paille added the comment: @vstinner: once you have a portable version of alignof, you can deciding to *not* use the pool allocator if the required alignment is greater than 8B, or you could modify the pool allocator to take alignment information as an extra parameter? -- nosy: +serge-sans-paille ___ Python tracker <https://bugs.python.org/issue36618> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28015] configure --with-lto builds fail when CC=clang on Linux, requires gold linker
serge-sans-paille added the comment: Looks like a package dependency issue: installing ``llvm-dev`` package should fix the problem. Or in that particular case ``llvm-3.8-dev``. -- nosy: +serge-sans-paille ___ Python tracker <https://bugs.python.org/issue28015> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34814] makesetup: must link C extensions to libpython when compiled in shared mode
serge-sans-paille added the comment:
Not an expert of Python build, but I've been creating a few « reverse engineer
challenge » where I had to ship modified version of the interpreter, so played
with it a bit.
I agree consistency is nice to reason about. It looks better to me to *not*
link with libpython.so directly. This is probably better as this does not make
``libpython`` an install requirement (e.g. when one wants to embed a minimal
version of python)
As a short check, I ran
```
nm libpython3.so | grep ' [tT] ' | cut -d ' ' -f 3 | while read line; do nm
python | grep ' [tT] ' | cut -d ' ' -f 3 | grep $line >/dev/null || { echo
"bad: $line"; break; }; done
```
and everything looks fine, so all symbols should already be in the interpreter.
I've also checked whether that's an issue or not for user-defined native
extensions and everything runs smoothly without the explicit dep.
So the argument would be: why adding this dep when it's not needed?
--
nosy: +serge-sans-paille
___
Python tracker
<https://bugs.python.org/issue34814>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25657] virtualenv's activate does not update LD_LIBRARY_PATH
New submission from serge-sans-paille: My use cas of virtual env was the following: 1. create a virtual env 2. install a third party shared library and its python wrapper 3. import the wrapper that itself loads the shared library The problem is that the shared library gets install into /lib (which is a normal behavior) but virtualenv's activate does not update LD_LIBRARY_PATH A possible fix would be to add the following lines into virtualenv's activate: ``` if [ -n "$_OLD_VIRTUAL_LD_LIBRARY_PATH" ] ; then PATH="$_OLD_VIRTUAL_LD_LIBRARY_PATH" export LD_LIBRARY_PATH unset _OLD_VIRTUAL_LD_LIBRARY_PATH fi ``` and a bit later ``` _OLD_VIRTUAL_LD_LIBRARY_PATH="$LD_LIBRARY_PATH" LD_LIBRARY_PATH="$VIRTUAL_ENV/lib:$LD_LIBRARY_PATH" export LD_LIBRARY_PATH ``` in a simialr manner to what is done with `PATH` -- messages: 254845 nosy: serge-sans-paille priority: normal severity: normal status: open title: virtualenv's activate does not update LD_LIBRARY_PATH type: enhancement versions: Python 2.7 ___ Python tracker <http://bugs.python.org/issue25657> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25657] virtualenv's activate does not update LD_LIBRARY_PATH
serge-sans-paille added the comment: ok, I'll report there then. Sorry for the noise :-/ -- resolution: -> not a bug status: open -> closed ___ Python tracker <http://bugs.python.org/issue25657> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
