cxx-users — Discuss the use and improvement of PyCXX

Re: OpenBSD 7.4-current port and test produces an Abort trap at callback_bad with 'callback_args string'

[Barry S. <ba...@ba...>]

> On 14 Dec 2023, at 06:28, Matti Viljamaa <mav...@gm...> wrote:
> 
> What are the used eg++ and g++ versions here?
> 

At this point you should be able to work the issues with the compiler yourself.
You do not need any special PyCXX knowledge.

I will be committing changes to the by build scripts to support openbsd so that testing is easier.

Here are the versions of the compiler:

$ eg++ -v
Using built-in specs.
COLLECT_GCC=eg++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-openbsd7.4/11.2.0/lto-wrapper
Target: x86_64-unknown-openbsd7.4
Configured with: /usr/obj/ports/gcc-11.2.0/gcc-11.2.0/configure --with-as=/usr/local/bin/gas --with-stage1-ldflags=-L/usr/obj/ports/gcc-11.2.0/bootstrap/lib --verbose --program-transform-name='s,^,e,' --disable-nls --with-system-zlib --disable-libmudflap --disable-libgomp --disable-libssp --disable-tls --with-gnu-ld --with-gnu-as --enable-threads=posix --enable-wchar_t --with-gmp=/usr/local --enable-languages=c,c++,fortran,objc,ada,d --disable-libstdcxx-pch --enable-default-pie --enable-standard-branch-protection --without-isl --enable-default-ssp --enable-cpp --prefix=/usr/local --sysconfdir=/etc --mandir=/usr/local/man --infodir=/usr/local/info --localstatedir=/var --disable-silent-rules --disable-gtk-doc
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.0 (GCC)

$ egcc -v
Using built-in specs.
COLLECT_GCC=egcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-openbsd7.4/11.2.0/lto-wrapper
Target: x86_64-unknown-openbsd7.4
Configured with: /usr/obj/ports/gcc-11.2.0/gcc-11.2.0/configure --with-as=/usr/local/bin/gas --with-stage1-ldflags=-L/usr/obj/ports/gcc-11.2.0/bootstrap/lib --verbose --program-transform-name='s,^,e,' --disable-nls --with-system-zlib --disable-libmudflap --disable-libgomp --disable-libssp --disable-tls --with-gnu-ld --with-gnu-as --enable-threads=posix --enable-wchar_t --with-gmp=/usr/local --enable-languages=c,c++,fortran,objc,ada,d --disable-libstdcxx-pch --enable-default-pie --enable-standard-branch-protection --without-isl --enable-default-ssp --enable-cpp --prefix=/usr/local --sysconfdir=/etc --mandir=/usr/local/man --infodir=/usr/local/info --localstatedir=/var --disable-silent-rules --disable-gtk-doc
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.2.0 (GCC)

Re: OpenBSD 7.4-current port and test produces an Abort trap at callback_bad with 'callback_args string'

[Matti V. <mav...@gm...>]

What are the used eg++ and g++ versions here?

They said at https://matrix.to/#/#openbsd:matrix.org that the compilers
should have feature parity. Possibly the used versions differ?

On Wed, Dec 13, 2023 at 5:52 PM Barry Scott <ba...@ba...> wrote:

> The problem is that eg++ has no working support for C++ exceptions.
>
> The following simple C++ program fails to work:
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <iostream>
>
> int main()
> {
>     std::cout << "Hello" <<std::endl;
>     try
>     {
>         throw 20;
>     }
>     catch (int e)
>     {
>         std::cout << "catch of " << e << std::endl;
>     }
>     return 0;
> }
>
> On Fedora 39 I get this:
>
> $ g++ -g -O0 -o a a.cpp
> $ ./a
> Hello
> catch of 20
>
>
> On OpenBSD 7.4 I get this:
>
> $ eg++ -g -O0 -o a a.cpp
> $ ./a
> Hello
> Abort trap (core dumped)
>
> And with explicit option:
>
> $ eg++ -g -O0 -o a -fexceptions a.cpp; ./a
> Hello
> Abort trap (core dumped)
>
> Fix the compiler and PyCXX should work.
>
> Barry
>
>
>
>
> On 13 Dec 2023, at 11:10, Barry Scott <ba...@ba...> wrote:
>
> I now have an old laptop with OpenBSD 7.4 installed.
> Was way harder then it should be to install this OS...
>
> I'll try and repro what you are seeing.
>
> My working guess is that the compile options broke C++ exception handing.
>
> Barry
>
>
>
> On 11 Dec 2023, at 09:06, Matti Viljamaa <mav...@gm...> wrote:
>
> FYI, I am replicating the issue at po...@op... mailing list to get
> different views:
>
> https://marc.info/?l=openbsd-ports&m=170227787921446&w=2
>
> On Sat, Dec 9, 2023 at 2:45 PM Matti Viljamaa <mav...@gm...>
> wrote:
>
>> Maybe the following is helpful:
>>
>> (gdb) bt
>> #0  thrkill () at /tmp/-:2
>> #1  0xf7a555255abd010d in ?? ()
>> #2  0x000000d3e7980c52 in _libc_abort () at
>> /usr/src/lib/libc/stdlib/abort.c:51
>> #3  0x000000d4b9c3ce70 in uw_init_context_1 (
>>     context=<error reading variable: dwarf2_find_location_expression:
>> Corrupted DWARF expression.>, context@entry=0x794f944a9560,
>>     outer_cfa=<error reading variable: dwarf2_find_location_expression:
>> Corrupted DWARF expression.>, outer_cfa@entry=0x794f944a9910,
>>     outer_ra=<error reading variable: dwarf2_find_location_expression:
>> Corrupted DWARF expression.>) at
>> /usr/obj/ports/gcc-11.2.0/gcc-11.2.0/libgcc/unwind-pe.h:88
>> #4  0x000000d4b9c3c5d9 in _Unwind_RaiseException (exc=0xd3f70264c0)
>>     at /usr/obj/ports/gcc-11.2.0/gcc-11.2.0/libgcc/unwind.inc:93
>> #5  0x000000d4b9b25414 in __cxxabiv1::__cxa_throw (obj=<optimized out>,
>>     tinfo=0xd3f5aaa770 <typeinfo for Py::ValueError>,
>>     dest=0xd3f5a9a6e2 <Py::ValueError::~ValueError()>)
>>     at
>> /usr/obj/ports/gcc-11.2.0/gcc-11.2.0/libstdc++-v3/libsupc++/eh_throw.cc:90
>> #6  0x000000d3f5a9a73d in Py::ValueError::throwFunc ()
>>     at ./CXX/Python3/cxx_standard_exceptions.hxx:74
>> #7  0x000000d3f5a98426 in Py::ifPyErrorThrowCxxException ()
>>     at Src/Python3/cxx_exceptions.cxx:41
>> #8  0x000000d3f5a80e1c in Py::Callable::apply (this=0x794f944a9a40,
>> args=...)
>>     at ./CXX/Python3/Objects.hxx:3241
>> #9  0x000000d3f5a842c8 in simple_module::func_with_callback
>> (this=0xd45b2ef460,
>>     args=...) at Demo/Python3/simple.cxx:351
>> #10 0x000000d3f5a8b513 in
>> Py::ExtensionModule<simple_module>::invoke_method_keyword (
>>     this=0xd45b2ef460, method_def=0xd410e7b420, args=..., keywords=...)
>>     at ./CXX/Python3/ExtensionModule.hxx:192
>> #11 0x000000d3f5a9524d in Py::method_keyword_call_handler (Python
>> Exception <class 'gdb.error'> There is no member named ob_item.:
>> _self_and_name_tuple=, Python Exception <class 'gdb.error'> There is no
>> member named ob_item.:
>>
>>     _args=, _keywords=0x0) at Src/Python3/cxx_extensions.cxx:1695
>> #12 0x000000d41f076d1c in cfunction_call () from
>> /usr/local/lib/libpython3.10.so.0.0
>> #13 0x000000d41f01cc75 in _PyObject_MakeTpCall ()
>>    from /usr/local/lib/libpython3.10.so.0.0
>> #14 0x000000d41f129e60 in call_function () from
>> /usr/local/lib/libpython3.10.so.0.0
>> #15 0x000000d41f1206c0 in _PyEval_EvalFrameDefault ()
>>    from /usr/local/lib/libpython3.10.so.0.0
>> #16 0x000000d41f11d4e4 in _PyEval_Vector () from
>> /usr/local/lib/libpython3.10.so.0.0
>> #17 0x000000d41f185527 in run_mod () from
>> /usr/local/lib/libpython3.10.so.0.0
>> #18 0x000000d41f185e0c in PyRun_InteractiveOneObjectEx ()
>>    from /usr/local/lib/libpython3.10.so.0.0
>> #19 0x000000d41f1848be in _PyRun_InteractiveLoopObject ()
>>    from /usr/local/lib/libpython3.10.so.0.0
>> #20 0x000000d41f183dfb in _PyRun_AnyFileObject ()
>>    from /usr/local/lib/libpython3.10.so.0.0
>> #21 0x000000d41f187d2d in PyRun_AnyFileExFlags ()
>>    from /usr/local/lib/libpython3.10.so.0.0
>> #22 0x000000d41f1ac960 in Py_RunMain () from
>> /usr/local/lib/libpython3.10.so.0.0
>> #23 0x000000d41f1adc33 in pymain_main () from
>> /usr/local/lib/libpython3.10.so.0.0
>> #24 0x000000d41f1ae02c in Py_BytesMain () from
>> /usr/local/lib/libpython3.10.so.0.0
>> #25 0x000000d1cd9a4971 in _start ()
>>
>> On Sat, Dec 9, 2023 at 2:35 PM Matti Viljamaa <mav...@gm...>
>> wrote:
>>
>>> PYTHONPATH=obj egdb python3
>>> GNU gdb (GDB) 9.2
>>> Copyright (C) 2020 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later <
>>> http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.
>>> Type "show copying" and "show warranty" for details.
>>> This GDB was configured as "x86_64-unknown-openbsd7.4".
>>> Type "show configuration" for configuration details.
>>> For bug reporting instructions, please see:
>>> <http://www.gnu.org/software/gdb/bugs/>.
>>> Find the GDB manual and other documentation resources online at:
>>>     <http://www.gnu.org/software/gdb/documentation/>.
>>>
>>> For help, type "help".
>>> Type "apropos word" to search for commands related to "word"...
>>> Reading symbols from python3...
>>> (No debugging symbols found in python3)
>>> (gdb) import simple
>>> Undefined command: "import".  Try "help".
>>> (gdb) run
>>> Starting program: /usr/local/bin/python3
>>> Python 3.10.13 (main, Dec  5 2023, 18:39:12) [Clang 16.0.6 ] on openbsd7
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>> import simple
>>> warning: File "/usr/local/lib/libestdc++.so.20.0-gdb.py" auto-loading
>>> has been declined by your `auto-load safe-path' set to
>>> "/usr/local/share/gdb/auto-load".
>>> To enable execution of this file add
>>>         add-auto-load-safe-path /usr/local/lib/libestdc++.so.20.0-gdb.py
>>> line to your configuration file "/root/.gdbinit".
>>> To completely disable this security protection add
>>>         set auto-load safe-path /
>>> line to your configuration file "/root/.gdbinit".
>>> For more information about this security protection see the
>>> "Auto-loading safe path" section in the GDB manual.  E.g., run from the
>>> shell:
>>>         info "(gdb)Auto-loading safe path"
>>> sizeof(int) 4
>>> sizeof(long) 8
>>> sizeof(Py_hash_t) 8
>>> sizeof(Py_ssize_t) 8
>>> >>> def callback_bad( arg ):
>>> ...   raise ValueError( 'callback_bad error' )
>>> ...
>>> >>> simple.func_with_callback( callback_bad, 'fred' )
>>>
>>> Program received signal SIGABRT, Aborted.
>>> thrkill () at /tmp/-:2
>>> 2       /tmp/-: No such file or directory.
>>> (gdb) Quit
>>> (gdb)
>>>
>>> ---
>>>
>>> Now what?
>>>
>>> On Tue, Dec 5, 2023 at 1:46 PM Barry Scott <ba...@ba...>
>>> wrote:
>>>
>>>>
>>>> On 29/11/2023 13:02, Matti Viljamaa wrote:
>>>>
>>>> On a closer inspection it seems related to the line:
>>>>
>>>> simple.func_with_callback( callback_bad, 'fred' )
>>>>
>>>> because replacing that with a direct call:
>>>>
>>>> call_back('fred')
>>>>
>>>> works as expected:
>>>>
>>>> ...
>>>> TEST: call C++ with Python callback_good
>>>> callback_good with 'callback_args string'
>>>> PASS callback_good returned 'good result'
>>>> TEST: call C++ with Python callback_bad
>>>> callback_bad with 'fred'
>>>> PASS callback_bad: error callback_bad error
>>>> TEST: call C++ with Python callback_raise_simple_error
>>>> callback_bad with 'callback_args string'
>>>> Abort trap (core dumped)
>>>>
>>>> Is there some problem with raising exceptions with the
>>>> simple.func_with_callback?
>>>>
>>>> However, I also think there might be a problem with:
>>>>
>>>> TEST: call C++ with Python callback_good
>>>> callback_good with 'callback_args string'
>>>> PASS callback_good returned 'good result'
>>>>
>>>> because I think it shouldn't show 'callback_args string'
>>>>
>>>> On Wed, Nov 29, 2023 at 1:15 PM Matti Viljamaa <
>>>> mav...@gm...> wrote:
>>>>
>>>>> I am attempting to build pycxx-7.1.8 for OpenBSD 7.4-current.
>>>>>
>>>>> I am following the Unix installation guide at:
>>>>>
>>>>> https://cxx.sourceforge.net/
>>>>>
>>>>> The final line:
>>>>>
>>>>> make -f linux.mak clean test
>>>>>
>>>>> or
>>>>>
>>>>> gmake -f linux.mak clean test
>>>>>
>>>>> in OpenBSD
>>>>>
>>>>> fails to
>>>>>
>>>>> ...
>>>>> TEST: call C++ with Python callback_bad
>>>>> callback_bad with 'callback_args string'
>>>>> Abort trap (core dumped)
>>>>> gmake: *** [linux.mak:86: test] Error 134
>>>>>
>>>>> Upon inspecting test_simple.py I've noticed that it seems to be linked
>>>>> to raising ValueError, because commenting out line 31:
>>>>>
>>>>> raise ValueError( 'callback_bad error' )
>>>>>
>>>>> in test_simple.py makes test_simple.py progress to the next test. Now
>>>>> I see:
>>>>>
>>>>> ...
>>>>> TEST: call C++ with Python callback_bad
>>>>> callback_bad with 'callback_args string'
>>>>> FAILED callback_bad None
>>>>> TEST: call C++ with Python callback_raise_simple_error
>>>>> callback_bad with 'callback_args string'
>>>>> Abort trap (core dumped)
>>>>>
>>>>> However, since the Abort traps continue showing, I speculate that this
>>>>> is about something more. Possible reasons:
>>>>>
>>>>> * pycxx-7.1.8 is not compatible with Python 3.10 (or a particular
>>>>> subversion)
>>>>> * something is different in OpenBSD compared to Linux
>>>>>
>>>>> Any ideas?
>>>>>
>>>> This is how to run the failing test on its own to debug it:
>>>> :  11:44:26   worthy  ~/Projects/pycxx-trunk
>>>> : [1] barry $ PYTHONPATH=obj gdb python3.10
>>>> GNU gdb (Fedora Linux) 13.2-11.fc39
>>>> Copyright (C) 2023 Free Software Foundation, Inc.
>>>> License GPLv3+: GNU GPL version 3 or later
>>>> <http://gnu.org/licenses/gpl.html> <http://gnu.org/licenses/gpl.html>
>>>> This is free software: you are free to change and redistribute it.
>>>> There is NO WARRANTY, to the extent permitted by law.
>>>> Type "show copying" and "show warranty" for details.
>>>> This GDB was configured as "x86_64-redhat-linux-gnu".
>>>> Type "show configuration" for configuration details.
>>>> For bug reporting instructions, please see:
>>>> <https://www.gnu.org/software/gdb/bugs/>
>>>> <https://www.gnu.org/software/gdb/bugs/>.
>>>> Find the GDB manual and other documentation resources online at:
>>>>     <http://www.gnu.org/software/gdb/documentation/>
>>>> <http://www.gnu.org/software/gdb/documentation/>.
>>>>
>>>> For help, type "help".
>>>> Type "apropos word" to search for commands related to "word"...
>>>> Reading symbols from python3.10...
>>>> Reading symbols from
>>>> /home/barry/.cache/debuginfod_client/5ba318aef33a2277a4c3e2fef48addf050553288/debuginfo...
>>>>
>>>> (gdb) import
>>>> simple
>>>>
>>>> Undefined command: "import".  Try "help".
>>>> (gdb) run
>>>> Starting program: /usr/bin/python3.10
>>>> [Thread debugging using libthread_db
>>>> enabled]
>>>>
>>>> Using host libthread_db library "/lib64/libthread_db.so.1".
>>>> Python 3.10.13 (main, Aug 28 2023, 00:00:00) [GCC 13.2.1 20230728 (Red
>>>> Hat 13.2.1-1)] on
>>>> linux
>>>>
>>>> Type "help", "copyright", "credits" or "license" for more information.
>>>> >>> import
>>>> simple
>>>>
>>>> sizeof(int)
>>>> 4
>>>>
>>>> sizeof(long) 8
>>>> sizeof(Py_hash_t) 8
>>>> sizeof(Py_ssize_t) 8
>>>> >>> def callback_bad( arg ):
>>>> ...     raise ValueError( 'callback_bad error' )
>>>> ...
>>>> >>> simple.func_with_callback( callback_bad, 'fred' )
>>>> Traceback (most recent call last):
>>>>   File "<stdin>", line 1, in <module>
>>>>   File "<stdin>", line 2, in callback_bad
>>>> ValueError: callback_bad error
>>>> >>>
>>>>
>>>>
>>>> _______________________________________________
>>>> CXX-Users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/cxx-users
>>>>
>>>> _______________________________________________
>>>> CXX-Users mailing list
>>>> CXX...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/cxx-users
>>>>
>>> _______________________________________________
> CXX-Users mailing list
> CXX...@li...
> https://lists.sourceforge.net/lists/listinfo/cxx-users
>
>
> _______________________________________________
> CXX-Users mailing list
> CXX...@li...
> https://lists.sourceforge.net/lists/listinfo/cxx-users
>
>
>

Re: OpenBSD 7.4-current port and test produces an Abort trap at callback_bad with 'callback_args string'

[Barry S. <ba...@ba...>]

The problem is that eg++ has no working support for C++ exceptions.

The following simple C++ program fails to work:

#include <stdio.h>
#include <stdlib.h>
#include <iostream>

int main()
{
    std::cout << "Hello" <<std::endl;
    try
    {
        throw 20;
    }
    catch (int e)
    {
        std::cout << "catch of " << e << std::endl;
    }
    return 0;
}

On Fedora 39 I get this:

$ g++ -g -O0 -o a a.cpp
$ ./a
Hello
catch of 20


On OpenBSD 7.4 I get this:

$ eg++ -g -O0 -o a a.cpp
$ ./a
Hello
Abort trap (core dumped)

And with explicit option:

$ eg++ -g -O0 -o a -fexceptions a.cpp; ./a
Hello
Abort trap (core dumped)

Fix the compiler and PyCXX should work.

Barry




> On 13 Dec 2023, at 11:10, Barry Scott <ba...@ba...> wrote:
> 
> I now have an old laptop with OpenBSD 7.4 installed.
> Was way harder then it should be to install this OS...
> 
> I'll try and repro what you are seeing.
> 
> My working guess is that the compile options broke C++ exception handing.
> 
> Barry
> 
> 
> 
>> On 11 Dec 2023, at 09:06, Matti Viljamaa <mav...@gm...> wrote:
>> 
>> FYI, I am replicating the issue at po...@op... <mailto:po...@op...> mailing list to get different views:
>> 
>> https://marc.info/?l=openbsd-ports&m=170227787921446&w=2
>> 
>> On Sat, Dec 9, 2023 at 2:45 PM Matti Viljamaa <mav...@gm... <mailto:mav...@gm...>> wrote:
>>> Maybe the following is helpful:
>>> 
>>> (gdb) bt
>>> #0  thrkill () at /tmp/-:2
>>> #1  0xf7a555255abd010d in ?? ()
>>> #2  0x000000d3e7980c52 in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
>>> #3  0x000000d4b9c3ce70 in uw_init_context_1 (
>>>     context=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, context@entry=0x794f944a9560, 
>>>     outer_cfa=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, outer_cfa@entry=0x794f944a9910, 
>>>     outer_ra=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at /usr/obj/ports/gcc-11.2.0/gcc-11.2.0/libgcc/unwind-pe.h:88
>>> #4  0x000000d4b9c3c5d9 in _Unwind_RaiseException (exc=0xd3f70264c0)
>>>     at /usr/obj/ports/gcc-11.2.0/gcc-11.2.0/libgcc/unwind.inc:93
>>> #5  0x000000d4b9b25414 in __cxxabiv1::__cxa_throw (obj=<optimized out>, 
>>>     tinfo=0xd3f5aaa770 <typeinfo for Py::ValueError>, 
>>>     dest=0xd3f5a9a6e2 <Py::ValueError::~ValueError()>)
>>>     at /usr/obj/ports/gcc-11.2.0/gcc-11.2.0/libstdc++-v3/libsupc++/eh_throw.cc:90
>>> #6  0x000000d3f5a9a73d in Py::ValueError::throwFunc ()
>>>     at ./CXX/Python3/cxx_standard_exceptions.hxx:74
>>> #7  0x000000d3f5a98426 in Py::ifPyErrorThrowCxxException ()
>>>     at Src/Python3/cxx_exceptions.cxx:41
>>> #8  0x000000d3f5a80e1c in Py::Callable::apply (this=0x794f944a9a40, args=...)
>>>     at ./CXX/Python3/Objects.hxx:3241
>>> #9  0x000000d3f5a842c8 in simple_module::func_with_callback (this=0xd45b2ef460, 
>>>     args=...) at Demo/Python3/simple.cxx:351
>>> #10 0x000000d3f5a8b513 in Py::ExtensionModule<simple_module>::invoke_method_keyword (
>>>     this=0xd45b2ef460, method_def=0xd410e7b420, args=..., keywords=...)
>>>     at ./CXX/Python3/ExtensionModule.hxx:192
>>> #11 0x000000d3f5a9524d in Py::method_keyword_call_handler (Python Exception <class 'gdb.error'> There is no member named ob_item.: 
>>> _self_and_name_tuple=, Python Exception <class 'gdb.error'> There is no member named ob_item.: 
>>> 
>>>     _args=, _keywords=0x0) at Src/Python3/cxx_extensions.cxx:1695
>>> #12 0x000000d41f076d1c in cfunction_call () from /usr/local/lib/libpython3.10.so.0.0
>>> #13 0x000000d41f01cc75 in _PyObject_MakeTpCall ()
>>>    from /usr/local/lib/libpython3.10.so.0.0
>>> #14 0x000000d41f129e60 in call_function () from /usr/local/lib/libpython3.10.so.0.0
>>> #15 0x000000d41f1206c0 in _PyEval_EvalFrameDefault ()
>>>    from /usr/local/lib/libpython3.10.so.0.0
>>> #16 0x000000d41f11d4e4 in _PyEval_Vector () from /usr/local/lib/libpython3.10.so.0.0
>>> #17 0x000000d41f185527 in run_mod () from /usr/local/lib/libpython3.10.so.0.0
>>> #18 0x000000d41f185e0c in PyRun_InteractiveOneObjectEx ()
>>>    from /usr/local/lib/libpython3.10.so.0.0
>>> #19 0x000000d41f1848be in _PyRun_InteractiveLoopObject ()
>>>    from /usr/local/lib/libpython3.10.so.0.0
>>> #20 0x000000d41f183dfb in _PyRun_AnyFileObject ()
>>>    from /usr/local/lib/libpython3.10.so.0.0
>>> #21 0x000000d41f187d2d in PyRun_AnyFileExFlags ()
>>>    from /usr/local/lib/libpython3.10.so.0.0
>>> #22 0x000000d41f1ac960 in Py_RunMain () from /usr/local/lib/libpython3.10.so.0.0
>>> #23 0x000000d41f1adc33 in pymain_main () from /usr/local/lib/libpython3.10.so.0.0
>>> #24 0x000000d41f1ae02c in Py_BytesMain () from /usr/local/lib/libpython3.10.so.0.0
>>> #25 0x000000d1cd9a4971 in _start ()
>>> 
>>> On Sat, Dec 9, 2023 at 2:35 PM Matti Viljamaa <mav...@gm... <mailto:mav...@gm...>> wrote:
>>>> PYTHONPATH=obj egdb python3
>>>> GNU gdb (GDB) 9.2
>>>> Copyright (C) 2020 Free Software Foundation, Inc.
>>>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>>>> This is free software: you are free to change and redistribute it.
>>>> There is NO WARRANTY, to the extent permitted by law.
>>>> Type "show copying" and "show warranty" for details.
>>>> This GDB was configured as "x86_64-unknown-openbsd7.4".
>>>> Type "show configuration" for configuration details.
>>>> For bug reporting instructions, please see:
>>>> <http://www.gnu.org/software/gdb/bugs/>.
>>>> Find the GDB manual and other documentation resources online at:
>>>>     <http://www.gnu.org/software/gdb/documentation/>.
>>>> 
>>>> For help, type "help".
>>>> Type "apropos word" to search for commands related to "word"...
>>>> Reading symbols from python3...
>>>> (No debugging symbols found in python3)
>>>> (gdb) import simple
>>>> Undefined command: "import".  Try "help".
>>>> (gdb) run
>>>> Starting program: /usr/local/bin/python3 
>>>> Python 3.10.13 (main, Dec  5 2023, 18:39:12) [Clang 16.0.6 ] on openbsd7
>>>> Type "help", "copyright", "credits" or "license" for more information.
>>>> >>> import simple
>>>> warning: File "/usr/local/lib/libestdc++.so.20.0-gdb.py <http://so.20.0-gdb.py/>" auto-loading has been declined by your `auto-load safe-path' set to "/usr/local/share/gdb/auto-load".
>>>> To enable execution of this file add
>>>>         add-auto-load-safe-path /usr/local/lib/libestdc++.so.20.0-gdb.py <http://so.20.0-gdb.py/>
>>>> line to your configuration file "/root/.gdbinit".
>>>> To completely disable this security protection add
>>>>         set auto-load safe-path /
>>>> line to your configuration file "/root/.gdbinit".
>>>> For more information about this security protection see the
>>>> "Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
>>>>         info "(gdb)Auto-loading safe path"
>>>> sizeof(int) 4
>>>> sizeof(long) 8
>>>> sizeof(Py_hash_t) 8
>>>> sizeof(Py_ssize_t) 8
>>>> >>> def callback_bad( arg ):
>>>> ...   raise ValueError( 'callback_bad error' )
>>>> ... 
>>>> >>> simple.func_with_callback( callback_bad, 'fred' )
>>>> 
>>>> Program received signal SIGABRT, Aborted.
>>>> thrkill () at /tmp/-:2
>>>> 2       /tmp/-: No such file or directory.
>>>> (gdb) Quit  
>>>> (gdb)
>>>> 
>>>> ---
>>>> 
>>>> Now what?
>>>> 
>>>> 
>>>> On Tue, Dec 5, 2023 at 1:46 PM Barry Scott <ba...@ba... <mailto:ba...@ba...>> wrote:
>>>>> 
>>>>> 
>>>>> On 29/11/2023 13:02, Matti Viljamaa wrote:
>>>>>> On a closer inspection it seems related to the line:
>>>>>> 
>>>>>> simple.func_with_callback( callback_bad, 'fred' )
>>>>>> 
>>>>>> because replacing that with a direct call:
>>>>>> 
>>>>>> call_back('fred')
>>>>>> 
>>>>>> works as expected:
>>>>>> 
>>>>>> ...
>>>>>> TEST: call C++ with Python callback_good
>>>>>> callback_good with 'callback_args string'
>>>>>> PASS callback_good returned 'good result'
>>>>>> TEST: call C++ with Python callback_bad
>>>>>> callback_bad with 'fred'
>>>>>> PASS callback_bad: error callback_bad error
>>>>>> TEST: call C++ with Python callback_raise_simple_error
>>>>>> callback_bad with 'callback_args string'
>>>>>> Abort trap (core dumped)
>>>>>> 
>>>>>> Is there some problem with raising exceptions with the simple.func_with_callback?
>>>>>> 
>>>>>> However, I also think there might be a problem with:
>>>>>> 
>>>>>> TEST: call C++ with Python callback_good
>>>>>> callback_good with 'callback_args string'
>>>>>> PASS callback_good returned 'good result'
>>>>>> 
>>>>>> because I think it shouldn't show 'callback_args string'
>>>>>> 
>>>>>> On Wed, Nov 29, 2023 at 1:15 PM Matti Viljamaa <mav...@gm... <mailto:mav...@gm...>> wrote:
>>>>>>> I am attempting to build pycxx-7.1.8 for OpenBSD 7.4-current.
>>>>>>> 
>>>>>>> I am following the Unix installation guide at:
>>>>>>> 
>>>>>>> https://cxx.sourceforge.net/
>>>>>>> 
>>>>>>> The final line:
>>>>>>> 
>>>>>>> make -f linux.mak clean test
>>>>>>> 
>>>>>>> or
>>>>>>> 
>>>>>>> gmake -f linux.mak clean test
>>>>>>> 
>>>>>>> in OpenBSD
>>>>>>> 
>>>>>>> fails to
>>>>>>> 
>>>>>>> ...
>>>>>>> TEST: call C++ with Python callback_bad
>>>>>>> callback_bad with 'callback_args string'
>>>>>>> Abort trap (core dumped) 
>>>>>>> gmake: *** [linux.mak:86: test] Error 134
>>>>>>> 
>>>>>>> Upon inspecting test_simple.py I've noticed that it seems to be linked to raising ValueError, because commenting out line 31:
>>>>>>> 
>>>>>>> raise ValueError( 'callback_bad error' )
>>>>>>> 
>>>>>>> in test_simple.py makes test_simple.py progress to the next test. Now I see:
>>>>>>> 
>>>>>>> ...
>>>>>>> TEST: call C++ with Python callback_bad
>>>>>>> callback_bad with 'callback_args string'
>>>>>>> FAILED callback_bad None
>>>>>>> TEST: call C++ with Python callback_raise_simple_error
>>>>>>> callback_bad with 'callback_args string'
>>>>>>> Abort trap (core dumped)
>>>>>>> 
>>>>>>> However, since the Abort traps continue showing, I speculate that this is about something more. Possible reasons:
>>>>>>> 
>>>>>>> * pycxx-7.1.8 is not compatible with Python 3.10 (or a particular subversion)
>>>>>>> * something is different in OpenBSD compared to Linux
>>>>>>> 
>>>>>>> Any ideas?
>>>>> This is how to run the failing test on its own to debug it:
>>>>> :  11:44:26   worthy  ~/Projects/pycxx-trunk
>>>>> : [1] barry $ PYTHONPATH=obj gdb python3.10 
>>>>> GNU gdb (Fedora Linux) 13.2-11.fc39
>>>>> Copyright (C) 2023 Free Software Foundation, Inc.
>>>>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> <http://gnu.org/licenses/gpl.html>
>>>>> This is free software: you are free to change and redistribute it.
>>>>> There is NO WARRANTY, to the extent permitted by law.
>>>>> Type "show copying" and "show warranty" for details.
>>>>> This GDB was configured as "x86_64-redhat-linux-gnu".
>>>>> Type "show configuration" for configuration details.
>>>>> For bug reporting instructions, please see:
>>>>> <https://www.gnu.org/software/gdb/bugs/> <https://www.gnu.org/software/gdb/bugs/>.
>>>>> Find the GDB manual and other documentation resources online at:
>>>>>     <http://www.gnu.org/software/gdb/documentation/> <http://www.gnu.org/software/gdb/documentation/>.
>>>>> 
>>>>> For help, type "help".
>>>>> Type "apropos word" to search for commands related to "word"...
>>>>> Reading symbols from python3.10...
>>>>> Reading symbols from /home/barry/.cache/debuginfod_client/5ba318aef33a2277a4c3e2fef48addf050553288/debuginfo...                                                          
>>>>> (gdb) import simple                                                                                                                                                      
>>>>> Undefined command: "import".  Try "help".
>>>>> (gdb) run
>>>>> Starting program: /usr/bin/python3.10 
>>>>> [Thread debugging using libthread_db enabled]                                                                                                                            
>>>>> Using host libthread_db library "/lib64/libthread_db.so.1".
>>>>> Python 3.10.13 (main, Aug 28 2023, 00:00:00) [GCC 13.2.1 20230728 (Red Hat 13.2.1-1)] on linux                                                                           
>>>>> Type "help", "copyright", "credits" or "license" for more information.
>>>>> >>> import simple                                                                                                                                                        
>>>>> sizeof(int) 4                                                                                                                                                            
>>>>> sizeof(long) 8
>>>>> sizeof(Py_hash_t) 8
>>>>> sizeof(Py_ssize_t) 8
>>>>> >>> def callback_bad( arg ):
>>>>> ...     raise ValueError( 'callback_bad error' )
>>>>> ... 
>>>>> >>> simple.func_with_callback( callback_bad, 'fred' )
>>>>> Traceback (most recent call last):
>>>>>   File "<stdin>", line 1, in <module>
>>>>>   File "<stdin>", line 2, in callback_bad
>>>>> ValueError: callback_bad error
>>>>> >>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> CXX-Users mailing list
>>>>>> CXX...@li... <mailto:CXX...@li...>
>>>>>> https://lists.sourceforge.net/lists/listinfo/cxx-users
>>>>> _______________________________________________
>>>>> CXX-Users mailing list
>>>>> CXX...@li... <mailto:CXX...@li...>
>>>>> https://lists.sourceforge.net/lists/listinfo/cxx-users
>> _______________________________________________
>> CXX-Users mailing list
>> CXX...@li...
>> https://lists.sourceforge.net/lists/listinfo/cxx-users
> 
> _______________________________________________
> CXX-Users mailing list
> CXX...@li...
> https://lists.sourceforge.net/lists/listinfo/cxx-users

Re: OpenBSD 7.4-current port and test produces an Abort trap at callback_bad with 'callback_args string'

[Barry S. <ba...@ba...>]

I now have an old laptop with OpenBSD 7.4 installed.
Was way harder then it should be to install this OS...

I'll try and repro what you are seeing.

My working guess is that the compile options broke C++ exception handing.

Barry



> On 11 Dec 2023, at 09:06, Matti Viljamaa <mav...@gm...> wrote:
> 
> FYI, I am replicating the issue at po...@op... <mailto:po...@op...> mailing list to get different views:
> 
> https://marc.info/?l=openbsd-ports&m=170227787921446&w=2
> 
> On Sat, Dec 9, 2023 at 2:45 PM Matti Viljamaa <mav...@gm... <mailto:mav...@gm...>> wrote:
>> Maybe the following is helpful:
>> 
>> (gdb) bt
>> #0  thrkill () at /tmp/-:2
>> #1  0xf7a555255abd010d in ?? ()
>> #2  0x000000d3e7980c52 in _libc_abort () at /usr/src/lib/libc/stdlib/abort.c:51
>> #3  0x000000d4b9c3ce70 in uw_init_context_1 (
>>     context=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, context@entry=0x794f944a9560, 
>>     outer_cfa=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>, outer_cfa@entry=0x794f944a9910, 
>>     outer_ra=<error reading variable: dwarf2_find_location_expression: Corrupted DWARF expression.>) at /usr/obj/ports/gcc-11.2.0/gcc-11.2.0/libgcc/unwind-pe.h:88
>> #4  0x000000d4b9c3c5d9 in _Unwind_RaiseException (exc=0xd3f70264c0)
>>     at /usr/obj/ports/gcc-11.2.0/gcc-11.2.0/libgcc/unwind.inc:93
>> #5  0x000000d4b9b25414 in __cxxabiv1::__cxa_throw (obj=<optimized out>, 
>>     tinfo=0xd3f5aaa770 <typeinfo for Py::ValueError>, 
>>     dest=0xd3f5a9a6e2 <Py::ValueError::~ValueError()>)
>>     at /usr/obj/ports/gcc-11.2.0/gcc-11.2.0/libstdc++-v3/libsupc++/eh_throw.cc:90
>> #6  0x000000d3f5a9a73d in Py::ValueError::throwFunc ()
>>     at ./CXX/Python3/cxx_standard_exceptions.hxx:74
>> #7  0x000000d3f5a98426 in Py::ifPyErrorThrowCxxException ()
>>     at Src/Python3/cxx_exceptions.cxx:41
>> #8  0x000000d3f5a80e1c in Py::Callable::apply (this=0x794f944a9a40, args=...)
>>     at ./CXX/Python3/Objects.hxx:3241
>> #9  0x000000d3f5a842c8 in simple_module::func_with_callback (this=0xd45b2ef460, 
>>     args=...) at Demo/Python3/simple.cxx:351
>> #10 0x000000d3f5a8b513 in Py::ExtensionModule<simple_module>::invoke_method_keyword (
>>     this=0xd45b2ef460, method_def=0xd410e7b420, args=..., keywords=...)
>>     at ./CXX/Python3/ExtensionModule.hxx:192
>> #11 0x000000d3f5a9524d in Py::method_keyword_call_handler (Python Exception <class 'gdb.error'> There is no member named ob_item.: 
>> _self_and_name_tuple=, Python Exception <class 'gdb.error'> There is no member named ob_item.: 
>> 
>>     _args=, _keywords=0x0) at Src/Python3/cxx_extensions.cxx:1695
>> #12 0x000000d41f076d1c in cfunction_call () from /usr/local/lib/libpython3.10.so.0.0
>> #13 0x000000d41f01cc75 in _PyObject_MakeTpCall ()
>>    from /usr/local/lib/libpython3.10.so.0.0
>> #14 0x000000d41f129e60 in call_function () from /usr/local/lib/libpython3.10.so.0.0
>> #15 0x000000d41f1206c0 in _PyEval_EvalFrameDefault ()
>>    from /usr/local/lib/libpython3.10.so.0.0
>> #16 0x000000d41f11d4e4 in _PyEval_Vector () from /usr/local/lib/libpython3.10.so.0.0
>> #17 0x000000d41f185527 in run_mod () from /usr/local/lib/libpython3.10.so.0.0
>> #18 0x000000d41f185e0c in PyRun_InteractiveOneObjectEx ()
>>    from /usr/local/lib/libpython3.10.so.0.0
>> #19 0x000000d41f1848be in _PyRun_InteractiveLoopObject ()
>>    from /usr/local/lib/libpython3.10.so.0.0
>> #20 0x000000d41f183dfb in _PyRun_AnyFileObject ()
>>    from /usr/local/lib/libpython3.10.so.0.0
>> #21 0x000000d41f187d2d in PyRun_AnyFileExFlags ()
>>    from /usr/local/lib/libpython3.10.so.0.0
>> #22 0x000000d41f1ac960 in Py_RunMain () from /usr/local/lib/libpython3.10.so.0.0
>> #23 0x000000d41f1adc33 in pymain_main () from /usr/local/lib/libpython3.10.so.0.0
>> #24 0x000000d41f1ae02c in Py_BytesMain () from /usr/local/lib/libpython3.10.so.0.0
>> #25 0x000000d1cd9a4971 in _start ()
>> 
>> On Sat, Dec 9, 2023 at 2:35 PM Matti Viljamaa <mav...@gm... <mailto:mav...@gm...>> wrote:
>>> PYTHONPATH=obj egdb python3
>>> GNU gdb (GDB) 9.2
>>> Copyright (C) 2020 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.
>>> Type "show copying" and "show warranty" for details.
>>> This GDB was configured as "x86_64-unknown-openbsd7.4".
>>> Type "show configuration" for configuration details.
>>> For bug reporting instructions, please see:
>>> <http://www.gnu.org/software/gdb/bugs/>.
>>> Find the GDB manual and other documentation resources online at:
>>>     <http://www.gnu.org/software/gdb/documentation/>.
>>> 
>>> For help, type "help".
>>> Type "apropos word" to search for commands related to "word"...
>>> Reading symbols from python3...
>>> (No debugging symbols found in python3)
>>> (gdb) import simple
>>> Undefined command: "import".  Try "help".
>>> (gdb) run
>>> Starting program: /usr/local/bin/python3 
>>> Python 3.10.13 (main, Dec  5 2023, 18:39:12) [Clang 16.0.6 ] on openbsd7
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>> import simple
>>> warning: File "/usr/local/lib/libestdc++.so.20.0-gdb.py <http://so.20.0-gdb.py/>" auto-loading has been declined by your `auto-load safe-path' set to "/usr/local/share/gdb/auto-load".
>>> To enable execution of this file add
>>>         add-auto-load-safe-path /usr/local/lib/libestdc++.so.20.0-gdb.py <http://so.20.0-gdb.py/>
>>> line to your configuration file "/root/.gdbinit".
>>> To completely disable this security protection add
>>>         set auto-load safe-path /
>>> line to your configuration file "/root/.gdbinit".
>>> For more information about this security protection see the
>>> "Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
>>>         info "(gdb)Auto-loading safe path"
>>> sizeof(int) 4
>>> sizeof(long) 8
>>> sizeof(Py_hash_t) 8
>>> sizeof(Py_ssize_t) 8
>>> >>> def callback_bad( arg ):
>>> ...   raise ValueError( 'callback_bad error' )
>>> ... 
>>> >>> simple.func_with_callback( callback_bad, 'fred' )
>>> 
>>> Program received signal SIGABRT, Aborted.
>>> thrkill () at /tmp/-:2
>>> 2       /tmp/-: No such file or directory.
>>> (gdb) Quit  
>>> (gdb)
>>> 
>>> ---
>>> 
>>> Now what?
>>> 
>>> 
>>> On Tue, Dec 5, 2023 at 1:46 PM Barry Scott <ba...@ba... <mailto:ba...@ba...>> wrote:
>>>> 
>>>> 
>>>> On 29/11/2023 13:02, Matti Viljamaa wrote:
>>>>> On a closer inspection it seems related to the line:
>>>>> 
>>>>> simple.func_with_callback( callback_bad, 'fred' )
>>>>> 
>>>>> because replacing that with a direct call:
>>>>> 
>>>>> call_back('fred')
>>>>> 
>>>>> works as expected:
>>>>> 
>>>>> ...
>>>>> TEST: call C++ with Python callback_good
>>>>> callback_good with 'callback_args string'
>>>>> PASS callback_good returned 'good result'
>>>>> TEST: call C++ with Python callback_bad
>>>>> callback_bad with 'fred'
>>>>> PASS callback_bad: error callback_bad error
>>>>> TEST: call C++ with Python callback_raise_simple_error
>>>>> callback_bad with 'callback_args string'
>>>>> Abort trap (core dumped)
>>>>> 
>>>>> Is there some problem with raising exceptions with the simple.func_with_callback?
>>>>> 
>>>>> However, I also think there might be a problem with:
>>>>> 
>>>>> TEST: call C++ with Python callback_good
>>>>> callback_good with 'callback_args string'
>>>>> PASS callback_good returned 'good result'
>>>>> 
>>>>> because I think it shouldn't show 'callback_args string'
>>>>> 
>>>>> On Wed, Nov 29, 2023 at 1:15 PM Matti Viljamaa <mav...@gm... <mailto:mav...@gm...>> wrote:
>>>>>> I am attempting to build pycxx-7.1.8 for OpenBSD 7.4-current.
>>>>>> 
>>>>>> I am following the Unix installation guide at:
>>>>>> 
>>>>>> https://cxx.sourceforge.net/
>>>>>> 
>>>>>> The final line:
>>>>>> 
>>>>>> make -f linux.mak clean test
>>>>>> 
>>>>>> or
>>>>>> 
>>>>>> gmake -f linux.mak clean test
>>>>>> 
>>>>>> in OpenBSD
>>>>>> 
>>>>>> fails to
>>>>>> 
>>>>>> ...
>>>>>> TEST: call C++ with Python callback_bad
>>>>>> callback_bad with 'callback_args string'
>>>>>> Abort trap (core dumped) 
>>>>>> gmake: *** [linux.mak:86: test] Error 134
>>>>>> 
>>>>>> Upon inspecting test_simple.py I've noticed that it seems to be linked to raising ValueError, because commenting out line 31:
>>>>>> 
>>>>>> raise ValueError( 'callback_bad error' )
>>>>>> 
>>>>>> in test_simple.py makes test_simple.py progress to the next test. Now I see:
>>>>>> 
>>>>>> ...
>>>>>> TEST: call C++ with Python callback_bad
>>>>>> callback_bad with 'callback_args string'
>>>>>> FAILED callback_bad None
>>>>>> TEST: call C++ with Python callback_raise_simple_error
>>>>>> callback_bad with 'callback_args string'
>>>>>> Abort trap (core dumped)
>>>>>> 
>>>>>> However, since the Abort traps continue showing, I speculate that this is about something more. Possible reasons:
>>>>>> 
>>>>>> * pycxx-7.1.8 is not compatible with Python 3.10 (or a particular subversion)
>>>>>> * something is different in OpenBSD compared to Linux
>>>>>> 
>>>>>> Any ideas?
>>>> This is how to run the failing test on its own to debug it:
>>>> :  11:44:26   worthy  ~/Projects/pycxx-trunk
>>>> : [1] barry $ PYTHONPATH=obj gdb python3.10 
>>>> GNU gdb (Fedora Linux) 13.2-11.fc39
>>>> Copyright (C) 2023 Free Software Foundation, Inc.
>>>> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> <http://gnu.org/licenses/gpl.html>
>>>> This is free software: you are free to change and redistribute it.
>>>> There is NO WARRANTY, to the extent permitted by law.
>>>> Type "show copying" and "show warranty" for details.
>>>> This GDB was configured as "x86_64-redhat-linux-gnu".
>>>> Type "show configuration" for configuration details.
>>>> For bug reporting instructions, please see:
>>>> <https://www.gnu.org/software/gdb/bugs/> <https://www.gnu.org/software/gdb/bugs/>.
>>>> Find the GDB manual and other documentation resources online at:
>>>>     <http://www.gnu.org/software/gdb/documentation/> <http://www.gnu.org/software/gdb/documentation/>.
>>>> 
>>>> For help, type "help".
>>>> Type "apropos word" to search for commands related to "word"...
>>>> Reading symbols from python3.10...
>>>> Reading symbols from /home/barry/.cache/debuginfod_client/5ba318aef33a2277a4c3e2fef48addf050553288/debuginfo...                                                          
>>>> (gdb) import simple                                                                                                                                                      
>>>> Undefined command: "import".  Try "help".
>>>> (gdb) run
>>>> Starting program: /usr/bin/python3.10 
>>>> [Thread debugging using libthread_db enabled]                                                                                                                            
>>>> Using host libthread_db library "/lib64/libthread_db.so.1".
>>>> Python 3.10.13 (main, Aug 28 2023, 00:00:00) [GCC 13.2.1 20230728 (Red Hat 13.2.1-1)] on linux                                                                           
>>>> Type "help", "copyright", "credits" or "license" for more information.
>>>> >>> import simple                                                                                                                                                        
>>>> sizeof(int) 4                                                                                                                                                            
>>>> sizeof(long) 8
>>>> sizeof(Py_hash_t) 8
>>>> sizeof(Py_ssize_t) 8
>>>> >>> def callback_bad( arg ):
>>>> ...     raise ValueError( 'callback_bad error' )
>>>> ... 
>>>> >>> simple.func_with_callback( callback_bad, 'fred' )
>>>> Traceback (most recent call last):
>>>>   File "<stdin>", line 1, in <module>
>>>>   File "<stdin>", line 2, in callback_bad
>>>> ValueError: callback_bad error
>>>> >>> 
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> CXX-Users mailing list
>>>>> CXX...@li... <mailto:CXX...@li...>
>>>>> https://lists.sourceforge.net/lists/listinfo/cxx-users
>>>> _______________________________________________
>>>> CXX-Users mailing list
>>>> CXX...@li... <mailto:CXX...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/cxx-users
> _______________________________________________
> CXX-Users mailing list
> CXX...@li...
> https://lists.sourceforge.net/lists/listinfo/cxx-users

Re: OpenBSD 7.4-current port and test produces an Abort trap at callback_bad with 'callback_args string'

[Matti V. <mav...@gm...>]

FYI, I am replicating the issue at po...@op... mailing list to get
different views:

https://marc.info/?l=openbsd-ports&m=170227787921446&w=2

On Sat, Dec 9, 2023 at 2:45 PM Matti Viljamaa <mav...@gm...>
wrote:

> Maybe the following is helpful:
>
> (gdb) bt
> #0  thrkill () at /tmp/-:2
> #1  0xf7a555255abd010d in ?? ()
> #2  0x000000d3e7980c52 in _libc_abort () at
> /usr/src/lib/libc/stdlib/abort.c:51
> #3  0x000000d4b9c3ce70 in uw_init_context_1 (
>     context=<error reading variable: dwarf2_find_location_expression:
> Corrupted DWARF expression.>, context@entry=0x794f944a9560,
>     outer_cfa=<error reading variable: dwarf2_find_location_expression:
> Corrupted DWARF expression.>, outer_cfa@entry=0x794f944a9910,
>     outer_ra=<error reading variable: dwarf2_find_location_expression:
> Corrupted DWARF expression.>) at
> /usr/obj/ports/gcc-11.2.0/gcc-11.2.0/libgcc/unwind-pe.h:88
> #4  0x000000d4b9c3c5d9 in _Unwind_RaiseException (exc=0xd3f70264c0)
>     at /usr/obj/ports/gcc-11.2.0/gcc-11.2.0/libgcc/unwind.inc:93
> #5  0x000000d4b9b25414 in __cxxabiv1::__cxa_throw (obj=<optimized out>,
>     tinfo=0xd3f5aaa770 <typeinfo for Py::ValueError>,
>     dest=0xd3f5a9a6e2 <Py::ValueError::~ValueError()>)
>     at
> /usr/obj/ports/gcc-11.2.0/gcc-11.2.0/libstdc++-v3/libsupc++/eh_throw.cc:90
> #6  0x000000d3f5a9a73d in Py::ValueError::throwFunc ()
>     at ./CXX/Python3/cxx_standard_exceptions.hxx:74
> #7  0x000000d3f5a98426 in Py::ifPyErrorThrowCxxException ()
>     at Src/Python3/cxx_exceptions.cxx:41
> #8  0x000000d3f5a80e1c in Py::Callable::apply (this=0x794f944a9a40,
> args=...)
>     at ./CXX/Python3/Objects.hxx:3241
> #9  0x000000d3f5a842c8 in simple_module::func_with_callback
> (this=0xd45b2ef460,
>     args=...) at Demo/Python3/simple.cxx:351
> #10 0x000000d3f5a8b513 in
> Py::ExtensionModule<simple_module>::invoke_method_keyword (
>     this=0xd45b2ef460, method_def=0xd410e7b420, args=..., keywords=...)
>     at ./CXX/Python3/ExtensionModule.hxx:192
> #11 0x000000d3f5a9524d in Py::method_keyword_call_handler (Python
> Exception <class 'gdb.error'> There is no member named ob_item.:
> _self_and_name_tuple=, Python Exception <class 'gdb.error'> There is no
> member named ob_item.:
>
>     _args=, _keywords=0x0) at Src/Python3/cxx_extensions.cxx:1695
> #12 0x000000d41f076d1c in cfunction_call () from
> /usr/local/lib/libpython3.10.so.0.0
> #13 0x000000d41f01cc75 in _PyObject_MakeTpCall ()
>    from /usr/local/lib/libpython3.10.so.0.0
> #14 0x000000d41f129e60 in call_function () from
> /usr/local/lib/libpython3.10.so.0.0
> #15 0x000000d41f1206c0 in _PyEval_EvalFrameDefault ()
>    from /usr/local/lib/libpython3.10.so.0.0
> #16 0x000000d41f11d4e4 in _PyEval_Vector () from
> /usr/local/lib/libpython3.10.so.0.0
> #17 0x000000d41f185527 in run_mod () from
> /usr/local/lib/libpython3.10.so.0.0
> #18 0x000000d41f185e0c in PyRun_InteractiveOneObjectEx ()
>    from /usr/local/lib/libpython3.10.so.0.0
> #19 0x000000d41f1848be in _PyRun_InteractiveLoopObject ()
>    from /usr/local/lib/libpython3.10.so.0.0
> #20 0x000000d41f183dfb in _PyRun_AnyFileObject ()
>    from /usr/local/lib/libpython3.10.so.0.0
> #21 0x000000d41f187d2d in PyRun_AnyFileExFlags ()
>    from /usr/local/lib/libpython3.10.so.0.0
> #22 0x000000d41f1ac960 in Py_RunMain () from
> /usr/local/lib/libpython3.10.so.0.0
> #23 0x000000d41f1adc33 in pymain_main () from
> /usr/local/lib/libpython3.10.so.0.0
> #24 0x000000d41f1ae02c in Py_BytesMain () from
> /usr/local/lib/libpython3.10.so.0.0
> #25 0x000000d1cd9a4971 in _start ()
>
> On Sat, Dec 9, 2023 at 2:35 PM Matti Viljamaa <mav...@gm...>
> wrote:
>
>> PYTHONPATH=obj egdb python3
>> GNU gdb (GDB) 9.2
>> Copyright (C) 2020 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later <
>> http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>> Type "show copying" and "show warranty" for details.
>> This GDB was configured as "x86_64-unknown-openbsd7.4".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>.
>> Find the GDB manual and other documentation resources online at:
>>     <http://www.gnu.org/software/gdb/documentation/>.
>>
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from python3...
>> (No debugging symbols found in python3)
>> (gdb) import simple
>> Undefined command: "import".  Try "help".
>> (gdb) run
>> Starting program: /usr/local/bin/python3
>> Python 3.10.13 (main, Dec  5 2023, 18:39:12) [Clang 16.0.6 ] on openbsd7
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import simple
>> warning: File "/usr/local/lib/libestdc++.so.20.0-gdb.py" auto-loading
>> has been declined by your `auto-load safe-path' set to
>> "/usr/local/share/gdb/auto-load".
>> To enable execution of this file add
>>         add-auto-load-safe-path /usr/local/lib/libestdc++.so.20.0-gdb.py
>> line to your configuration file "/root/.gdbinit".
>> To completely disable this security protection add
>>         set auto-load safe-path /
>> line to your configuration file "/root/.gdbinit".
>> For more information about this security protection see the
>> "Auto-loading safe path" section in the GDB manual.  E.g., run from the
>> shell:
>>         info "(gdb)Auto-loading safe path"
>> sizeof(int) 4
>> sizeof(long) 8
>> sizeof(Py_hash_t) 8
>> sizeof(Py_ssize_t) 8
>> >>> def callback_bad( arg ):
>> ...   raise ValueError( 'callback_bad error' )
>> ...
>> >>> simple.func_with_callback( callback_bad, 'fred' )
>>
>> Program received signal SIGABRT, Aborted.
>> thrkill () at /tmp/-:2
>> 2       /tmp/-: No such file or directory.
>> (gdb) Quit
>> (gdb)
>>
>> ---
>>
>> Now what?
>>
>> On Tue, Dec 5, 2023 at 1:46 PM Barry Scott <ba...@ba...>
>> wrote:
>>
>>>
>>> On 29/11/2023 13:02, Matti Viljamaa wrote:
>>>
>>> On a closer inspection it seems related to the line:
>>>
>>> simple.func_with_callback( callback_bad, 'fred' )
>>>
>>> because replacing that with a direct call:
>>>
>>> call_back('fred')
>>>
>>> works as expected:
>>>
>>> ...
>>> TEST: call C++ with Python callback_good
>>> callback_good with 'callback_args string'
>>> PASS callback_good returned 'good result'
>>> TEST: call C++ with Python callback_bad
>>> callback_bad with 'fred'
>>> PASS callback_bad: error callback_bad error
>>> TEST: call C++ with Python callback_raise_simple_error
>>> callback_bad with 'callback_args string'
>>> Abort trap (core dumped)
>>>
>>> Is there some problem with raising exceptions with the
>>> simple.func_with_callback?
>>>
>>> However, I also think there might be a problem with:
>>>
>>> TEST: call C++ with Python callback_good
>>> callback_good with 'callback_args string'
>>> PASS callback_good returned 'good result'
>>>
>>> because I think it shouldn't show 'callback_args string'
>>>
>>> On Wed, Nov 29, 2023 at 1:15 PM Matti Viljamaa <mav...@gm...>
>>> wrote:
>>>
>>>> I am attempting to build pycxx-7.1.8 for OpenBSD 7.4-current.
>>>>
>>>> I am following the Unix installation guide at:
>>>>
>>>> https://cxx.sourceforge.net/
>>>>
>>>> The final line:
>>>>
>>>> make -f linux.mak clean test
>>>>
>>>> or
>>>>
>>>> gmake -f linux.mak clean test
>>>>
>>>> in OpenBSD
>>>>
>>>> fails to
>>>>
>>>> ...
>>>> TEST: call C++ with Python callback_bad
>>>> callback_bad with 'callback_args string'
>>>> Abort trap (core dumped)
>>>> gmake: *** [linux.mak:86: test] Error 134
>>>>
>>>> Upon inspecting test_simple.py I've noticed that it seems to be linked
>>>> to raising ValueError, because commenting out line 31:
>>>>
>>>> raise ValueError( 'callback_bad error' )
>>>>
>>>> in test_simple.py makes test_simple.py progress to the next test. Now I
>>>> see:
>>>>
>>>> ...
>>>> TEST: call C++ with Python callback_bad
>>>> callback_bad with 'callback_args string'
>>>> FAILED callback_bad None
>>>> TEST: call C++ with Python callback_raise_simple_error
>>>> callback_bad with 'callback_args string'
>>>> Abort trap (core dumped)
>>>>
>>>> However, since the Abort traps continue showing, I speculate that this
>>>> is about something more. Possible reasons:
>>>>
>>>> * pycxx-7.1.8 is not compatible with Python 3.10 (or a particular
>>>> subversion)
>>>> * something is different in OpenBSD compared to Linux
>>>>
>>>> Any ideas?
>>>>
>>> This is how to run the failing test on its own to debug it:
>>> :  11:44:26   worthy  ~/Projects/pycxx-trunk
>>> : [1] barry $ PYTHONPATH=obj gdb python3.10
>>> GNU gdb (Fedora Linux) 13.2-11.fc39
>>> Copyright (C) 2023 Free Software Foundation, Inc.
>>> License GPLv3+: GNU GPL version 3 or later
>>> <http://gnu.org/licenses/gpl.html> <http://gnu.org/licenses/gpl.html>
>>> This is free software: you are free to change and redistribute it.
>>> There is NO WARRANTY, to the extent permitted by law.
>>> Type "show copying" and "show warranty" for details.
>>> This GDB was configured as "x86_64-redhat-linux-gnu".
>>> Type "show configuration" for configuration details.
>>> For bug reporting instructions, please see:
>>> <https://www.gnu.org/software/gdb/bugs/>
>>> <https://www.gnu.org/software/gdb/bugs/>.
>>> Find the GDB manual and other documentation resources online at:
>>>     <http://www.gnu.org/software/gdb/documentation/>
>>> <http://www.gnu.org/software/gdb/documentation/>.
>>>
>>> For help, type "help".
>>> Type "apropos word" to search for commands related to "word"...
>>> Reading symbols from python3.10...
>>> Reading symbols from
>>> /home/barry/.cache/debuginfod_client/5ba318aef33a2277a4c3e2fef48addf050553288/debuginfo...
>>>
>>> (gdb) import
>>> simple
>>>
>>> Undefined command: "import".  Try "help".
>>> (gdb) run
>>> Starting program: /usr/bin/python3.10
>>> [Thread debugging using libthread_db
>>> enabled]
>>>
>>> Using host libthread_db library "/lib64/libthread_db.so.1".
>>> Python 3.10.13 (main, Aug 28 2023, 00:00:00) [GCC 13.2.1 20230728 (Red
>>> Hat 13.2.1-1)] on
>>> linux
>>>
>>> Type "help", "copyright", "credits" or "license" for more information.
>>> >>> import
>>> simple
>>>
>>> sizeof(int)
>>> 4
>>>
>>> sizeof(long) 8
>>> sizeof(Py_hash_t) 8
>>> sizeof(Py_ssize_t) 8
>>> >>> def callback_bad( arg ):
>>> ...     raise ValueError( 'callback_bad error' )
>>> ...
>>> >>> simple.func_with_callback( callback_bad, 'fred' )
>>> Traceback (most recent call last):
>>>   File "<stdin>", line 1, in <module>
>>>   File "<stdin>", line 2, in callback_bad
>>> ValueError: callback_bad error
>>> >>>
>>>
>>>
>>> _______________________________________________
>>> CXX-Users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/cxx-users
>>>
>>> _______________________________________________
>>> CXX-Users mailing list
>>> CXX...@li...
>>> https://lists.sourceforge.net/lists/listinfo/cxx-users
>>>
>>

Re: OpenBSD 7.4-current port and test produces an Abort trap at callback_bad with 'callback_args string'

[Matti V. <mav...@gm...>]

Maybe the following is helpful:

(gdb) bt
#0  thrkill () at /tmp/-:2
#1  0xf7a555255abd010d in ?? ()
#2  0x000000d3e7980c52 in _libc_abort () at
/usr/src/lib/libc/stdlib/abort.c:51
#3  0x000000d4b9c3ce70 in uw_init_context_1 (
    context=<error reading variable: dwarf2_find_location_expression:
Corrupted DWARF expression.>, context@entry=0x794f944a9560,
    outer_cfa=<error reading variable: dwarf2_find_location_expression:
Corrupted DWARF expression.>, outer_cfa@entry=0x794f944a9910,
    outer_ra=<error reading variable: dwarf2_find_location_expression:
Corrupted DWARF expression.>) at
/usr/obj/ports/gcc-11.2.0/gcc-11.2.0/libgcc/unwind-pe.h:88
#4  0x000000d4b9c3c5d9 in _Unwind_RaiseException (exc=0xd3f70264c0)
    at /usr/obj/ports/gcc-11.2.0/gcc-11.2.0/libgcc/unwind.inc:93
#5  0x000000d4b9b25414 in __cxxabiv1::__cxa_throw (obj=<optimized out>,
    tinfo=0xd3f5aaa770 <typeinfo for Py::ValueError>,
    dest=0xd3f5a9a6e2 <Py::ValueError::~ValueError()>)
    at
/usr/obj/ports/gcc-11.2.0/gcc-11.2.0/libstdc++-v3/libsupc++/eh_throw.cc:90
#6  0x000000d3f5a9a73d in Py::ValueError::throwFunc ()
    at ./CXX/Python3/cxx_standard_exceptions.hxx:74
#7  0x000000d3f5a98426 in Py::ifPyErrorThrowCxxException ()
    at Src/Python3/cxx_exceptions.cxx:41
#8  0x000000d3f5a80e1c in Py::Callable::apply (this=0x794f944a9a40,
args=...)
    at ./CXX/Python3/Objects.hxx:3241
#9  0x000000d3f5a842c8 in simple_module::func_with_callback
(this=0xd45b2ef460,
    args=...) at Demo/Python3/simple.cxx:351
#10 0x000000d3f5a8b513 in
Py::ExtensionModule<simple_module>::invoke_method_keyword (
    this=0xd45b2ef460, method_def=0xd410e7b420, args=..., keywords=...)
    at ./CXX/Python3/ExtensionModule.hxx:192
#11 0x000000d3f5a9524d in Py::method_keyword_call_handler (Python Exception
<class 'gdb.error'> There is no member named ob_item.:
_self_and_name_tuple=, Python Exception <class 'gdb.error'> There is no
member named ob_item.:

    _args=, _keywords=0x0) at Src/Python3/cxx_extensions.cxx:1695
#12 0x000000d41f076d1c in cfunction_call () from
/usr/local/lib/libpython3.10.so.0.0
#13 0x000000d41f01cc75 in _PyObject_MakeTpCall ()
   from /usr/local/lib/libpython3.10.so.0.0
#14 0x000000d41f129e60 in call_function () from
/usr/local/lib/libpython3.10.so.0.0
#15 0x000000d41f1206c0 in _PyEval_EvalFrameDefault ()
   from /usr/local/lib/libpython3.10.so.0.0
#16 0x000000d41f11d4e4 in _PyEval_Vector () from
/usr/local/lib/libpython3.10.so.0.0
#17 0x000000d41f185527 in run_mod () from
/usr/local/lib/libpython3.10.so.0.0
#18 0x000000d41f185e0c in PyRun_InteractiveOneObjectEx ()
   from /usr/local/lib/libpython3.10.so.0.0
#19 0x000000d41f1848be in _PyRun_InteractiveLoopObject ()
   from /usr/local/lib/libpython3.10.so.0.0
#20 0x000000d41f183dfb in _PyRun_AnyFileObject ()
   from /usr/local/lib/libpython3.10.so.0.0
#21 0x000000d41f187d2d in PyRun_AnyFileExFlags ()
   from /usr/local/lib/libpython3.10.so.0.0
#22 0x000000d41f1ac960 in Py_RunMain () from
/usr/local/lib/libpython3.10.so.0.0
#23 0x000000d41f1adc33 in pymain_main () from
/usr/local/lib/libpython3.10.so.0.0
#24 0x000000d41f1ae02c in Py_BytesMain () from
/usr/local/lib/libpython3.10.so.0.0
#25 0x000000d1cd9a4971 in _start ()

On Sat, Dec 9, 2023 at 2:35 PM Matti Viljamaa <mav...@gm...>
wrote:

> PYTHONPATH=obj egdb python3
> GNU gdb (GDB) 9.2
> Copyright (C) 2020 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <
> http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-unknown-openbsd7.4".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
>     <http://www.gnu.org/software/gdb/documentation/>.
>
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from python3...
> (No debugging symbols found in python3)
> (gdb) import simple
> Undefined command: "import".  Try "help".
> (gdb) run
> Starting program: /usr/local/bin/python3
> Python 3.10.13 (main, Dec  5 2023, 18:39:12) [Clang 16.0.6 ] on openbsd7
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import simple
> warning: File "/usr/local/lib/libestdc++.so.20.0-gdb.py" auto-loading has
> been declined by your `auto-load safe-path' set to
> "/usr/local/share/gdb/auto-load".
> To enable execution of this file add
>         add-auto-load-safe-path /usr/local/lib/libestdc++.so.20.0-gdb.py
> line to your configuration file "/root/.gdbinit".
> To completely disable this security protection add
>         set auto-load safe-path /
> line to your configuration file "/root/.gdbinit".
> For more information about this security protection see the
> "Auto-loading safe path" section in the GDB manual.  E.g., run from the
> shell:
>         info "(gdb)Auto-loading safe path"
> sizeof(int) 4
> sizeof(long) 8
> sizeof(Py_hash_t) 8
> sizeof(Py_ssize_t) 8
> >>> def callback_bad( arg ):
> ...   raise ValueError( 'callback_bad error' )
> ...
> >>> simple.func_with_callback( callback_bad, 'fred' )
>
> Program received signal SIGABRT, Aborted.
> thrkill () at /tmp/-:2
> 2       /tmp/-: No such file or directory.
> (gdb) Quit
> (gdb)
>
> ---
>
> Now what?
>
> On Tue, Dec 5, 2023 at 1:46 PM Barry Scott <ba...@ba...> wrote:
>
>>
>> On 29/11/2023 13:02, Matti Viljamaa wrote:
>>
>> On a closer inspection it seems related to the line:
>>
>> simple.func_with_callback( callback_bad, 'fred' )
>>
>> because replacing that with a direct call:
>>
>> call_back('fred')
>>
>> works as expected:
>>
>> ...
>> TEST: call C++ with Python callback_good
>> callback_good with 'callback_args string'
>> PASS callback_good returned 'good result'
>> TEST: call C++ with Python callback_bad
>> callback_bad with 'fred'
>> PASS callback_bad: error callback_bad error
>> TEST: call C++ with Python callback_raise_simple_error
>> callback_bad with 'callback_args string'
>> Abort trap (core dumped)
>>
>> Is there some problem with raising exceptions with the
>> simple.func_with_callback?
>>
>> However, I also think there might be a problem with:
>>
>> TEST: call C++ with Python callback_good
>> callback_good with 'callback_args string'
>> PASS callback_good returned 'good result'
>>
>> because I think it shouldn't show 'callback_args string'
>>
>> On Wed, Nov 29, 2023 at 1:15 PM Matti Viljamaa <mav...@gm...>
>> wrote:
>>
>>> I am attempting to build pycxx-7.1.8 for OpenBSD 7.4-current.
>>>
>>> I am following the Unix installation guide at:
>>>
>>> https://cxx.sourceforge.net/
>>>
>>> The final line:
>>>
>>> make -f linux.mak clean test
>>>
>>> or
>>>
>>> gmake -f linux.mak clean test
>>>
>>> in OpenBSD
>>>
>>> fails to
>>>
>>> ...
>>> TEST: call C++ with Python callback_bad
>>> callback_bad with 'callback_args string'
>>> Abort trap (core dumped)
>>> gmake: *** [linux.mak:86: test] Error 134
>>>
>>> Upon inspecting test_simple.py I've noticed that it seems to be linked
>>> to raising ValueError, because commenting out line 31:
>>>
>>> raise ValueError( 'callback_bad error' )
>>>
>>> in test_simple.py makes test_simple.py progress to the next test. Now I
>>> see:
>>>
>>> ...
>>> TEST: call C++ with Python callback_bad
>>> callback_bad with 'callback_args string'
>>> FAILED callback_bad None
>>> TEST: call C++ with Python callback_raise_simple_error
>>> callback_bad with 'callback_args string'
>>> Abort trap (core dumped)
>>>
>>> However, since the Abort traps continue showing, I speculate that this
>>> is about something more. Possible reasons:
>>>
>>> * pycxx-7.1.8 is not compatible with Python 3.10 (or a particular
>>> subversion)
>>> * something is different in OpenBSD compared to Linux
>>>
>>> Any ideas?
>>>
>> This is how to run the failing test on its own to debug it:
>> :  11:44:26   worthy  ~/Projects/pycxx-trunk
>> : [1] barry $ PYTHONPATH=obj gdb python3.10
>> GNU gdb (Fedora Linux) 13.2-11.fc39
>> Copyright (C) 2023 Free Software Foundation, Inc.
>> License GPLv3+: GNU GPL version 3 or later
>> <http://gnu.org/licenses/gpl.html> <http://gnu.org/licenses/gpl.html>
>> This is free software: you are free to change and redistribute it.
>> There is NO WARRANTY, to the extent permitted by law.
>> Type "show copying" and "show warranty" for details.
>> This GDB was configured as "x86_64-redhat-linux-gnu".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> <https://www.gnu.org/software/gdb/bugs/>
>> <https://www.gnu.org/software/gdb/bugs/>.
>> Find the GDB manual and other documentation resources online at:
>>     <http://www.gnu.org/software/gdb/documentation/>
>> <http://www.gnu.org/software/gdb/documentation/>.
>>
>> For help, type "help".
>> Type "apropos word" to search for commands related to "word"...
>> Reading symbols from python3.10...
>> Reading symbols from
>> /home/barry/.cache/debuginfod_client/5ba318aef33a2277a4c3e2fef48addf050553288/debuginfo...
>>
>> (gdb) import
>> simple
>>
>> Undefined command: "import".  Try "help".
>> (gdb) run
>> Starting program: /usr/bin/python3.10
>> [Thread debugging using libthread_db
>> enabled]
>>
>> Using host libthread_db library "/lib64/libthread_db.so.1".
>> Python 3.10.13 (main, Aug 28 2023, 00:00:00) [GCC 13.2.1 20230728 (Red
>> Hat 13.2.1-1)] on
>> linux
>>
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> import
>> simple
>>
>> sizeof(int)
>> 4
>>
>> sizeof(long) 8
>> sizeof(Py_hash_t) 8
>> sizeof(Py_ssize_t) 8
>> >>> def callback_bad( arg ):
>> ...     raise ValueError( 'callback_bad error' )
>> ...
>> >>> simple.func_with_callback( callback_bad, 'fred' )
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>>   File "<stdin>", line 2, in callback_bad
>> ValueError: callback_bad error
>> >>>
>>
>>
>> _______________________________________________
>> CXX-Users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/cxx-users
>>
>> _______________________________________________
>> CXX-Users mailing list
>> CXX...@li...
>> https://lists.sourceforge.net/lists/listinfo/cxx-users
>>
>

Re: OpenBSD 7.4-current port and test produces an Abort trap at callback_bad with 'callback_args string'

[Matti V. <mav...@gm...>]

PYTHONPATH=obj egdb python3
GNU gdb (GDB) 9.2
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html
>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-unknown-openbsd7.4".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from python3...
(No debugging symbols found in python3)
(gdb) import simple
Undefined command: "import".  Try "help".
(gdb) run
Starting program: /usr/local/bin/python3
Python 3.10.13 (main, Dec  5 2023, 18:39:12) [Clang 16.0.6 ] on openbsd7
Type "help", "copyright", "credits" or "license" for more information.
>>> import simple
warning: File "/usr/local/lib/libestdc++.so.20.0-gdb.py" auto-loading has
been declined by your `auto-load safe-path' set to
"/usr/local/share/gdb/auto-load".
To enable execution of this file add
        add-auto-load-safe-path /usr/local/lib/libestdc++.so.20.0-gdb.py
line to your configuration file "/root/.gdbinit".
To completely disable this security protection add
        set auto-load safe-path /
line to your configuration file "/root/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the
shell:
        info "(gdb)Auto-loading safe path"
sizeof(int) 4
sizeof(long) 8
sizeof(Py_hash_t) 8
sizeof(Py_ssize_t) 8
>>> def callback_bad( arg ):
...   raise ValueError( 'callback_bad error' )
...
>>> simple.func_with_callback( callback_bad, 'fred' )

Program received signal SIGABRT, Aborted.
thrkill () at /tmp/-:2
2       /tmp/-: No such file or directory.
(gdb) Quit
(gdb)

---

Now what?

On Tue, Dec 5, 2023 at 1:46 PM Barry Scott <ba...@ba...> wrote:

>
> On 29/11/2023 13:02, Matti Viljamaa wrote:
>
> On a closer inspection it seems related to the line:
>
> simple.func_with_callback( callback_bad, 'fred' )
>
> because replacing that with a direct call:
>
> call_back('fred')
>
> works as expected:
>
> ...
> TEST: call C++ with Python callback_good
> callback_good with 'callback_args string'
> PASS callback_good returned 'good result'
> TEST: call C++ with Python callback_bad
> callback_bad with 'fred'
> PASS callback_bad: error callback_bad error
> TEST: call C++ with Python callback_raise_simple_error
> callback_bad with 'callback_args string'
> Abort trap (core dumped)
>
> Is there some problem with raising exceptions with the
> simple.func_with_callback?
>
> However, I also think there might be a problem with:
>
> TEST: call C++ with Python callback_good
> callback_good with 'callback_args string'
> PASS callback_good returned 'good result'
>
> because I think it shouldn't show 'callback_args string'
>
> On Wed, Nov 29, 2023 at 1:15 PM Matti Viljamaa <mav...@gm...>
> wrote:
>
>> I am attempting to build pycxx-7.1.8 for OpenBSD 7.4-current.
>>
>> I am following the Unix installation guide at:
>>
>> https://cxx.sourceforge.net/
>>
>> The final line:
>>
>> make -f linux.mak clean test
>>
>> or
>>
>> gmake -f linux.mak clean test
>>
>> in OpenBSD
>>
>> fails to
>>
>> ...
>> TEST: call C++ with Python callback_bad
>> callback_bad with 'callback_args string'
>> Abort trap (core dumped)
>> gmake: *** [linux.mak:86: test] Error 134
>>
>> Upon inspecting test_simple.py I've noticed that it seems to be linked to
>> raising ValueError, because commenting out line 31:
>>
>> raise ValueError( 'callback_bad error' )
>>
>> in test_simple.py makes test_simple.py progress to the next test. Now I
>> see:
>>
>> ...
>> TEST: call C++ with Python callback_bad
>> callback_bad with 'callback_args string'
>> FAILED callback_bad None
>> TEST: call C++ with Python callback_raise_simple_error
>> callback_bad with 'callback_args string'
>> Abort trap (core dumped)
>>
>> However, since the Abort traps continue showing, I speculate that this is
>> about something more. Possible reasons:
>>
>> * pycxx-7.1.8 is not compatible with Python 3.10 (or a particular
>> subversion)
>> * something is different in OpenBSD compared to Linux
>>
>> Any ideas?
>>
> This is how to run the failing test on its own to debug it:
> :  11:44:26   worthy  ~/Projects/pycxx-trunk
> : [1] barry $ PYTHONPATH=obj gdb python3.10
> GNU gdb (Fedora Linux) 13.2-11.fc39
> Copyright (C) 2023 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> Type "show copying" and "show warranty" for details.
> This GDB was configured as "x86_64-redhat-linux-gnu".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <https://www.gnu.org/software/gdb/bugs/>
> <https://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
>     <http://www.gnu.org/software/gdb/documentation/>
> <http://www.gnu.org/software/gdb/documentation/>.
>
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from python3.10...
> Reading symbols from
> /home/barry/.cache/debuginfod_client/5ba318aef33a2277a4c3e2fef48addf050553288/debuginfo...
>
> (gdb) import
> simple
>
> Undefined command: "import".  Try "help".
> (gdb) run
> Starting program: /usr/bin/python3.10
> [Thread debugging using libthread_db
> enabled]
>
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Python 3.10.13 (main, Aug 28 2023, 00:00:00) [GCC 13.2.1 20230728 (Red Hat
> 13.2.1-1)] on
> linux
>
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import
> simple
>
> sizeof(int)
> 4
>
> sizeof(long) 8
> sizeof(Py_hash_t) 8
> sizeof(Py_ssize_t) 8
> >>> def callback_bad( arg ):
> ...     raise ValueError( 'callback_bad error' )
> ...
> >>> simple.func_with_callback( callback_bad, 'fred' )
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
>   File "<stdin>", line 2, in callback_bad
> ValueError: callback_bad error
> >>>
>
>
> _______________________________________________
> CXX-Users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/cxx-users
>
> _______________________________________________
> CXX-Users mailing list
> CXX...@li...
> https://lists.sourceforge.net/lists/listinfo/cxx-users
>

Re: Make file in Unix tar.gz seems to have wrong paths

[Matti V. <mav...@gm...>]

No, just dismiss the info about paths. This is just about make vs gmake
again on OpenBSD.

So install gmake via pkg_add gmake and then g++ via pkg_add g++. Then
create a symbolic link:

 ln -s /usr/local/bin/eg++ /usr/local/bin/g++

Then use gmake in place of make.

On Sat, Dec 9, 2023 at 2:07 PM Matti Viljamaa <mav...@gm...>
wrote:

> I think I previously did some modification into the .mak for this, but I
> reinstalled OpenBSD, and I noticed that the problem is there still and
> forgot the fix.
>
> The problem is that by following the Unix installation guide the final
> line actually produces:
>
> gmake -f linux.mak clean test
> rm -f obj/simple.*
> rm -f obj/simple.obj
> rm -f obj/cxxsupport.obj
> rm -f obj/cxx_extensions.obj
> rm -f obj/cxx_exceptions.obj
> rm -f obj/cxxextensions.obj
> rm -f obj/IndirectPythonInterface.obj
> rm -f obj/example.*
> rm -f obj/example.obj
> rm -f obj/range.obj
> rm -f obj/rangetest.obj
> rm -f obj/pycxx_iter.*
> rm -f obj/pycxx_iter.obj
> Compile: Demo/Python3/simple.cxx into obj/simple.obj
> g++ -c -g -Wall -fPIC -fexceptions -frtti -I. -ISrc
> -I/usr/local/include/python3.10 -DNDEBUG  -oobj/simple.obj
>  Demo/Python3/simple.cxx
> gmake: g++: No such file or directory
> gmake: *** [linux.mak:15: obj/simple.obj] Error 127
>
> In other words, the path that the makefile seems wrong.
>
> Is there an official fix for this?
>

Make file in Unix tar.gz seems to have wrong paths

[Matti V. <mav...@gm...>]

I think I previously did some modification into the .mak for this, but I
reinstalled OpenBSD, and I noticed that the problem is there still and
forgot the fix.

The problem is that by following the Unix installation guide the final line
actually produces:

gmake -f linux.mak clean test
rm -f obj/simple.*
rm -f obj/simple.obj
rm -f obj/cxxsupport.obj
rm -f obj/cxx_extensions.obj
rm -f obj/cxx_exceptions.obj
rm -f obj/cxxextensions.obj
rm -f obj/IndirectPythonInterface.obj
rm -f obj/example.*
rm -f obj/example.obj
rm -f obj/range.obj
rm -f obj/rangetest.obj
rm -f obj/pycxx_iter.*
rm -f obj/pycxx_iter.obj
Compile: Demo/Python3/simple.cxx into obj/simple.obj
g++ -c -g -Wall -fPIC -fexceptions -frtti -I. -ISrc
-I/usr/local/include/python3.10 -DNDEBUG  -oobj/simple.obj
 Demo/Python3/simple.cxx
gmake: g++: No such file or directory
gmake: *** [linux.mak:15: obj/simple.obj] Error 127

In other words, the path that the makefile seems wrong.

Is there an official fix for this?

Re: OpenBSD 7.4-current port and test produces an Abort trap at callback_bad with 'callback_args string'

[Barry S. <ba...@ba...>]

On 29/11/2023 13:02, Matti Viljamaa wrote:
> On a closer inspection it seems related to the line:
>
> simple.func_with_callback( callback_bad, 'fred' )
>
> because replacing that with a direct call:
>
> call_back('fred')
>
> works as expected:
>
> ...
> TEST: call C++ with Python callback_good
> callback_good with 'callback_args string'
> PASS callback_good returned 'good result'
> TEST: call C++ with Python callback_bad
> callback_bad with 'fred'
> PASS callback_bad: error callback_bad error
> TEST: call C++ with Python callback_raise_simple_error
> callback_bad with 'callback_args string'
> Abort trap (core dumped)
>
> Is there some problem with raising exceptions with the 
> simple.func_with_callback?
>
> However, I also think there might be a problem with:
>
> TEST: call C++ with Python callback_good
> callback_good with 'callback_args string'
> PASS callback_good returned 'good result'
>
> because I think it shouldn't show 'callback_args string'
>
> On Wed, Nov 29, 2023 at 1:15 PM Matti Viljamaa 
> <mav...@gm...> wrote:
>
>     I am attempting to build pycxx-7.1.8 for OpenBSD 7.4-current.
>
>     I am following the Unix installation guide at:
>
>     https://cxx.sourceforge.net/
>
>     The final line:
>
>     make -f linux.mak clean test
>
>     or
>
>     gmake -f linux.mak clean test
>
>     in OpenBSD
>
>     fails to
>
>     ...
>     TEST: call C++ with Python callback_bad
>     callback_bad with 'callback_args string'
>     Abort trap (core dumped)
>     gmake: *** [linux.mak:86: test] Error 134
>
>     Upon inspecting test_simple.py I've noticed that it seems to be
>     linked to raising ValueError, because commenting out line 31:
>
>     raise ValueError( 'callback_bad error' )
>
>     in test_simple.py makes test_simple.py progress to the next test.
>     Now I see:
>
>     ...
>     TEST: call C++ with Python callback_bad
>     callback_bad with 'callback_args string'
>     FAILED callback_bad None
>     TEST: call C++ with Python callback_raise_simple_error
>     callback_bad with 'callback_args string'
>     Abort trap (core dumped)
>
>     However, since the Abort traps continue showing, I speculate that
>     this is about something more. Possible reasons:
>
>     * pycxx-7.1.8 is not compatible with Python 3.10 (or a particular
>     subversion)
>     * something is different in OpenBSD compared to Linux
>
>     Any ideas?
>
This is how to run the failing test on its own to debug it:
:  11:44:26   worthy  ~/Projects/pycxx-trunk
: [1] barry $ PYTHONPATH=obj gdb python3.10
GNU gdb (Fedora Linux) 13.2-11.fc39
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from python3.10...
Reading symbols from 
/home/barry/.cache/debuginfod_client/5ba318aef33a2277a4c3e2fef48addf050553288/debuginfo... 

(gdb) import simple
Undefined command: "import".  Try "help".
(gdb) run
Starting program: /usr/bin/python3.10
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Python 3.10.13 (main, Aug 28 2023, 00:00:00) [GCC 13.2.1 20230728 (Red 
Hat 13.2.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
 >>> import simple
sizeof(int) 4
sizeof(long) 8
sizeof(Py_hash_t) 8
sizeof(Py_ssize_t) 8
 >>> def callback_bad( arg ):
...     raise ValueError( 'callback_bad error' )
...
 >>> simple.func_with_callback( callback_bad, 'fred' )
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
   File "<stdin>", line 2, in callback_bad
ValueError: callback_bad error
 >>>

>
> _______________________________________________
> CXX-Users mailing list
> CXX...@li...
> https://lists.sourceforge.net/lists/listinfo/cxx-users

Re: OpenBSD 7.4-current port and test produces an Abort trap at callback_bad with 'callback_args string'

[Barry S. <ba...@ba...>]

On 29/11/2023 11:15, Matti Viljamaa wrote:
> I am attempting to build pycxx-7.1.8 for OpenBSD 7.4-current.
>
> I am following the Unix installation guide at:
>
> https://cxx.sourceforge.net/
>
> The final line:
>
> make -f linux.mak clean test
>
> or
>
> gmake -f linux.mak clean test
>
> in OpenBSD
>
> fails to
>
> ...
> TEST: call C++ with Python callback_bad
> callback_bad with 'callback_args string'
> Abort trap (core dumped)
> gmake: *** [linux.mak:86: test] Error 134
>
> Upon inspecting test_simple.py I've noticed that it seems to be linked 
> to raising ValueError, because commenting out line 31:
>
> raise ValueError( 'callback_bad error' )
>
> in test_simple.py makes test_simple.py progress to the next test. Now 
> I see:
>
> ...
> TEST: call C++ with Python callback_bad
> callback_bad with 'callback_args string'
> FAILED callback_bad None
> TEST: call C++ with Python callback_raise_simple_error
> callback_bad with 'callback_args string'
> Abort trap (core dumped)
>
> However, since the Abort traps continue showing, I speculate that this 
> is about something more. Possible reasons:
>
> * pycxx-7.1.8 is not compatible with Python 3.10 (or a particular 
> subversion)

I fully support python 3.10 and I assum you want to build pysvn and I 
also fully support on python 3.10.

> * something is different in OpenBSD compared to Linux

It will be this. When I'm testing I use the build-limited-api.sh and  
build-unlimited-api.sh scripts.
You might want to use them, after you add openbsd changes (gmake vs make).
If you let me know what uname prints for OpenBSD I'll commit the change 
for the next release.

When I run ./build-unlimited-api.sh python3.10
I get this output for the callback test:

...

TEST: raise user defined exception
PASS SimpleError Testing simple error
TEST: call C++ with Python callback_good
callback_good with 'callback_args string'
PASS callback_good returned 'good result'
TEST: call C++ with Python callback_bad
callback_bad with 'callback_args string'
PASS callback_bad: error callback_bad error
...

I suggest that you run the failing test under gdb so that you can find 
out why the abort is happening.

Unhandled exception in the C++ maybe?

I tried to build a VM to run this in for openbsd 7.4 but I cannot 
install the CD install75.iso version.
I am an old OpenBSD user so the install is familiar.

linux virt-manager can setup a VM but I see a ATA error part way through 
the install process.
The VM reboots after the kernle syncs the disks but has not installed 
the OS.

As there is not a arm64 ISO I cannot try with macOS parallels.

Do you have access to a linux VM to compare against?

I use Fedora 39 as by main development environment.

I assume that PyCXX was working on OpenBSD 7.3?

Barry

Re: OpenBSD 7.4-current port and test produces an Abort trap at callback_bad with 'callback_args string'

[Matti V. <mav...@gm...>]

On a closer inspection it seems related to the line:

simple.func_with_callback( callback_bad, 'fred' )

because replacing that with a direct call:

call_back('fred')

works as expected:

...
TEST: call C++ with Python callback_good
callback_good with 'callback_args string'
PASS callback_good returned 'good result'
TEST: call C++ with Python callback_bad
callback_bad with 'fred'
PASS callback_bad: error callback_bad error
TEST: call C++ with Python callback_raise_simple_error
callback_bad with 'callback_args string'
Abort trap (core dumped)

Is there some problem with raising exceptions with the
simple.func_with_callback?

However, I also think there might be a problem with:

TEST: call C++ with Python callback_good
callback_good with 'callback_args string'
PASS callback_good returned 'good result'

because I think it shouldn't show 'callback_args string'

On Wed, Nov 29, 2023 at 1:15 PM Matti Viljamaa <mav...@gm...>
wrote:

> I am attempting to build pycxx-7.1.8 for OpenBSD 7.4-current.
>
> I am following the Unix installation guide at:
>
> https://cxx.sourceforge.net/
>
> The final line:
>
> make -f linux.mak clean test
>
> or
>
> gmake -f linux.mak clean test
>
> in OpenBSD
>
> fails to
>
> ...
> TEST: call C++ with Python callback_bad
> callback_bad with 'callback_args string'
> Abort trap (core dumped)
> gmake: *** [linux.mak:86: test] Error 134
>
> Upon inspecting test_simple.py I've noticed that it seems to be linked to
> raising ValueError, because commenting out line 31:
>
> raise ValueError( 'callback_bad error' )
>
> in test_simple.py makes test_simple.py progress to the next test. Now I
> see:
>
> ...
> TEST: call C++ with Python callback_bad
> callback_bad with 'callback_args string'
> FAILED callback_bad None
> TEST: call C++ with Python callback_raise_simple_error
> callback_bad with 'callback_args string'
> Abort trap (core dumped)
>
> However, since the Abort traps continue showing, I speculate that this is
> about something more. Possible reasons:
>
> * pycxx-7.1.8 is not compatible with Python 3.10 (or a particular
> subversion)
> * something is different in OpenBSD compared to Linux
>
> Any ideas?
>

OpenBSD 7.4-current port and test produces an Abort trap at callback_bad with 'callback_args string'

[Matti V. <mav...@gm...>]

I am attempting to build pycxx-7.1.8 for OpenBSD 7.4-current.

I am following the Unix installation guide at:

https://cxx.sourceforge.net/

The final line:

make -f linux.mak clean test

or

gmake -f linux.mak clean test

in OpenBSD

fails to

...
TEST: call C++ with Python callback_bad
callback_bad with 'callback_args string'
Abort trap (core dumped)
gmake: *** [linux.mak:86: test] Error 134

Upon inspecting test_simple.py I've noticed that it seems to be linked to
raising ValueError, because commenting out line 31:

raise ValueError( 'callback_bad error' )

in test_simple.py makes test_simple.py progress to the next test. Now I see:

...
TEST: call C++ with Python callback_bad
callback_bad with 'callback_args string'
FAILED callback_bad None
TEST: call C++ with Python callback_raise_simple_error
callback_bad with 'callback_args string'
Abort trap (core dumped)

However, since the Abort traps continue showing, I speculate that this is
about something more. Possible reasons:

* pycxx-7.1.8 is not compatible with Python 3.10 (or a particular
subversion)
* something is different in OpenBSD compared to Linux

Any ideas?

PyCXX V7.1.7 Released

[Barry S. <ba...@ba...>]

Version: 7.1.7 (13-Feb-2022)

Add support for building against python 3.11 alpha 4.

This is Version 7.1.6 with README updates.

PyCXX V7.1.5 released

[Barry S. <ba...@ba...>]

Version: 7.1.5 (21-feb-2021)

Replace use of deprecated PyUnicode APIs with the supported version.

The class Py::String functions that used deprecated PyUnicode APIs
that have no replacements are not available for python 3.9 and later:

    const Py_UNICODE *unicode_data() const;
    unicodestring as_unicodestring() const;

Replace build-all.sh and build-all.cmd with build-all.py that can handle the 
build matrix.
Add limited API builds for all possible combinations.

Note: Python 3.9 has a bug that prevents use of the limited API until this bug 
is fix and shipped:
https://bugs.python.org/issue43155 for details.
The workaround is to set Py_LIMITED_API to use python 3.8.

Re: export with PyCXX

[Anton M. <am...@ab...>]

Hello, Barry. 
  Thanks for reply.
 
I am not going to argue about the PyCXX libs and RTTI, to build PyCXX with VS I have to include in my project anyway reference to "c:\Python37\libs" folder, and the prebuild "python37.lib", so far I didn't had issues.  
  Let me get introduced a little more with PyCXX so to be able to understand your answer...  
  Best Regards  
  
  
  
  
  
  
  
  
  
  






 >-------- Оригинално писмо --------

 >От: Barry Scott ba...@ba...

 >Относно: Re: export with PyCXX

 >До: PyCXX and improvement  

 >Изпратено на: 10.11.2019 14:30



 
 
  

   
   

    
     
     On 9 Nov 2019, at 20:18, Anton Milev <
      am...@ab... > wrote:
     
    

     
      
       Hello, Bary.
       
       

       
       
       Thanks! I will risk to ask for some improvements even if I do not understand completely PyCXX. I will happy if you answer any of it

        
       
       
       
1. Can you add a VS2017/19
 Step-by-Step demo? I actually started using PyCXX with VS2017 so if you like I can help with this.
       
      
     
    
    
    

    
    
    Sorry I'm not a Visual Studio GUI user. I use the VS C++ from the command line.
    
    
    

    
    
     
      
       
       2. With VS 2017 I had to search for and add all .cxx files from "C:\PyCXX\Src"
 (cxx_extensions.cxx,. ...) to the VS project. This is not convenient.
       
      
     
    
    
    

    
    
     
      
       
       Is it possible to create with the build scripts a single


        lib  file and I to include in my project only the libs path (from Linker > General->Additional Library Directories) ?
       
      
     
    
    
    

    
    
    It is not practical to provide as a lib.
    
    
    This is because you have to compile the code with the C++ options that you have chosen for the rest of your project.
    
    
    For example some projects want RTTI and others do not.
    
    
    You might use Python limiter API or not.
    
    
    

    
    
     
      
       
       It is similar to how Python libs are included in VS, you only include   and set the link path.
       
      
     
    
    
    

    
    
     
      
       
       3. I am confused with the demos, simple.cxx is not simple at all and is hard for me to start using it.
       
      
     
    
    
    

    Simple is relative...
   
   
   

   
   
   What I mean by simple is that its shows the simplest way to create a module, class and function, etc.
   
   
   

    
     
      
      Please advice me in the following case -

      
      
      

      
      
      I have a C++ class A. It is quite complicated and contains a lot of functions and code. I want to export this class A to Python.

      
     
    
    
     
      
      

      
      
      Is this the right approach:
      
      
      

      
      
      
 class     OldClass  :   public   Py::  PythonExtension    OldClass  
>  
       
       

       
      
     
    
    
    

    Look at Demo/Python3/simple.cxx and follow the pattern of the new_style_class.
   
   
   You are using the older style of classes that is not recommended for new code.
   
   
   

    
     
      
       
       
 {  
       
 public  :  
       
 


 OldClass()  
       
 


 {  
       
 


 }  
        
         
 
        

        
       
 


   virtual   ~OldClass()  
       
 


 {  
       
 


 }  
        
         
 
        

        
       
 


   static     void   init_type(  void  )  
       
 


 {  
       
 






 behaviors().name(  "simple.OldClass"  );  
       
 






 behaviors().doc(  "documentation for OldClass class"  );  
       
 






 behaviors().supportGetattr();  
        
         
 
        

        
       
 






 add_noargs_method(  "func1"  ,&amp;  OldClass  ::func1);  
       
 






 add_varargs_method(  "func2"  ,&amp;  OldClass  ::func2);  
       
 






 add_keyword_method(  "func3"  ,&amp;  OldClass  ::func3);  
        
         
 
        

        
       
 






 behaviors().readyType();  
       
 


 }  
        
         
 
        

        
       
 


   // override functions from PythonExtension    
       
 


   virtual   Py::  Object   getattr(  const     char   *  name  )  
       
 


 {  
       
 






   return   getattr_methods(  name  );  
       
 


 }  
        
         
 
        

        
       
 


 Py::  Object   func1(  void  )  
       
 


 {  
       
 






 std::cout        "func1 Called."        std::endl;  
       
 






   return   Py::None();  
       
 


 }  
        
         
 
        

        
       
 


 Py::  Object   func2(  const   Py::  Tuple   &amp;  args  )  
       
 


 {  
       
 






 std::cout        "func2 Called with "          args  .length()        " normal arguments."        std::endl;  
       
 






   return   Py::None();  
       
 


 }  
        
         
 
 
 
        

        
        
         
 

 
        

        
       
  private:   
       
  CppClass m_cpp ;   
       
 };  
       
       
       4. I have in my class A many 
        overload operators  and I want to use them in Python too.
       
       
       

       
       
       For example:
       
       
       

       
       
        >>> import simple 
       
       
        >>> a = simple.OldClass() 
       
       
        
         >>> a.func1() 
        
        
        func1 Called.
        
        
         >>> a.func2(5) 
        
        
        func2 Called with 1 normal arguments.
        
       
       
        >>> b = a 
       
       
       

       
       
       So far Ok but how to do with PyCXX support the following operators:
       
       
       

       
       
       

       
       
        
         >>> b += a 
        
        
        Traceback (most recent call last):
        
        
        
 File " ", line 1, in  
        
        
        TypeError: unsupported operand type(s) for +=: 'simple.OldClass' and 'simple.OldClass'
        
       
      
     
    
    
    

    
    
    You have to implement the number_inplace_add. See Demo/Python3/simple.cxx

    
    
    (I just added support for inplace add today. Please get check out the source:
    
    
    

    
    
    svn co

     https://svn.code.sf.net/p/cxx/code/trunk/CXX 
    
    
    

    
    
     
      
       
       

       
       
        
         >>> c = simple.OldClass() 
        
        
         >>> a = b +  c
        
        
        Traceback (most recent call last):
        
        
        
 File " ", line 1, in  
        
        
        TypeError: unsupported operand type(s) for +: 'simple.OldClass' and 'simple.OldClass'
        
       
      
     
    
    
    

    
    
    You have to implement the number_add method. See Demo/Python3/simple.cxx

    


    
    
     
      
       
       

       
       
       

       
       
       My purpose is to expose and use in Python my C++ class as a new type. I need support for different constructors, like:
       
       
       

       
       
        >>> a = simple..OldClass("a") 
       
       
        >>> a = simple..OldClass(5) 
       
       
       

       
      
     
    
    
    No problem look at simple.cxx and the c'tor for new_style_class.
    
    
    

    
    
     
     
 
 new_style_class( Py::PythonClassInstance *self, Py::Tuple &amp;args, Py::Dict &amp;kwds )
     
     
     

     
     
     You can handle args and kwds as you need to implement your API.
     
     
     

     
    
    
     
      
       
       

       
       
       I hope my questions are not too confusing

        
       
      
     
    
   

   
   
   Barry
   
   
   

   
 
  

Re: export with PyCXX

[Barry S. <ba...@ba...>]

> On 9 Nov 2019, at 20:18, Anton Milev <am...@ab...> wrote:
> 
> Hello, Bary.
> 
> Thanks! I will risk to ask for some improvements even if I do not understand completely PyCXX. I will happy if you answer any of it 
> 
> 1. Can you add a VS2017/19  Step-by-Step demo? I actually started using PyCXX with VS2017 so if you like I can help with this.

Sorry I'm not a Visual Studio GUI user. I use the VS C++ from the command line.

> 2. With VS 2017 I had to search for and add all .cxx files from "C:\PyCXX\Src"  (cxx_extensions.cxx,. ...) to the VS project. This is not convenient.

> Is it possible to create with the build scripts a single  lib file and I to include in my project only the libs path (from Linker > General->Additional Library Directories) ?

It is not practical to provide as a lib.
This is because you have to compile the code with the C++ options that you have chosen for the rest of your project.
For example some projects want RTTI and others do not.
You might use Python limiter API or not.

> It is similar to how Python libs are included in VS, you only include <Python.h> and set the link path.

> 3. I am confused with the demos, simple.cxx is not simple at all and is hard for me to start using it.

Simple is relative...

What I mean by simple is that its shows the simplest way to create a module, class and function, etc.

> Please advice me in the following case - 
> 
> I have a C++ class A. It is quite complicated and contains a lot of functions and code. I want to export this class A to Python. 
> 
> Is this the right approach:
> 
> class OldClass: public Py::PythonExtension< OldClass >
> 
> 

Look at Demo/Python3/simple.cxx and follow the pattern of the new_style_class.
You are using the older style of classes that is not recommended for new code.

> {
> 
> public:
> 
>     OldClass()
> 
>     {
> 
>     }
> 
>  
>     virtual ~OldClass()
> 
>     {
> 
>     }
> 
>  
>     static void init_type(void)
> 
>     {
> 
>         behaviors().name("simple.OldClass");
> 
>         behaviors().doc("documentation for OldClass class");
> 
>         behaviors().supportGetattr();
> 
>  
>         add_noargs_method("func1",&OldClass::func1);
> 
>         add_varargs_method("func2",&OldClass::func2);
> 
>         add_keyword_method("func3",&OldClass::func3);
> 
>  
>         behaviors().readyType();
> 
>     }
> 
>  
>     // override functions from PythonExtension
> 
>     virtual Py::Object getattr(const char *name)
> 
>     {
> 
>         return getattr_methods(name);
> 
>     }
> 
>  
>     Py::Object func1(void)
> 
>     {
> 
>         std::cout << "func1 Called." << std::endl;
> 
>         return Py::None();
> 
>     }
> 
>  
>     Py::Object func2(const Py::Tuple &args)
> 
>     {
> 
>         std::cout << "func2 Called with " << args.length() << " normal arguments." << std::endl;
> 
>         return Py::None();
> 
>     }
> 
>      
>     
> private:
> 
> CppClass m_cpp ;
> 
> };
> 
> 4. I have in my class A many overload operators and I want to use them in Python too.
> 
> For example:
> 
> >>> import simple
> >>> a = simple.OldClass()
> >>> a.func1()
> func1 Called.
> >>> a.func2(5)
> func2 Called with 1 normal arguments.
> >>> b = a
> 
> So far Ok but how to do with PyCXX support the following operators:
> 
> 
> >>> b += a
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: unsupported operand type(s) for +=: 'simple.OldClass' and 'simple.OldClass'

You have to implement the number_inplace_add. See Demo/Python3/simple.cxx 
(I just added support for inplace add today. Please get check out the source:

svn co https://svn.code.sf.net/p/cxx/code/trunk/CXX <https://svn.code.sf.net/p/cxx/code/trunk/CXX>

> 
> >>> c = simple.OldClass()
> >>> a = b + c
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: unsupported operand type(s) for +: 'simple.OldClass' and 'simple.OldClass'

You have to implement the number_add method. See Demo/Python3/simple.cxx 
 
> 
> 
> My purpose is to expose and use in Python my C++ class as a new type. I need support for different constructors, like:
> 
> >>> a = simple..OldClass("a")
> >>> a = simple..OldClass(5)
> 
No problem look at simple.cxx and the c'tor for new_style_class.

    new_style_class( Py::PythonClassInstance *self, Py::Tuple &args, Py::Dict &kwds )

You can handle args and kwds as you need to implement your API.

> 
> I hope my questions are not too confusing 

Barry

Re: export with PyCXX

[Anton M. <am...@ab...>]

Hello, Bary. 
  Thanks! I will risk to ask for some improvements even if I do not understand completely PyCXX. I will happy if you answer any of it
   
1. Can you add a VS2017/19
 Step-by-Step demo? I actually started using PyCXX with VS2017 so if you like I can help with this.  2. With VS 2017 I had to search for and add all .cxx files from "C:\PyCXX\Src"
 (cxx_extensions.cxx,. ...) to the VS project. This is not convenient. Is it possible to create with the build scripts a single

 lib  file and I to include in my project only the libs path (from Linker > General->Additional Library Directories) ? It is similar to how Python libs are included in VS, you only include   and set the link path.  3. I am confused with the demos, simple.cxx is not simple at all and is hard for me to start using it.  Please advice me in the following case -
  
  I have a C++ class A. It is quite complicated and contains a lot of functions and code. I want to export this class A to Python.
  
  Is this the right approach:  
   <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;
color:blue;mso-ansi-language:EN-US;mso-fareast-language:EN-US">class    <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;
color:#2B91AF;mso-ansi-language:EN-US;mso-fareast-language:EN-US">OldClass  :  <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;
color:blue;mso-ansi-language:EN-US;mso-fareast-language:EN-US">public   Py:: <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;
color:#2B91AF;mso-ansi-language:EN-US;mso-fareast-language:EN-US">PythonExtension   <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;
color:#2B91AF;mso-ansi-language:EN-US;mso-fareast-language:EN-US">OldClass   >    {  

 <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;
color:blue;mso-ansi-language:EN-US;mso-fareast-language:EN-US">public  :    

  


 OldClass()    

  


 {    

  


 }    

  
  

  


  <span style="font-size:9.5pt;
font-family:Consolas;mso-bidi-font-family:Consolas;color:blue;mso-ansi-language:
EN-US;mso-fareast-language:EN-US">virtual   ~OldClass()    

  


 {    

  


 }    

  
  

  


  <span style="font-size:9.5pt;
font-family:Consolas;mso-bidi-font-family:Consolas;color:blue;mso-ansi-language:
EN-US;mso-fareast-language:EN-US">static    <span style="font-size:9.5pt;
font-family:Consolas;mso-bidi-font-family:Consolas;color:blue;mso-ansi-language:
EN-US;mso-fareast-language:EN-US">void   init_type( <span style="font-size:
9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;color:blue;mso-ansi-language:
EN-US;mso-fareast-language:EN-US">void  )    

  


 {    

  






 behaviors().name( <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;
color:#A31515;mso-ansi-language:EN-US;mso-fareast-language:EN-US">"simple.OldClass"  );    

  






 behaviors().doc( <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;
color:#A31515;mso-ansi-language:EN-US;mso-fareast-language:EN-US">"documentation
for OldClass class"  );    

  






 behaviors().supportGetattr();    

  
  

  






 add_noargs_method( <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;
color:#A31515;mso-ansi-language:EN-US;mso-fareast-language:EN-US">"func1"  ,&amp; <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;
color:#2B91AF;mso-ansi-language:EN-US;mso-fareast-language:EN-US">OldClass  ::func1);    

  






 add_varargs_method( <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;
color:#A31515;mso-ansi-language:EN-US;mso-fareast-language:EN-US">"func2"  ,&amp; <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;
color:#2B91AF;mso-ansi-language:EN-US;mso-fareast-language:EN-US">OldClass  ::func2);    

  






 add_keyword_method( <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;
color:#A31515;mso-ansi-language:EN-US;mso-fareast-language:EN-US">"func3"  ,&amp; <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;
color:#2B91AF;mso-ansi-language:EN-US;mso-fareast-language:EN-US">OldClass  ::func3);    

  
  

  






 behaviors().readyType();    

  


 }    

  
  

  


  <span style="font-size:9.5pt;
font-family:Consolas;mso-bidi-font-family:Consolas;color:green;mso-ansi-language:
EN-US;mso-fareast-language:EN-US">// override functions from PythonExtension      

  


  <span style="font-size:9.5pt;
font-family:Consolas;mso-bidi-font-family:Consolas;color:blue;mso-ansi-language:
EN-US;mso-fareast-language:EN-US">virtual   Py:: <span style="font-size:9.5pt;
font-family:Consolas;mso-bidi-font-family:Consolas;color:#2B91AF;mso-ansi-language:
EN-US;mso-fareast-language:EN-US">Object   getattr( <span style="font-size:9.5pt;
font-family:Consolas;mso-bidi-font-family:Consolas;color:blue;mso-ansi-language:
EN-US;mso-fareast-language:EN-US">const    <span style="font-size:9.5pt;
font-family:Consolas;mso-bidi-font-family:Consolas;color:blue;mso-ansi-language:
EN-US;mso-fareast-language:EN-US">char   * <span style="font-size:9.5pt;
font-family:Consolas;mso-bidi-font-family:Consolas;color:gray;mso-ansi-language:
EN-US;mso-fareast-language:EN-US">name  )    

  


 {    

  






  <span style="font-size:9.5pt;
font-family:Consolas;mso-bidi-font-family:Consolas;color:blue;mso-ansi-language:
EN-US;mso-fareast-language:EN-US">return   getattr_methods( <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;
color:gray;mso-ansi-language:EN-US;mso-fareast-language:EN-US">name  );    

  


 }    

  
  

  


 Py:: <span style="font-size:9.5pt;
font-family:Consolas;mso-bidi-font-family:Consolas;color:#2B91AF;mso-ansi-language:
EN-US;mso-fareast-language:EN-US">Object   func1( <span style="font-size:9.5pt;
font-family:Consolas;mso-bidi-font-family:Consolas;color:blue;mso-ansi-language:
EN-US;mso-fareast-language:EN-US">void  )    

  


 {    

  






 std::cout  <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;
color:teal;mso-ansi-language:EN-US;mso-fareast-language:EN-US">    <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;
color:#A31515;mso-ansi-language:EN-US;mso-fareast-language:EN-US">"func1
Called."    <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:
Consolas;color:teal;mso-ansi-language:EN-US;mso-fareast-language:EN-US">   std::endl;    

  






  <span style="font-size:9.5pt;
font-family:Consolas;mso-bidi-font-family:Consolas;color:blue;mso-ansi-language:
EN-US;mso-fareast-language:EN-US">return   Py::None();    

  


 }    

  
  

  


 Py:: <span style="font-size:9.5pt;
font-family:Consolas;mso-bidi-font-family:Consolas;color:#2B91AF;mso-ansi-language:
EN-US;mso-fareast-language:EN-US">Object   func2( <span style="font-size:9.5pt;
font-family:Consolas;mso-bidi-font-family:Consolas;color:blue;mso-ansi-language:
EN-US;mso-fareast-language:EN-US">const   Py:: <span style="font-size:9.5pt;
font-family:Consolas;mso-bidi-font-family:Consolas;color:#2B91AF;mso-ansi-language:
EN-US;mso-fareast-language:EN-US">Tuple   &amp; <span style="font-size:9.5pt;
font-family:Consolas;mso-bidi-font-family:Consolas;color:gray;mso-ansi-language:
EN-US;mso-fareast-language:EN-US">args  )    

  


 {    

  






 std::cout  <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;
color:teal;mso-ansi-language:EN-US;mso-fareast-language:EN-US">    <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;
color:#A31515;mso-ansi-language:EN-US;mso-fareast-language:EN-US">"func2
Called with "    <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:
Consolas;color:teal;mso-ansi-language:EN-US;mso-fareast-language:EN-US">    <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;
color:gray;mso-ansi-language:EN-US;mso-fareast-language:EN-US">args  .length()  <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;
color:teal;mso-ansi-language:EN-US;mso-fareast-language:EN-US">    <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:Consolas;
color:#A31515;mso-ansi-language:EN-US;mso-fareast-language:EN-US">" normal
arguments."    <span style="font-size:9.5pt;font-family:Consolas;mso-bidi-font-family:
Consolas;color:teal;mso-ansi-language:EN-US;mso-fareast-language:EN-US">   std::endl;    

  






  <span style="font-size:9.5pt;
font-family:Consolas;mso-bidi-font-family:Consolas;color:blue;mso-ansi-language:
EN-US;mso-fareast-language:EN-US">return   Py::None();    

  


 }    

  
 
 
  

  
 

     private:   

   CppClass m_cpp ;     };      4. I have in my class A many  overload operators  and I want to use them in Python too.  
  For example:  
   >>> import simple    >>> a = simple.OldClass()     >>> a.func1()   func1 Called.   >>> a.func2(5)   func2 Called with 1 normal arguments.    >>> b = a   
  So far Ok but how to do with PyCXX support the following operators:  
  
    >>> b += a   Traceback (most recent call last):  
 File " ", line 1, in    TypeError: unsupported operand type(s) for +=: 'simple.OldClass' and 'simple.OldClass'   
    >>> c = simple.OldClass()    >>> a = b +  c  Traceback (most recent call last):  
 File " ", line 1, in    TypeError: unsupported operand type(s) for +: 'simple.OldClass' and 'simple.OldClass'   
  
  My purpose is to expose and use in Python my C++ class as a new type. I need support for different constructors, like:  
   >>> a = simple..OldClass("a")    >>> a = simple..OldClass(5)   
  
  I hope my questions are not too confusing
   
  
  






 >-------- Оригинално писмо --------

 >От: Barry ba...@ba...

 >Относно: Re: export with PyCXX

 >До: Anton Milev  

 >Изпратено на: 09.11.2019 09:36



 
 
   
   Please join and ask on the mailing list so that there is public record of
   
   
   the conversation.
   
   
   

   
   
    https://sourceforge.net/projects/cxx/lists/cxx-users 
   
   
   

   
   
   Barry
   
   
   

   
   
   

    
    On 9 Nov 2019, at 00:28, Anton Milev   wrote:
    

    

    
   
   
    
     Hello, Barry.
     
     I am trying to use PyCXX with VS2017 but I am having a number of difficulties.

     
     
     You probably receive a lot of emails, but if you are interested I can send you my initial feedback?
     
     
     I am not very advanced with Python, so probably I am making something dumb:)
      
    
   
 
 

PyCXX V7.1.3 released

[Barry S. <ba...@ba...>]

Version: 7.1.3 (8-Jul-2019)

Fix for https://sourceforge.net/p/cxx/bugs/43/
memory leak caused by wrong ref count on python3 Py::String objects.

Remove support for supportPrint() etc as the tp_print field is
being removed from python either in 3.8 or 3.9.

PyCXX V7.1.2 released

[Barry S. <ba...@ba...>]

Version: 7.1.2 (4-Mar-2019)

Fix problem with compiling for Python 2 and
the _Py_PackageContext symbol.

Merge Fedora's setup.py changes.

PyCXX V7.1.1 Released

[Barry S. <ba...@ba...>]

Version: 7.1.1 (18-Feb-2019)

Add exception errorType() and errorValue() function to access
the type and value of an exception.

Barry

PyCXX V7.1.0 Released

[Barry S. <ba...@ba...>]

Version: 7.1.0 (24-August-2018)

Can now build with Py_LIMITED_API, requires Python 3.4 or later.

Changes to support Python 3.7

Re: undefined reference to `Py::ifPyErrorThrowCxxException()'

[Richard S. <hob...@gm...>]

On Wed, Apr 18, 2018 at 1:03 PM, Barry Scott <ba...@ba...> wrote:

>
>
> On 18 Apr 2018, at 14:37, Richard Shaw <hob...@gm...> wrote:
>
> BUILDSTDERR:              throw Py::Exception("abort progress indicator");
> BUILDSTDERR:                                                            ^
>
> And you can see the define added for PYCXX_6_2_COMPATIBILITY...
>
>
> Oh. Looks like I missed off a small part of the backward compat.
>
> That throws a RuntimeError.
>
> I think you can change it to be:
>
> throw Py::RuntimeError("about progress indictor");
>

Thanks, upstream freecad has committed a change and now it builds.

Richard

Re: undefined reference to `Py::ifPyErrorThrowCxxException()'

[Barry S. <ba...@ba...>]

> On 18 Apr 2018, at 14:37, Richard Shaw <hob...@gm...> wrote:
> 
> BUILDSTDERR:              throw Py::Exception("abort progress indicator");
> BUILDSTDERR:                                                            ^
> 
> And you can see the define added for PYCXX_6_2_COMPATIBILITY...

Oh. Looks like I missed off a small part of the backward compat.

That throws a RuntimeError.

I think you can change it to be:

throw Py::RuntimeError("about progress indictor");

Barry

Re: undefined reference to `Py::ifPyErrorThrowCxxException()'

[Richard S. <hob...@gm...>]

Getting closer... I have verified that exx_exceptions is getting compiled:

[ 18%] Building CXX object
src/Base/CMakeFiles/FreeCADBase.dir/usr/src/CXX/cxx_exceptions.cxx.o
cd /builddir/build/BUILD/FreeCAD-0.17/build/src/Base && /usr/bin/c++
-DFreeCADBase_EXPORTS -DHAVE_CONFIG_H -DHAVE_SWIG=1 -DQT_CORE_LIB
-DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_SVG_LIB
-DQT_UITOOLS_LIB -DQT_WEBKIT_LIB -DQT_XML_LIB -D_OCC64
-I/builddir/build/BUILD/FreeCAD-0.17/build -I/usr/include/smesh -isystem
/usr/include/QtOpenGL -isystem /usr/include/QtSvg -isystem
/usr/include/QtUiTools -isystem /usr/include/QtWebKit -isystem
/usr/include/QtGui -isystem /usr/include/QtXml -isystem
/usr/include/QtNetwork -isystem /usr/include/QtCore
-I/builddir/build/BUILD/FreeCAD-0.17/build/src
-I/builddir/build/BUILD/FreeCAD-0.17/src
-I/builddir/build/BUILD/FreeCAD-0.17/build/src/Base
-I/builddir/build/BUILD/FreeCAD-0.17/src/Base -I/usr/include/python2.7
-Wall -Wextra -Wno-write-strings -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection
-DPYCXX_6_2_COMPATIBILITY -std=c++11 -D_OCC64 -fPIC   -o
CMakeFiles/FreeCADBase.dir/usr/src/CXX/cxx_exceptions.cxx.o -c
/usr/src/CXX/cxx_exceptions.cxx

But I'm still getting:

[ 23%] Building CXX object
src/Base/CMakeFiles/FreeCADBase.dir/Sequencer.cpp.o
cd /builddir/build/BUILD/FreeCAD-0.17/build/src/Base && /usr/bin/c++
-DFreeCADBase_EXPORTS -DHAVE_CONFIG_H -DHAVE_SWIG=1 -DQT_CORE_LIB
-DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_DEBUG -DQT_OPENGL_LIB -DQT_SVG_LIB
-DQT_UITOOLS_LIB -DQT_WEBKIT_LIB -DQT_XML_LIB -D_OCC64
-I/builddir/build/BUILD/FreeCAD-0.17/build -I/usr/include/smesh -isystem
/usr/include/QtOpenGL -isystem /usr/include/QtSvg -isystem
/usr/include/QtUiTools -isystem /usr/include/QtWebKit -isystem
/usr/include/QtGui -isystem /usr/include/QtXml -isystem
/usr/include/QtNetwork -isystem /usr/include/QtCore
-I/builddir/build/BUILD/FreeCAD-0.17/build/src
-I/builddir/build/BUILD/FreeCAD-0.17/src
-I/builddir/build/BUILD/FreeCAD-0.17/build/src/Base
-I/builddir/build/BUILD/FreeCAD-0.17/src/Base -I/usr/include/python2.7
-Wall -Wextra -Wno-write-strings -O2 -g -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -grecord-gcc-switches
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection
-DPYCXX_6_2_COMPATIBILITY -std=c++11 -D_OCC64 -fPIC   -o
CMakeFiles/FreeCADBase.dir/Sequencer.cpp.o -c
/builddir/build/BUILD/FreeCAD-0.17/src/Base/Sequencer.cpp
BUILDSTDERR: /builddir/build/BUILD/FreeCAD-0.17/src/Base/Sequencer.cpp: In
member function 'Py::Object Base::ProgressIndicatorPy::next(const
Py::Tuple&)':
BUILDSTDERR:
/builddir/build/BUILD/FreeCAD-0.17/src/Base/Sequencer.cpp:370:59: error: no
matching function for call to 'Py::Exception::Exception(const char [25])'
BUILDSTDERR:              throw Py::Exception("abort progress indicator");
BUILDSTDERR:                                                            ^

And you can see the define added for PYCXX_6_2_COMPATIBILITY...

Thanks,
Richard