← Back to team overview

kicad-developers team mailing list archive

Re: wxPython version check

 

On 2/16/2015 11:44 AM, Brian Sidebotham wrote:
> On 16 February 2015 at 15:42, Brian Sidebotham
> <brian.sidebotham@xxxxxxxxx> wrote:
>> On 16 February 2015 at 14:17, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
>>> Brian,
>>>
>>> How are you telling the kicad configuration where wxPython build is
>>> located during you winbuilder configuration?  Would Garth's solution
>>> below solve your problem?  The only issue I see with Garth's solution is
>>> that if you install wxPython somewhere other than where you defined
>>> PYTHON_SITE_PACKAGE_PATH, you would be right back to where you started.
>>>  In other words you could build kicad but when you launched the python
>>> console, it would most likely crash because wxPython would not be
>>> located at PYTHON_SITE_PACKAGE_PATH or worse a different version of
>>> wxPython would be loaded.
>>
>> Hi Wayne,
> 
>> These days however packages like mingw-w64-python2 exist and so really
>> we should be able to make use of that in KiCad-Winbuilder instead of
>> the custom projects. I'll look into it.
>>
> 
> I just checked http://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686/mingw-w64-i686-python2-2.7.9-2-any.pkg.tar.xz/download
> 
> Unfortunately we get: libgcc_s_dw2-1.dll is missing. This is a
> show-stopper in my opinion because dwarf-2 is known to be broken with
> regards to throwing exceptions across DLL boundaries. Since the Kiway
> work there's no real option but to support exception throwing across
> DLL boundaries otherwise exceptions cannot propagate correctly.

After all this time, this issue hasn't been addressed?  This was an
issue over 10 years ago.  This makes me feel better about the bug fixing
rate in KiCad.  I'm not sure which code in KiCad would cause this error.
 Most of the exceptions that I can think of do not cross DLL boundaries.
 They only cross from the DLL to the main executable which does not
fail.  I just tested the pretty library parser which throws an IO_ERROR
from _pcbnew.kiface to pcbnew.exe without any issues.  I don't think
wxWidgets raises any an most of Boost is the header libraries so that
wouldn't be an issue either.  Do Python exceptions cross over into C++
land?  If so, that could be an error.

> 
> That's why the KiCad-Winbuilder toolchain uses mingw-w64 sjlj
> throughout (including dependencies) because it's not broken,
> regardless of whether it's regarded as slower than dwarf-2. x86_64
> should be good though as it uses SEH.
> 
> Is the KiCad msys2 package built using the same, I guess it must be?
> Really it means it's broken because there are plenty of places in the
> KiCad code when exceptions go across DLL boundaries. While it will
> work until an exception occurs, it will simply crash rather than
> handle the exception *if* the exception goes across a DLL boundary. I
> used to know how to trigger that in the KiCad code, but I cannot
> remember what I used to do. It is testable.
> 
> Therefore msys2 packages are not usable by KiCad-Winbuilder for now
> anyway, unless I move it to 64-bit only. (Does anyone still run 32-bit
> these days?)
> 
> Best Regards,
> 
> Brian.
> 



Follow ups

References