kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

On 25 January 2013 14:45, Wayne Stambaugh <stambaughw@xxxxxxxxxxx> wrote:

> On 1/25/2013 7:55 AM, Brian Sidebotham wrote:
> > I was having a quick look at the FreeCAD project as it is a CPP project
> > with python scripting integrated. Of interest is that they do not use
> > anything other than the MSVC pre-build version of python.
> >
> > Here's a link to the README for building FreeCAD with mingw:
> >
> >
> http://free-cad.git.sourceforge.net/git/gitweb.cgi?p=free-cad/free-cad;a=blob_plain;f=README.MinGW;hb=HEAD
> >
> > And a relevant excerpt from that readme:
> >
> > o Python
> > It seems to be nearly impossible to build the Python sources directly
> with the MinGW
> > compiler. This is because some Python modules require some features
> which are not
> > implemented on the MinGW platform. Fortunately, the Python sources are
> plain C code
> > and instead of trying to build it with MinGW you can get a ready binary
> package built
> > with the MSVC compiler. You can install the Python stuff whereever you
> want. Afterwards
> > copy the include folder to C:\MSYS\1.0\local, the DLL can go to
> C:\MSYS\1.0\local\bin.
> >
> > Now we also need the so called import library. There we cannot use the
> .lib file which
> > comes together with the installer. But it's easy to create one with the
> pexports/dlltool
> > utilities. Assuming the Python version is 2.6 do these two steps:
> >
> >   pexports python26.dll > python26.def
> >   dlltool -D python26.dll -d python26.def -l libpython26.dll.a
>
> Brian,
>
> This is documented in the MinGW wiki for as long as I can remember
> (which apparently isn't very long these days :)).  The problem is
> getting wxPython to build properly against the MinGW build of wxWidgets
> and the Visual Studio build of Python.  The problem is that MinGW is
> linked against the generic C run time library msvcrt.dll and Python is
> linked against msvcrXX.dll where XX is the C run time library version
> specific to the version of Visual Studio used to build Python.  For
> Python 2.7.3 this is msvcr90.dll.  The problem is these two libraries
> both provide the C run time.  Obviously when both of these libraries get
> linked it causes library load issues when you attempt to run wxPython
> due to conflicts.  According to the link I sent last week, you can edit
> your Python distutils.cygwincompiler.py file to prevent msvcrXX.dll from
> being added to the link list which supposedly fixes the problem.  I'm
> not sure I'm comfortable with that solution.  Modifying default Python
> files is rarely a good idea and I'm not sure that there are not
> incompatibilities between msvcrt.dll and msvcr90.dll that will not cause
> other problems.  Ideally, the Python binaries should be built against
> msvcrt.dll instead of msvcrXX.dll.  If memory serves, there is switch in
> Visual Studio that tells the linker to use the generic msvcrt.dll
> instead of the msvcrXX.dll version that comes with Visual Studio.
> Apparently this is Microsoft's attempt at using version specific
> libraries.  Maybe they should have copied libtool.
>
> >
> > The file libpython26.dll.a can now be moved to C:\MSYS\1.0\local\lib.
>
> A better place for this file is /mingw/lib since you are using it to
> build MinGW executable files.  Remember MSYS and MinGW binaries are not
> the same thing even thought they are both Windows executable files.
> MSYS is linked against msys-1.0.dll and MinGW is linked against
> mingwm10.dll.  The MinGW wiki has a lot of good information about the
> dos, don'ts, and differences between the two.
>
>
Hi Wayne,

Thanks for that information. I soon realised that this wasn't really the
way we should probably head, but at the time it seemed like useful
information. Sorry, I'm being a bit noisy on the list today!

Anyway, the specs file modifications I mentioned in another mail seem like
a possible solution for linking MinGW executables against different MS CRT
versions. But I can't get round to testing until tonight.

Best Regards, Brian.