On 01/25/2013 04:08 PM, Brian Sidebotham wrote:
> I think this is worthy of another new thread, but is a fork of the Python
> Scripting
> cmake build macros. There are some notes on using MinGW with msvcr90.dll as a
> target C
> runtime.
>
> I added a new specs file to my local KiCad MinGW install (see attached). This
> goes in
> the <mingw-root>\lib\gcc\${VERSION}\ folder.
>
> Then we need to compile using that specs file. Just use -specs=specs90 as a
> compiler
> option. The default specs file for gcc is called specs. So if you want the
> compiler to
> default to build for msvcr90 you can rename the attached file to specs and
> you will not
> have to use the -specs= compiler option.
>
> The next problem is with msvcr80 onwards where executables require a
> manifest. The
> executable will not run unless it has a manifest. Normally the compiler
> embeds the
> manifest in the executable, but in MinGW's case that doesn't yet happen, so
> you need a
> manifest file like the one attached, named the same as the executable and
> suffixed with
> the extension .manifest. For example for the executable test.exe you need to
> supply
> something like the XML attached in a file called test.exe.manifest alongside
> the executable.
>
> There is some information about the manifest
> here:
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx
> <http://msdn.microsoft.com/en-us/library/windows/desktop/aa374191%28v=vs.85%29.aspx>
>
> Python 2.7 using msvcr90 as the runtime library. You can get the
> re-distributable
> package from the following location if your system is missing
> it: http://www.microsoft.com/en-us/download/details.aspx?id=5582
>
> I believe that the manifest issue can be solved by compiling the latest MinGW
> Runtime
> with a series of patches which will include the manifest.
>
> Some information about patching and compiling the latest MinGW runtime can be
> found here
> along with more information about these
> issues:
> http://developer.berlios.de/devlog/akruis/2012/06/10/msvcr90dll-and-mingw/
>
> All this will move us towards a toolchain that should be able to use the
> pre-compiled
> python and wxpython distributions for Windows.
>
> Dependancy Walker shows this mod to be working correctly. If you get an error
> with a
> test program saying that the C runtime library has been started incorrectly
> it's likely
> there's a problem with the manifest file.
>
> Lastly, apparently GPL V3 has removed the problem with distributing the
> msvcr90.dll (or
> whatever version).
>
> Best Regards, Brian.
Thanks Brian.
Your expertise in the realm of the various Microsof CRT libraries exceeds mine.
Some of
this gets more political than technical as far as I am concerned, and I will
never get
into that MS political stew again. You know, like the "Windows 8 computer",
which has a
hard time booting Linux because Microsoft tricked hardware OEMs into embracing
something
that would lead to a Microsoft tax. My next computer will not have such a bios.
So I will be relying on others, ( you, Wayne, Miguel, ??.. ) to carry this into
daylight.
I have done the heavy lifting, the patch is 3.5 megabytes in size.
But I am willing to toss the entire thing in the trash before I get involved in
kissing
Microsoft's ass again. That means the groveling at the CRT level will have to
be done by
someone else.
About the CMake/Mingw/Python Support:
====================================
This 2.7.4 CMake build environment is only expected to be used to generate
binaries. That
is an important concept to understand, because it keeps you from thinking it is
a
development environment. This patch will not get accepted into the python tree
at the
2.7.x branch. Not until it gets ported to 3.4 will it have a chance of being
accepted,
python team policy. So we can think of having two patches, one for "2.7.4...."
and one
for "dev=3.4" branch. The 2.7.4 patch is where we can learn, and solve our
immediate
need. The "dev" branch patch is important to get accepted because it would
remove us from
any maintenance burden moving forward. Somebody will have to be-friend the
python
developers and dribble the thing in piece by piece, I could get that started at
some
point, but would prefer someone else to eventually take ownership of it. If we
have a lot
of python customers using the 2.7.4 support with a shiny installer, that will
help in
creating appeal.
So I don't want to hear that these 2.7.4 patches won't let you build on
platform XYZ. As
I deliver it, it will work on x86_64 Ubuntu Precise, that is all. I suggest
you might
want to install Virtual Box on Windows64, then install Ubuntu Precise in there.
Or use
two computers. This way you can build the python 2.7.4 Mingw{x86_32,x86_64}
platforms in
the VM, and run it immediately on Windows. Or you could use a second computer.
For the dev=3.4 patch, I will create a copy of this one, and it will evolve
from there.
That one needs to be more polished.
But the problem of course is this: a lot of these ExternalProjects use
autotools/configure, and that won't run on Windows. So the subprojects, which
are now
about 65% of the build, they cannot even be done on Windows in a way that I
could
tolerate. (And this is of course why all projects that use autotools are not
particularly
concerned with the Windows developer.)
Each ExternalProject could be patched with a CMake build environment, then it
could all
happen on Windows.
I will send you some binaries in the next few days. And the work will be in a
bzr
branch. In that branch, "Revision 1" equals pristine python 2.7.4. To
generate the patch
you just do a diff from rev 1 using bzr.
For the wxWindows stuff, I have cross-compiled those in the past using Linux to
Windows.
CMake might only be used to generate installers from the result. A single
ExternProject_Add() would wrap the existing build mechanism, and then do the
packaging
after that.
Same for wxPython.
Dick
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
