|« Text searching files with known extensions||Simple Python example programs with explanations »|
Compiling omniORB 4.1.5 and omniORBpy 3.5 with Python 2.7January 24th, 2011
Python 2.7 (final) was released on 3rd July 2010, which is almost half a year ago. One of the awful things about Python is that major releases are not compatible with each other. That is the extension modules compiled against Python 2.6 do not play nicely with the extension modules compiled against Python 2.7. The upshot of this, is that if you want to upgrade your version of Python you have to hunt around looking for extension modules compiled against your new version. In spite of Python 2.7 being 7 months old (1 year + 1 month if you count back to the release of Python 2.7 alpha 1), there isn’t as much extension module support as you’d expect; you still have to hunt and most of it is on unofficial websites i.e. not in the download pages of its project.
One such project is the CORBA implementation omniORB. It’s download pages only contain the Python 2.6 version. While I can use
./configure to build projects under unix with ease the building of omniORBpy under windows was much more troublesome. I can see why no one has attempted it thus far.
So for all you lucky people out there here is how you do it.
You need to have Python installed but you probably have that already so I’m not going to talk about that here.
Firstly we must create a directory to download our source software into:
The latest one is
openssl-0.9.8k_WIN32 (at the time of writing).
Unpack them all into
C:\python-modules so that we have three folders
omniORBpy-3.5 needs to be in a special place to move it to
C:\python-modules\omniORB-4.1.5\src\lib\omniORBpy (removing the version number from the end of the directory name).
The build process needs Cygwin which I already had installed. I tried to use it in the build but it didn’t work, the “make” just hung. So I just stuck to the instructions and used omniORB’s cut-down version. You can download this from http://omniorb.sourceforge.net/att_packages/gnu-win32-lite.zip and unpack it into
Now that we have all the software downloaded, we can start configuring the build.
C:\python-modules\omniORB-4.1.5\config\config.mk and uncomment the platform you are using in my case it is
Next load the platform specific file from
C:\python-modules\omniORB-4.1.5\mk\platforms\x86_win32_vs_9.mk. As we will be building in a Cygwin environment, we need to specify paths in Cygwin format. Change the variable
PYTHON to point to the correct location of the Python executable. In my case I have Python 2.7 installed (but anything above Python 1.5 is fine)
PYTHON = /cygdrive/c/Python27/python
OpenSSL transport support is disabled by default because you need the Open SSL libraries which we have now so uncomment the OPEN_SSL_ROOT location. The path has to be a relative path. I tried all combinations of windows-style full paths and cygwin-style full paths and none of them worked. “make clean” doesn’t reset the build like it should do So if there is a problem during the build you have to unpack the sources from the zips again to create a fresh source tree. Set the ssl root to:
OPEN_SSL_ROOT = ../../../../../../openssl-0.9.8k_WIN32
which is a relative reference to
Now that we are configured we can actually start the build.
Open a command window and add
c:\gnuwin32 to the start of your path:
Run the visual studio batch file to set up the build environment:
“C:\Program Files\Microsoft Visual Studio 9.0\VC\vcvarsall.bat”
Not quite sure what this does but you need it. I think it has something to do with translating cygwin paths to windows paths
Change to the omniORB source directory and run the build:
The build of omniORB will take about 30 minutes.
The build of omniORBpy will take about 3 minutes.
Once the build has finished you need to create a module extension package so that you can give it to other people so they don’t have to go through all the hassle of downloading and compiling it all up.
The pre-built omniORBpy using Python 2.6 resident on SourceForge has a problem which means you need to adjust your
PYTHONPATH and your actual
PATH in order to use it. I use Clearcase which has everything on different drives so having to hard code drive letters made it almost impossible to use in a shared environment. Fear not I have done the 2 hours of reading really boring documentation so you don’t have to and constructed a omniORBpy 3.5 (omniORB 4.1.5) with Python 2.7 module extension that doesn’t require you to update your
PYTHONPATH by making use of the site pth features and the nugget of information I found buried on a forum that said that a pyd (Python dynamic library) would pick up DLLs from the same directory it lived in automatically.
Unfortunately the build system is not set up enough so that you can make an installable deliverable to give out like you get with some projects (for example lxml). This means you have to do it by hand and it’s a real pain in the arse!
I’ve written a program to make the omniORBpy extension placing everything in the right place. It’s a bit rough but it works. You can download it from here:
Well, thanks for reading all the way to the end (if you did!) and your prize is omniORBpy 3.5 with omniORB 4.1.5 binding using Python 2.7.1. Enjoy.
- Download http://www.bigsoft.co.uk/blog_images/omniORBpy-3.5.win32-py2.7.zip
You will also have to compile against a 64-bit version of Python as well as 64-bit versions of the supporting libraries. You will probably be able to find most of these yourself.
As 64-bit OS's become more prevalent software and documentation support will get better, but currently projects like these run much slower than reality. Be patient or lend a hand!
Thanks as-well to have updated the link. This is the kind of integration i would like to have found on the omniorb site.
having problem in configuration