Trained Monkey Hacking Experience

Monday, September 14, 2009

DJGPP crosscompiler for DOS in openSUSE build service

In case you need to build some binaries for some kind of DOS based bootstrap process, don't look far, the repository home:fstrba:msdos has all you need. A gcc-4.3.4 based cross-compiler for C and C++ along with the CVS HEAD version of DJGPP headers and libraries. The resulting executables running under DOS need a DPMI implementation like this one in the same directory to run.

When/If I have time, I will try to extend it to different languages supported by gcc.

Taste it and enjoy how sweet it is.

Tuesday, June 09, 2009

Contacts for Windows

Yesterday, I saw a nice little application landing its first release on ftp.gnome.org. Its name is contacts. As I love challenges, I spent some time in my evening porting it to Windows®. You can see the result here.

It has a very basic user interface and I had to disable the bacon stuff, because I did not manage to finish its port, but it basically works and interacts with your local evolution address-book. Read and write.

Tuesday, May 05, 2009

When the rules apply only to some of us

It is normally a rule for the community not to do any big and potentially risky changes in OpenOffice.org months before release. UI-freeze, feature-freeze are dates that if you miss them, your feature or fix will have to wait for the next release, or eventually for OOoLater tag. This is always true ...

... unless you are not the community member, but Sun employee. In that case, the rule starts to be a more flexible one.

To cut the thing short, if you are community member and are building ooo310-m11 with Windows and cygwin (and maybe only with Visual Studio 9, which is what Sun uses), you will realize that something changed and your build will consistently crash in the python module. The binary that will crash is the vcbuild.exe binary. What happened? Just our friends from Sun upgraded the python version of OpenOffice.org from 2.3.4 to 2.6.1 between release candidate 1 and release candidate 2. Theoretically, only show-stopper fixes are allowed in the RC phase, but since the rule is flexible depending on which side you are sitting, this could happen.

So, if you are on the wrong side of the flexibility, here is what can bail you out:

--- python/makefile.mk 2009-05-05 08:58:50.745625000 +0200 +++ python/makefile.mk 2009-05-05 08:59:45.261250000 +0200 @@ -117,11 +117,7 @@ # Build python executable and then runs a minimal script. Running the minimal script # ensures that certain *.pyc files are generated which would otherwise be created on # solver during registration in insetoo_native -.IF $(SYSBASE) != "" -BUILD_ACTION=$(COMPATH)$/vcpackages$/vcbuild.exe -useenv pcbuild.sln "Release|Win32" -.ELSE BUILD_ACTION=$(COMPATH)$/vcpackages$/vcbuild.exe pcbuild.sln "Release|Win32" -.ENDIF # $(SYSBASE) != "" .ENDIF .ENDIF

But given the way this was rushed through, don't be surprised if you have other problems later.

BTW, it is not like this problem was not known about beforehand.

Game, set, match for "Quality through process" approach.

UPDATE:

As pointed out on IRC, it is true that many people worked hard to make this - as agreed necessary - change possible at the late stage. I did not intend to offend them and stand to be corrected. The point here is that such changes are pretty risky at the late stage of release cycle especially because upstream does not use the same build environment as community. In the times where I was still bothering to push updates for libwpd upstream, I was often a victim of many procedural hickups. So, seeing a fast-track risky change in last moment is reminding me of all the hours fighting the bureaucracy. But, again, not intending to offend anybody.

Tuesday, April 28, 2009

HUNDRED (packages in windows:mingw:win32)

It has been long time since I blogged for the last time and quite things changed since: My daughter and my son took one more year and my wife is every day more beautiful and younger.

It is not that I was not having things to blog about, but the main quality of many FOSS hackers, lazyness, is the reason of this relative quietness. But now there is something really really cool that pushes me to blog again: At the end of 2008 and in the beginning of 2009 I was trying to come up with a repeatable and dependable way to build GTK+ and GNOME software for Windows.

I, myself, maintain several libraries and I build their Win32 versions on my Linux box as I described it here. So, the cross-compilation came as a natural reflex. I inspired myself by the infrastructure that the Fedora mingw project used and started to go through the usual cycle of while (!tired()) { build(); debug; }. And last night, I reached a milestone. My package repository hosted by openSUSE Build Service received its package number hundred.

Why am I saying all this? In fact, these packages are not only there to be a decoration. Many times, people that know about my work ask me for packages of different libraries. All the stuff that I build (or almost all can be found there). People asking for win32 version of the GTK+ port of Webkit can be interested in the mingw32-libwebkit package. Those that would gladly try to use Evolution as their mail client on windows, can find the updated mingw32-evolution package useful. It is enough to add the repository to your installation sources and lauch zypper ref; zypper in mingw32-evolution mingw32-tango-icon-theme and the rpm dependency resolution mechanism will pull all you need for you. After that, you can just zip the content of /usr/i686-pc-mingw32/sys-root/mingw directory and you can unzip the resulting package on your windows box. As simple as that!

For developpers that would like to cherry-pick packages and use them to develop their own, it is the best to to fetch them from the openSUSE 10.3 version of the repository. For later releases, openSUSE's rpm uses lzma payload and it can be a bit more tricky to uncompress the packages on a typical windows machine, although 7zip should know what to do with them, I guess.

As a technical information for developpers, all the binaries are stripped of unnecessary sections and the debugging information can be found for each source package in a separate package typically named mingw32-%{name}-debug-%{version}-%{release}.noarch.rpm. Uncompressing them in the same prefix as the corresponding binary packages will cause gdb.exe to use their symbols and you can produce meaningfull traces.

I still contend that the best way to use those packages for developping your own software is in an openSUSE installation. And the side benefit is that in this way one gets not only nice development environment for Windows development, but also the arguably best operating system in the world as a host.

I might take some more courage and write about Windows porting of software when I rest from writing this blog entry. While waiting, it is worth to read this little collection of slides of my distinguished colleague and incontested master of win32 porting, Tor Lillqvist. Everything I know about win32 is because of sitting at his feet.