[PyQt] Segfault when building wxPython with SIP 4.19.11

[Scott Talbert]

On Sat, 7 Jul 2018, Phil Thompson wrote:

>>>>>>>>> Hi,
>>>>>>>>> I'm seeing a segfault when building wxPython with SIP 4.19.11.
>>>>>>>>> Running command: sip
>>>>>>>>> /usr/bin/sip -w -o -g -I /home/talbert/Downloads/wxPython-4.0.1/src -I
>>>>>>>>> /home/talbert/Downloads/wxPython-4.0.1/sip/gen -c /tmp/tmpdH4lfu -b
>>>>>>>>> sip/cpp/_core.sbf -X pycode_core:wx/core.py sip/gen/_core.sip
>>>>>>>>> Segmentation fault (core dumped)
>>>>>>>>> (gdb) bt
>>>>>>>>> #0  prcode (fp=fp at entry=0x55f0f0d13ed0, fmt=0x55f0f042adc7 "\");\n#else\n",
>>>>>>>>>    fmt at entry=0x55f0f042ad58 "    /* Get the SIP module's API. */\n#if
>>>>>>>>> PY_VERSION_HEX >= 0x02050000\n    sip_sipmod =
>>>>>>>>> PyImport_ImportModule(\"%s\");\n#else\n")
>>>>>>>>>    at ./sipgen/gencode.c:14489
>>>>>>>>> #1  0x000055f0f04004e6 in generateSipImport (mod=0x55f0f0d14180,
>>>>>>>>>    fp=0x55f0f0d13ed0, sipName=0x0) at ./sipgen/gencode.c:2775
>>>>>>>>> #2  generateCpp (pt=pt at entry=0x7ffd5c4cabc0, mod=<optimized out>,
>>>>>>>>>    codeDir=codeDir at entry=0x7ffd5c4cc455 "/tmp/tmpdH4lfu",
>>>>>>>>>    srcSuffix=srcSuffix at entry=0x55f0f0422866 ".cpp", parts=parts at entry=0,
>>>>>>>>>    needed_qualifiers=needed_qualifiers at entry=0x0, xsl=0x0, py_debug=0,
>>>>>>>>>    sipName=0x0) at ./sipgen/gencode.c:2561
>>>>>>>>> #3  0x000055f0f0403269 in generateCode (pt=0x7ffd5c4cabc0,
>>>>>>>>>    codeDir=0x7ffd5c4cc455 "/tmp/tmpdH4lfu",
>>>>>>>>>    buildFile=0x7ffd5c4cc467 "sip/cpp/_core.sbf", docFile=<optimized out>,
>>>>>>>>>    srcSuffix=0x55f0f0422866 ".cpp", except=<optimized out>, trace=0,
>>>>>>>>>    releaseGIL=1, parts=0, needed_qualifiers=0x0, xsl=0x0, consModule=0x0,
>>>>>>>>>    docs=1, py_debug=0, sipName=0x0) at ./sipgen/gencode.c:358
>>>>>>>>> #4  0x000055f0f03e4e15 in main (argc=15, argv=0x7ffd5c4cae58)
>>>>>>>>>    at ./sipgen/main.c:291
>>>>>>>>> 4.19.8 worked ok.
>>>>>>>> It should be fixed in the current snapshot. 4.19.12 will be released
>>>>>>>> over the weekend.
>>>>>>> However there are slight changes to the way a private sip module is specified. I don’t know if this affects how wxPython is built.
>>>>>> I don't know either.  When I build wxPython, I am building it for
>>>>>> Fedora or Debian packages, and I build it using the public sip module,
>>>>>> stripping out the bundled copy.
>>>>> How do you know that the two are compatible?
>>>> That wxPython is compatible with a given version of sip, or whether a
>>>> public sip module is compatible with the version of sip that wxPython
>>>> was compiled with?
>>>
>>> Both.
>>
>> Well, for the first problem, I always make sure that I'm using the recommended version of sip (or higher).  I suppose there's a possibility that something could break in a future version of sip, but that generally hasn't happened.
>>
>> For the second problem, the public sip module will always be at the same version as the compiled version or higher.  I'm supposing that by recommending that sip consumers all use private copies of the module, you're suggesting that there may be problems (in the future?) where a newer version of the public module would not function with an older compiled consumer?
>
> Exactly. The sip module implements an API that has a major.minor version 
> number. Different major versions are, by definition, incompatible. The 
> API version number is completely independent of the version of a sip 
> release.
>
> The whole point of private sip modules is to allow incompatibilities.

Ah.  Well, in general I believe the Fedora sip package maintainers won't 
allow a sip API version change in a Fedora stable release, so I think this 
generally avoids problems.  I suspect Debian does the same.  It's mainly a 
concern in the development branches (rawhide/unstable).

Scott