kicad-developers team mailing list archive

[Miguel Ángel Ajo <majopela@xxxxxxxxxx>]

Hmm, this crashes in the fedora nightly build during pcbnew startup, I need to investigate why.

https://github.com/KiCad/kicad-source-mirror/commit/69553d6fa31a60a4694395f0dcadfdbd787c21a8#diff-cdb8e872a96e63280c27292a5845cfbeR147

snprintf( cmd, 1023, "import wxversion; wxversion.select('%s')", WXPYTHON_VERSION ); PyRun_SimpleString( cmd );  


Miguel Ángel Ajo


On Tuesday, 17 de February de 2015 at 17:31, Brian Sidebotham wrote:

> On 16 February 2015 at 17:44, Wayne Stambaugh <stambaughw@xxxxxxxxx (mailto:stambaughw@xxxxxxxxx)> wrote:
> > On 2/16/2015 11:44 AM, Brian Sidebotham wrote:
> > > On 16 February 2015 at 15:42, Brian Sidebotham
> > > <brian.sidebotham@xxxxxxxxx (mailto:brian.sidebotham@xxxxxxxxx)> wrote:
> > > > On 16 February 2015 at 14:17, Wayne Stambaugh <stambaughw@xxxxxxxxx (mailto: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.
> >  
>  
>  
> Hi Wayne,
>  
> Thanks so much for doing a quick sanity check. I forget the check I
> used to do. Perhaps it is no longer an issue these days and I'm worry
> about a past issue. I'll try and re-base KiCad-Winbuilder off the
> MSYS2 project MINGW repos for wxPython and python.
>  
> With regards to Python throwing exceptions, it's written entirely in C
> so there's no risk of it throwing exceptions.
>  
> Best Regards,
>  
> Brian.
>  
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx (mailto:kicad-developers@xxxxxxxxxxxxxxxxxxx)
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>  
>