kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

2015-02-16 17:44 GMT+01:00 Brian Sidebotham <brian.sidebotham@xxxxxxxxx>:
> 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.
>
> 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?)

MSYS2 can also build 32-bit, as far as I understand. (I am not sure if
this is what you say it can't according to your statement, but I think
so.)