kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 01/15/2013 12:28 PM, Wayne Stambaugh wrote:
> On 1/15/2013 10:16 AM, Wayne Stambaugh wrote:
>> On 1/15/2013 9:33 AM, Dick Hollenbeck wrote:
>>> On 01/15/2013 08:10 AM, Wayne Stambaugh wrote:
>>>> On 1/14/2013 10:15 PM, Dick Hollenbeck wrote:
>>>>> On Jan 14, 2013 8:27 PM, "Dick Hollenbeck" <dick@xxxxxxxxxxx
>>>>> <mailto:dick@xxxxxxxxxxx>> wrote:
>>>>>> I want to simplify the conversation and refer to these needed items as
>>>>> windows "packages".
>>>>>> Python
>>>>>> Python-dev
>>>>>> WxPython
>>>>>> WxPython-dev
>>>>> WxWidgets
>>>>> WxWidgets-dev
>>>> wxPython-dev includes wxWidgets-dev so it should work fine for KiCad
>>>> builds without scripting as well.  It should just be a matter of
>>>> creating the MinGW linker stubs to the MSVC built libraries provided by
>>>> the wxPython-dev package.  The only caveat may be if there is any name
>>>> mangling issues between the two linkers. 
>>>
>>> We were reminded recently that stub libraries can use ordinals instead of names.
>>>
>>> As long as the DLL entry points follow the Windows DLL ABI  for argument passing and stack
>>> cleanup, then it is in theory possible.
>>>
>>> With so many competing ABIs on Windows, it is also in possible that somebody screwed up
>>> when building the pre-built DLLs, and you won't notice it until you bring in the second
>>> compiler technology, i.e. Mingw.
>>>
>>> In that case it might mean building the DLLs yourself, instead of repackaging standard
>>> ones.  And at that point you'd want to kick some ass, just to make somebody pay for their
>>> disregard for the rest of the [non-Microsoft] world.
>> Trust me, it's way past that already.  This has been a complete exercise
>> in frustration.  It really shouldn't be this difficult.
> The problem I am having with the MinGW build of wxPython is described at
> the end of the the following thread:
>
> https://groups.google.com/forum/?fromgroups=#!topic/wxpython-users/brmQH4FSCo4
>
> I confirmed that both msvcrt and msvcr90 are being linked to all of the
> wxPython extension files.
>
> Below is an explanation of the differences between the MS runtime libraries.
>
> http://msdn.microsoft.com/en-us/library/abx4dbyh(v=vs.80).aspx
>
> There are several solutions but none of them are attractive.
>
> 1) Rebuild Python with one of the express versions MSVC and link against
> msvcrt instead of the MSVC specific version.
>
> 2) Rebuild mingw10.dll and link against the same msvcr??.dll as the
> installed Python is build against.
>
> 3) Do as the thread above discussed and modify Python distutils to
> ignore the version of msvcr??.dll that Python is linked against.
>
> 4) Figure out how to build Python with MinGW.  See the following link to
> get an idea of how much of a task that will be.
>
> http://bugs.python.org/issue10504
>
> 5) Fix KiCad to build with the correct version of the free (as in beer)
> express version of MSVC used to build Python.
>
> 6) Run around the room screaming and pulling out what is left of your hair.
>
> At this point, my desire to see this through has dropped substantially.
>  In the near term, I'll just use Linux when I need to do scripting.  I
> will continue to chip away at it but don't expect a solution any time
> soon.  If anyone has a better idea, I'm open to suggestion.


Yeah, somebody could actually pay for it.

Expertise and time like this is not free,  and this is a case where opensource fails to
clear this hurdle without funding.

Notice I did not volunteer, it cannot be free.