[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pykde
Subject:    Re: [PyQt] Segfault when building wxPython with SIP 4.19.11
From:       Scott Talbert <swt () techie ! net>
Date:       2018-07-08 4:08:41
Message-ID: alpine.DEB.2.20.1807080006020.21722 () bear ! techie ! net
[Download RAW message or body]

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@entry=0x55f0f0d13ed0, fmt=0x55f0f042adc7 \
> > > > > > > > > "\");\n#else\n", fmt@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@entry=0x7ffd5c4cabc0, mod=<optimized out>,
> > > > > > > > > codeDir=codeDir@entry=0x7ffd5c4cc455 "/tmp/tmpdH4lfu",
> > > > > > > > > srcSuffix=srcSuffix@entry=0x55f0f0422866 ".cpp", \
> > > > > > > > > parts=parts@entry=0, needed_qualifiers=needed_qualifiers@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


[Attachment #3 (text/plain)]

_______________________________________________
PyQt mailing list    PyQt@riverbankcomputing.com
https://www.riverbankcomputing.com/mailman/listinfo/pyqt

[prev in list] [next in list] [prev in thread] [next in thread]