[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:

[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/issu

[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/issue13

[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 Pyth

[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 --time

[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/issu

[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/issue42

[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 Unsub

[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_TY

[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

[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 <ht

[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*

[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

[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.