Several patches to improve compilation with Mono
Hi,
after trying to compile Python for .NET on ArchLinux x86_64 I have run into several issues which the attached patches fix:
1. Enable Mono config file loading. Otherwise a Python build with UCS4 Unicode strings does not work as the Mono.Posix module cannot find msvcrt (which is mapped to libc in Mono's config files). 2. Python.Runtime.dll.config is missing mappings for Python 2.7 3. The architecture detection code in the Makefile did not work correctly (checking for the 86 substring is true for both x86 as well as x86_64 targets). 4. I have renamed the clrmodule.il target in the Makefile to clrmodule_make.il. Otherwise a fresh SVN checkout would not build as clrmodule.il is already included. 5. Adapt the clrmod Makefile to support Mono 2.8 pkgconfig change. Additionally, retrieve Glib 2 options from its pkgconfig and compile the x86_64 build with -fPIC. 6. Support the standard DESTDIR parameter for the install target. Additionally, install Python.Runtime.dll and Python.Runtime.dll.config to the site-packages folder so it is found by the clr module.
If you have any comments or if there are any issues with these patches please let me know.
Philip
Much appreciated! I'll get these applied to the subversion just as soon as I get a little free time. Thank you very much, Barton
On 5/4/2011 6:24 AM, Philip Lorenz wrote:
Hi,
after trying to compile Python for .NET on ArchLinux x86_64 I have run into several issues which the attached patches fix:
- Enable Mono config file loading. Otherwise a Python build with UCS4
Unicode strings does not work as the Mono.Posix module cannot find msvcrt (which is mapped to libc in Mono's config files). 2. Python.Runtime.dll.config is missing mappings for Python 2.7 3. The architecture detection code in the Makefile did not work correctly (checking for the 86 substring is true for both x86 as well as x86_64 targets). 4. I have renamed the clrmodule.il target in the Makefile to clrmodule_make.il. Otherwise a fresh SVN checkout would not build as clrmodule.il is already included. 5. Adapt the clrmod Makefile to support Mono 2.8 pkgconfig change. Additionally, retrieve Glib 2 options from its pkgconfig and compile the x86_64 build with -fPIC. 6. Support the standard DESTDIR parameter for the install target. Additionally, install Python.Runtime.dll and Python.Runtime.dll.config to the site-packages folder so it is found by the clr module.
If you have any comments or if there are any issues with these patches please let me know.
Philip
Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet
First; thank you very much, Philip. Second; I apologize for letting this slip for so long. Somehow these patches sank low on my list. Then when I went to build on Fedora, I didn't make use of your very helpful and parallel work. I'll be applying patches and testing on Fedora FC15 in the very short term.
Thank you once again for your invaluable experience, Barton
On 05/04/2011 06:24 AM, Philip Lorenz wrote:
Hi,
after trying to compile Python for .NET on ArchLinux x86_64 I have run into several issues which the attached patches fix:
- Enable Mono config file loading. Otherwise a Python build with UCS4
Unicode strings does not work as the Mono.Posix module cannot find msvcrt (which is mapped to libc in Mono's config files). 2. Python.Runtime.dll.config is missing mappings for Python 2.7 3. The architecture detection code in the Makefile did not work correctly (checking for the 86 substring is true for both x86 as well as x86_64 targets). 4. I have renamed the clrmodule.il target in the Makefile to clrmodule_make.il. Otherwise a fresh SVN checkout would not build as clrmodule.il is already included. 5. Adapt the clrmod Makefile to support Mono 2.8 pkgconfig change. Additionally, retrieve Glib 2 options from its pkgconfig and compile the x86_64 build with -fPIC. 6. Support the standard DESTDIR parameter for the install target. Additionally, install Python.Runtime.dll and Python.Runtime.dll.config to the site-packages folder so it is found by the clr module.
If you have any comments or if there are any issues with these patches please let me know.
Philip
Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet
For what it's worth, I dug these patches out of the mailing list a month or so ago and had success running on a modern Ubuntu 64bit and some success with OSX.
-brad
On Aug 28, 2011, at 1:42 PM, Barton wrote:
First; thank you very much, Philip. Second; I apologize for letting this slip for so long. Somehow these patches sank low on my list. Then when I went to build on Fedora, I didn't make use of your very helpful and parallel work. I'll be applying patches and testing on Fedora FC15 in the very short term.
Thank you once again for your invaluable experience, Barton
On 05/04/2011 06:24 AM, Philip Lorenz wrote:
Hi,
after trying to compile Python for .NET on ArchLinux x86_64 I have run into several issues which the attached patches fix:
- Enable Mono config file loading. Otherwise a Python build with UCS4
Unicode strings does not work as the Mono.Posix module cannot find msvcrt (which is mapped to libc in Mono's config files). 2. Python.Runtime.dll.config is missing mappings for Python 2.7 3. The architecture detection code in the Makefile did not work correctly (checking for the 86 substring is true for both x86 as well as x86_64 targets). 4. I have renamed the clrmodule.il target in the Makefile to clrmodule_make.il. Otherwise a fresh SVN checkout would not build as clrmodule.il is already included. 5. Adapt the clrmod Makefile to support Mono 2.8 pkgconfig change. Additionally, retrieve Glib 2 options from its pkgconfig and compile the x86_64 build with -fPIC. 6. Support the standard DESTDIR parameter for the install target. Additionally, install Python.Runtime.dll and Python.Runtime.dll.config to the site-packages folder so it is found by the clr module.
If you have any comments or if there are any issues with these patches please let me know.
Philip
Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet
Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet
Thanks for the info Brad. Nice to have you on the list.
-Barton
On 08/28/2011 11:02 AM, Bradley Friedman wrote:
For what it's worth, I dug these patches out of the mailing list a month or so ago and had success running on a modern Ubuntu 64bit and some success with OSX.
-brad
On Aug 28, 2011, at 1:42 PM, Barton wrote:
So if git is producing your udiff files, does that mean that you are actually pulling from the clone that's on github?
That would explain why you didn't have the python2.7 mapping, anyway.
I (sort or) like the clrmodule_make.il input file name, but what to do for Windows folks?
I also like the DESTDIR parameter for the install target - and will commit that. Thanks again.
On 05/04/2011 06:24 AM, Philip Lorenz wrote:
Hi,
after trying to compile Python for .NET on ArchLinux x86_64 I have run into several issues which the attached patches fix:
- Enable Mono config file loading. Otherwise a Python build with UCS4
Unicode strings does not work as the Mono.Posix module cannot find msvcrt (which is mapped to libc in Mono's config files). 2. Python.Runtime.dll.config is missing mappings for Python 2.7 3. The architecture detection code in the Makefile did not work correctly (checking for the 86 substring is true for both x86 as well as x86_64 targets). 4. I have renamed the clrmodule.il target in the Makefile to clrmodule_make.il. Otherwise a fresh SVN checkout would not build as clrmodule.il is already included. 5. Adapt the clrmod Makefile to support Mono 2.8 pkgconfig change. Additionally, retrieve Glib 2 options from its pkgconfig and compile the x86_64 build with -fPIC. 6. Support the standard DESTDIR parameter for the install target. Additionally, install Python.Runtime.dll and Python.Runtime.dll.config to the site-packages folder so it is found by the clr module.
If you have any comments or if there are any issues with these patches please let me know.
Philip
Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet
Hi Barton,
On 08/29/2011 07:44 AM, Barton wrote:
So if git is producing your udiff files, does that mean that you are actually pulling from the clone that's on github?
I used the GIT-SVN bridge in order to create those patches. But may be something was wrong with my working copy.
I (sort or) like the clrmodule_make.il input file name, but what to do for Windows folks?
I haven't personally used the Makefile on Windows based systems (I always built Python.NET using the bundled Visual Studio Solution file). I don't know how exactly the Makefile would be invoked on Windows (is it a nmake compatible syntax?). A way to solve the issue could be to replace the "cp oldmodule.il clrmodule_make.il" statement in the else case with "copy clrmodule.il clrmodule_make.il".
Philip
Thanks, Philip, Nice to know that you're still around. All these build tool issues make me a little crazy. My background on on Windows, but I'm trying to divorce myself from the M$ platform. (I just adore my Fedora system) But things are still a little new to me on the Linux side. Now that I'm all set up with side-by-side build, and can serve my own SVN repo locally, I'll pull together all the contributions and finally commit to the VS2008 that I've been building with.
TWIMC: Interestingly, the github version has fully integrate nUnit integration (turns out a bit of this has leaked onto the trunk and broke my TestModule module). It makes me wonder if it's worth committing to the nUnit dependency..?
On 8/31/2011 8:15 AM, Philip Lorenz wrote:
Hi Barton,
On 08/29/2011 07:44 AM, Barton wrote:
So if git is producing your udiff files, does that mean that you are actually pulling from the clone that's on github?
I used the GIT-SVN bridge in order to create those patches. But may be something was wrong with my working copy.
I (sort or) like the clrmodule_make.il input file name, but what to do for Windows folks?
I haven't personally used the Makefile on Windows based systems (I always built Python.NET using the bundled Visual Studio Solution file). I don't know how exactly the Makefile would be invoked on Windows (is it a nmake compatible syntax?). A way to solve the issue could be to replace the "cp oldmodule.il clrmodule_make.il" statement in the else case with "copy clrmodule.il clrmodule_make.il".
Philip
participants (4)
-
Barton -
Barton
-
Bradley Friedman -
Philip Lorenz