kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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.

Wayne


<<<snipped>>>