<div dir="ltr">Well, if they aren't, then every effort should be made to <i>make</i> them compatible, right? With <u>some</u><i> </i>release of the dependency, at least, even if it has to be a specific one. I mean, compatibility only with a particular build that's distributed by the project as an opaque precompiled binary is hardly compatibility at all, from a FLOSS standpoint. Reminds me of the "bad old days" 10 years ago, when every project that used FFmpeg could only be built with the exact source tree that was bundled in with their project, and every project had its own, subtly different build of ffmpeg that they expected to be linked with.<br><br>That was awful and made everyone sad, so through herculean effort and endless hacking by both the ffmpeg team and the dependent projects, APIs were matured, callers worked out how to best code against the "stock" libraries, and the situation was slowly evolved to the point where, today, most projects can all be linked with the same stock FFmpeg libs, centrally installed, without requiring hardly any changes at all. It's like living in the future.<div><br></div><div>Heck, some projects can even be built against a <b>newer</b> release of FFmpeg than the one they were developed with! (Occasionally. Like, if it's one, maybe two releases later, you might have a chance. Their API is still an endlessly moving target, and if you have code that was written for FFmpeg 3.4 and you're already updated to 4.0, you're still Gonna Have A Bad Time™.)<br><br>...Anyway, point is, in an ideal world (which is not the world we live in — conceded) the answer to "how do you know it's compatible" would be something as plain as, "Says right in the README, requires version N.M or higher." I guess that's either naive, or optimistic. You decide. (But since you don't know me: smart money's on naive over optimistic.)</div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jul 6, 2018 at 5:40 PM Phil Thompson <<a href="mailto:phil@riverbankcomputing.com">phil@riverbankcomputing.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 06/07/2018 17:54, Scott Talbert wrote:<br>
> On Fri, 6 Jul 2018, Phil Thompson wrote:<br>
> <br>
>>>>>> Hi,<br>
>>>>>> <br>
>>>>>> I'm seeing a segfault when building wxPython with SIP 4.19.11.<br>
>>>>>> <br>
>>>>>> Running command: sip<br>
>>>>>> /usr/bin/sip -w -o -g -I <br>
>>>>>> /home/talbert/Downloads/wxPython-4.0.1/src -I<br>
>>>>>> /home/talbert/Downloads/wxPython-4.0.1/sip/gen -c /tmp/tmpdH4lfu <br>
>>>>>> -b<br>
>>>>>> sip/cpp/_core.sbf -X pycode_core:wx/core.py sip/gen/_core.sip<br>
>>>>>> Segmentation fault (core dumped)<br>
>>>>>> <br>
>>>>>> (gdb) bt<br>
>>>>>> #0 prcode (fp=fp@entry=0x55f0f0d13ed0, fmt=0x55f0f042adc7 <br>
>>>>>> "\");\n#else\n",<br>
>>>>>> fmt@entry=0x55f0f042ad58 " /* Get the SIP module's API. <br>
>>>>>> */\n#if<br>
>>>>>> PY_VERSION_HEX >= 0x02050000\n sip_sipmod =<br>
>>>>>> PyImport_ImportModule(\"%s\");\n#else\n")<br>
>>>>>> at ./sipgen/gencode.c:14489<br>
>>>>>> #1 0x000055f0f04004e6 in generateSipImport (mod=0x55f0f0d14180,<br>
>>>>>> fp=0x55f0f0d13ed0, sipName=0x0) at ./sipgen/gencode.c:2775<br>
>>>>>> #2 generateCpp (pt=pt@entry=0x7ffd5c4cabc0, mod=<optimized out>,<br>
>>>>>> codeDir=codeDir@entry=0x7ffd5c4cc455 "/tmp/tmpdH4lfu",<br>
>>>>>> srcSuffix=srcSuffix@entry=0x55f0f0422866 ".cpp", <br>
>>>>>> parts=parts@entry=0,<br>
>>>>>> needed_qualifiers=needed_qualifiers@entry=0x0, xsl=0x0, <br>
>>>>>> py_debug=0,<br>
>>>>>> sipName=0x0) at ./sipgen/gencode.c:2561<br>
>>>>>> #3 0x000055f0f0403269 in generateCode (pt=0x7ffd5c4cabc0,<br>
>>>>>> codeDir=0x7ffd5c4cc455 "/tmp/tmpdH4lfu",<br>
>>>>>> buildFile=0x7ffd5c4cc467 "sip/cpp/_core.sbf", <br>
>>>>>> docFile=<optimized out>,<br>
>>>>>> srcSuffix=0x55f0f0422866 ".cpp", except=<optimized out>, <br>
>>>>>> trace=0,<br>
>>>>>> releaseGIL=1, parts=0, needed_qualifiers=0x0, xsl=0x0, <br>
>>>>>> consModule=0x0,<br>
>>>>>> docs=1, py_debug=0, sipName=0x0) at ./sipgen/gencode.c:358<br>
>>>>>> #4 0x000055f0f03e4e15 in main (argc=15, argv=0x7ffd5c4cae58)<br>
>>>>>> at ./sipgen/main.c:291<br>
>>>>>> <br>
>>>>>> 4.19.8 worked ok.<br>
>>>>> <br>
>>>>> It should be fixed in the current snapshot. 4.19.12 will be <br>
>>>>> released<br>
>>>>> over the weekend.<br>
>>>> <br>
>>>> However there are slight changes to the way a private sip module is <br>
>>>> specified. I don’t know if this affects how wxPython is built.<br>
>>> <br>
>>> I don't know either. When I build wxPython, I am building it for<br>
>>> Fedora or Debian packages, and I build it using the public sip <br>
>>> module,<br>
>>> stripping out the bundled copy.<br>
>> <br>
>> How do you know that the two are compatible?<br>
> <br>
> That wxPython is compatible with a given version of sip, or whether a<br>
> public sip module is compatible with the version of sip that wxPython<br>
> was compiled with?<br>
<br>
Both.<br>
<br>
Phil<br>
<br>
_______________________________________________<br>
PyQt mailing list <a href="mailto:PyQt@riverbankcomputing.com" target="_blank">PyQt@riverbankcomputing.com</a><br>
<a href="https://www.riverbankcomputing.com/mailman/listinfo/pyqt" rel="noreferrer" target="_blank">https://www.riverbankcomputing.com/mailman/listinfo/pyqt</a></blockquote></div></div>