kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

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.

> 
> 
> Best Regards, Brian.
> 
> 
> On 24 January 2013 22:42, Brian Sidebotham <brian.sidebotham@xxxxxxxxx
> <mailto:brian.sidebotham@xxxxxxxxx>> wrote:
> 
>     A quick test to build wxPython with a freshly compiled python-mingw
>     with binascii package results in the next problem. One that looks a
>     bit more fundamental to sort out:
> 
>     This is what I get compiling the most basic of extension with this
>     python-mingw, the error is the same when trying to build wxPython too:
> 
>     KiCad-WinbuilderC:\kicad-winbuilder-dev\kicad-winbuilder\src\wx\testmodule>python
>     setup.py build -c mingw32
>     running build
>     running build_ext
>     Warning: Can't read registry to find the necessary compiler setting
>     Make sure that Python modules _winreg, win32api or win32con are
>     installed.
>     building 'hello' extension
>     C:\kicad-winbuilder-dev\kicad-winbuilder\env\mingw\bin\gcc.exe
>     -mno-cygwin -mdll
>      -O -Wall
>     -IC:\kicad-winbuilder-dev\kicad-winbuilder\env\python\include -IC:\kic
>     ad-winbuilder-dev\kicad-winbuilder\env\python\PC -c testmodule.c -o
>     build\temp.w
>     in32-2.7\Release\testmodule.o
>     Traceback (most recent call last):
>       File "setup.py", line 8, in <module>
>         ext_modules = [module1])
>       File
>     "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
>     ils\core.py", line 152, in setup
>         dist.run_commands()
>       File
>     "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
>     ils\dist.py", line 953, in run_commands
>         self.run_command(cmd)
>       File
>     "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
>     ils\dist.py", line 972, in run_command
>         cmd_obj.run()
>       File
>     "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
>     ils\command\build.py", line 127, in run
>         self.run_command(cmd_name)
>       File
>     "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
>     ils\cmd.py", line 326, in run_command
>         self.distribution.run_command(command)
>       File
>     "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
>     ils\dist.py", line 972, in run_command
>         cmd_obj.run()
>       File
>     "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
>     ils\command\build_ext.py", line 340, in run
>         self.build_extensions()
>       File
>     "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
>     ils\command\build_ext.py", line 449, in build_extensions
>         self.build_extension(ext)
>       File
>     "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
>     ils\command\build_ext.py", line 499, in build_extension
>         depends=ext.depends)
>       File
>     "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
>     ils\ccompiler.py", line 624, in compile
>         self._compile(obj, src, ext, cc_args, extra_postargs, pp_opts)
>       File
>     "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
>     ils\cygwinccompiler.py", line 164, in _compile
>         extra_postargs)
>       File
>     "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
>     ils\ccompiler.py", line 925, in spawn
>         spawn(cmd, dry_run=self.dry_run)
>       File
>     "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
>     ils\spawn.py", line 36, in spawn
>         _spawn_nt(cmd, search_path, dry_run=dry_run)
>       File
>     "C:\kicad-winbuilder-dev\kicad-winbuilder\env\python\lib\python2.7\distut
>     ils\spawn.py", line 69, in _spawn_nt
>         rc = os.spawnv(os.P_WAIT, executable, cmd)
>     AttributeError: 'module' object has no attribute 'spawnv'
> 
>     Basically it's down to not having pywin32 installed or any other
>     win32api module. The trouble is they all seem to require compiling
>     with msvc.
> 
>     I've run out of time again.
> 
>     Best Regards, Brian.
> 
> 
>     On 24 January 2013 08:41, Brian Sidebotham
>     <brian.sidebotham@xxxxxxxxx <mailto:brian.sidebotham@xxxxxxxxx>> wrote:
> 
>         I compiled python-mingw last night on a linux box with zlib and
>         expat so binascii and a few other modules get built-in, but I
>         ran out of time to test. I'll try and test building
>         wxPython with it tonight. I had to manually point cmake to the
>         libraries though, the find_package... functions do not appear to
>         work even though zilb and expat are available in the built-in
>         search paths.
> 
>         I had to patch ./Modules/socketmodule.h to change the header
>         <MSTcpIP.h> to <wincrypt.h> as MinGW on my linux box didn't have
>         MSTcpIP.h
> 
>         It appeared to build fine after that though.
> 
>         Best Regards, Brian.
> 
> 
>         On 21 January 2013 21:27, Miguel Angel Ajo Pelayo
>         <miguelangel@xxxxxxx <mailto:miguelangel@xxxxxxx>> wrote:
> 
>             Hi Brian!!, 
> 
>             On 21/01/2013, at 20:28, Brian Sidebotham
>             <brian.sidebotham@xxxxxxxxx
>             <mailto:brian.sidebotham@xxxxxxxxx>> wrote:
> 
>>             Hi Guys,
>>
>>             Sorry I'm late to the party, I've been doing wedding stuff
>>             for a while. It'll continue for the next few months.
>>
> 
>             Hehehe, are you sure of what you're doing? (just joking,
>             congratulations if I didn't already) ;)
> 
>>             I tried the MinGW python to build wxPython, but it falls
>>             over instantly because there's no binascii package. I fear
>>             that the base packages all need to be built with this
>>             python first before the wxPython can be built with it. It
>>             is probably worth noting to anyone desperate that the
>>             multiple crt problem is only apparent for Python V2.6 and
>>             greater. Python 2.5 does not suffer this problem apparently.
>>
> 
>             Whoops, ok, binascii needed, yes I suppose that we will need
>             packages here and there but eventually it must work.
> 
>>             Another problem is that GLCANVAS is not currently
>>             supported by wxPython. But I expect that just means that
>>             scripting will not have access to a 3D canvas?
>>
> 
>             Yes, that only means that the python side won't have access
>             to the 3D canvas, but wx must be compiled with it enabled.
>             GLCANVAS is used at the moment or in the GAL?, I've used 3D
>             + wxpython in linux, for sure.
> 
>>             On another note, whilst building with a standard python
>>             install I get the following error:
>>
>>             Traceback (most recent call last):
>>               File
>>             "C:/kicad-winbuilder-dev/kicad-winbuilder/src/kicad/pcbnew/../scripting/fixswigimports.py",
>>             line 26, in <module>
>>                 f = open(filename,"rb")
>>             IOError: [Errno 2] No such file or directory:
>>             'C:/kicad-winbuilder-dev/kicad-winbuilder/build/release/pcbnew/pcbnew.py'
>>             mingw32-make[2]: ***
>>             [pcbnew/CMakeFiles/FixSwigImportsScripting] Error 1
>>             mingw32-make[1]: ***
>>             [pcbnew/CMakeFiles/FixSwigImportsScripting.dir/all] Error 2
>>             mingw32-make[1]: *** Waiting for unfinished jobs....
>>             mingw32-make: *** [all] Error 2
>>
> 
>             Hmm, that .py is looking for the swig generated pcbnew.py
>             file, to fix the way it imports. There is no "pcbnew.py"
>             generated?
>             is swig executed before that? (the result must be the
>             .cxx/.cpp wrapper and the pcbnew.py
> 
> 
>>             Best Regards, Brian.
>>
>>             On 20 January 2013 20:55, Wayne Stambaugh
>>             <stambaughw@xxxxxxxxxxx <mailto:stambaughw@xxxxxxxxxxx>>
>>             wrote:
>>
>>                 On 1/20/2013 2:08 PM, Miguel Angel Ajo Pelayo wrote:
>>                 > Argh, no need to apologize Wayne, I hope they can
>>                 recover your system
>>                 > and provide you with something that works in an
>>                 stable way.
>>                 >
>>                 > I really hate when those things happen, 4-5 years
>>                 ago I had a problem like
>>                 > this with a couple of laptops, after some time we
>>                 suspected of power surges
>>                 > in the electrical line, because some more little
>>                 things died around, and
>>                 > I was
>>                 > astonished with the fact that the power adapter (2
>>                 different models)
>>                 > didn't kill those surges properly, which
>>                 surprisingly only killed the
>>                 > hard-disks ...
>>                 >
>>                 > I wish you good luck with the repair.
>>                 >
>>                 > for the time being, I've been able to build a couple
>>                 of packages:
>>                 >
>>                 >
>>                 http://dev.kicad-pcb.org/pkgs/Python-2.7.1-mingw32.tar.gz
>>                 >
>>                 http://dev.kicad-pcb.org/pkgs/Python-2.7.1-mingw32-builder.tar.gz
>>                  <--
>>                 > those are my cross build scripts at the moment that
>>                 expect some files in
>>                 > "archive" directory.
>>
>>                 I'll download them and take a look at them.  I'm using
>>                 my laptop right
>>                 now which is way to slow to be building really big
>>                 projects like Python.
>>                  By the time I get them built, my desktop will be back
>>                 from HP's repair
>>                 department.
>>
>>                 >
>>                 > The python-2.7.1 we've built runs for win32, and I'm
>>                 installing it to
>>                 > C:\Python, but could go other places
>>
>>                 The binary archive is a good start but most Window's
>>                 users will expect
>>                 an installer.  I didn't see any CPack stuff in the
>>                 CMake files used to
>>                 build Python so there will be a lot of work to do in
>>                 that regard.
>>
>>                 >
>>                 > It's important to set those vars before execution:
>>                 >
>>                 > set PYTHONHOME=C:\Python
>>                 > set PYTHONPATH=C:\Python\lib\python2.7;C:\Python\pyd
>>                 >
>>                 >
>>                 > And it also provides include files and .a libs
>>
>>                 These are key to building other extensions.
>>
>>                 >
>>                 > It took me ages to figure that I had missaplied one
>>                 of the patches (the
>>                 > 05 one, that needed patch -p1 instead of -p0) and
>>                 didn't let me build
>>                 > the .dll version for win32.
>>                 >
>>                 > Also "CRYPT" and "PYEXPAT" packages are disabled now
>>                 for a lack of
>>                 > libraries.
>>
>>                 I'm pretty sure libexpat builds on MinGW.  There is an
>>                 expat package
>>                 available for MinGW.  I'm not sure about the crypt
>>                 library.
>>
>>                 >
>>                 > This killed all my spare time from the last email on
>>                 the topic, which
>>                 > it's been a lot more than expected.
>>
>>                 I'm not surprised, these things always end up taking
>>                 more time than I
>>                 think they will.  Thank you for all of you efforts.
>>
>>                 Wayne
>>
>>                 >
>>                 > I'm afraid that I'll need to ask for a lot of help
>>                 if we really want to
>>                 > build a set of shiny packages.
>>                 >
>>                 > My next step is trying to compile the wxpython +
>>                 kicad with this python
>>                 > binary package, but I will wait until you can
>>                 recover your data, may be
>>                 > others are happy trying our shiny mingw-win32 python
>>                 package :-)
>>                 >
>>                 > Greetings, Mike
>>                 >
>>                 >
>>                 >
>>                 >
>>                 >
>>                 >
>>                 >
>>                 >
>>                 >
>>                 >
>>                 >
>>                 >
>>                 >
>>                 > 2013/1/20 Wayne Stambaugh <stambaughw@xxxxxxxxxxx
>>                 <mailto:stambaughw@xxxxxxxxxxx>
>>                 > <mailto:stambaughw@xxxxxxxxxxx
>>                 <mailto:stambaughw@xxxxxxxxxxx>>>
>>                 >
>>                 >     On 1/16/2013 12:56 PM, Wayne Stambaugh wrote:
>>                 >     > On 1/16/2013 12:16 PM, Miguel Angel Ajo Pelayo
>>                 wrote:
>>                 >     >> Other option we could have right now is
>>                 compile out the wxpython
>>                 >     support and provide
>>                 >     >> only embedded python scripting + python
>>                 pcbnew module for windows
>>                 >     users.
>>                 >     >>
>>                 >     >> In that case, next functionalities are lost:
>>                 >     >>
>>                 >     >> 1) PyCrust shell inside pcbnew
>>                 >     >> 2) Ability to create and run own wx-uis in
>>                 the embedded python
>>                 >     scripting.
>>                 >     >>
>>                 >     >> And we keep:
>>                 >     >>
>>                 >     >> 3) pcbnew module for commandline python scripting
>>                 >     >> 4) embedded pcbnew wizards & plugins
>>                 >     >>
>>                 >     >> Wayne, could you document the steps you
>>                 followed until now so I
>>                 >     can try to reproduce it and fight a little bit
>>                 in this war ?
>>                 >     >
>>                 >     > Please see my response to Adam.  I'll add the
>>                 Pthon command line
>>                 >     > scripting build instructions for Windows using
>>                 MinGW to
>>                 >     > Documentation/compiling/COMPILING.txt in my
>>                 next commit.
>>                 >
>>                 >     Bad news Miguel.  I was almost ready to commit
>>                 this when my home system,
>>                 >     which I just got back from HP's warranty repair
>>                 service the week before
>>                 >     Christmas, died again.  I've already contacted
>>                 HP service but it will
>>                 >     likely be at least a week before I get my system
>>                 back.  Needless to say
>>                 >     I am not happy.  This will be the third time
>>                 (one disk drive and one
>>                 >     motherboard) the system has had problems since I
>>                 bought it.  I apologize
>>                 >     for the delay.  As soon as I get my system back,
>>                 I'll get this
>>                 >     committed.
>>                 >
>>                 >     Wayne
>>                 >
>>                 >     >
>>                 >     >>
>>                 >     >>
>>                 >     >> Miguel Angel Ajo
>>                 >     >> http://www.nbee.es <http://www.nbee.es/>
>>                 >     >> +34911407752 <tel:%2B34911407752>
>>                 <tel:%2B34911407752>
>>                 >     >> skype: ajoajoajo
>>                 >     >>
>>                 >
>>                 >     <<<snipped>>>
>>                 >
>>                 >
>>                 >
>>                 >
>>                 > --
>>                 >
>>                 > Miguel Angel Ajo Pelayo
>>                 > http://www.nbee.es <http://www.nbee.es/>
>>                 > +34 636 52 25 69 <tel:%2B34%20636%2052%2025%2069>
>>                 > skype: ajoajoajo
>>
>>
>>                 _______________________________________________
>>                 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
>>
>>
> 
> 
> 
>