Most (commercial) linux distributions install their x86_64 version as a mixed environment. This means that the 64 bit libraries are installed in /lib64 and /usr/lib64, while the usual directories /lib and /usr/lib contain 32 bit libraries which are necessary to run 32 bit applications.
Debian, on the other hand, provides a pure x86_64 distribution (the amd64 port), where the 64 bit libraries are installed in /lib and /usr/lib. 32 bit libraries are either installed below /emul (through the ia32-libs package) or in a completely separate chroot environment. The chroot environment has the advantage that it uses the normal i386 packages and can even be updated with "apt-get dist-upgrade" separately from the 64 bit installation.
32 bit applications like OpenOffice run very well in the chroot environment, and even building i386 packages is possible. The only disadvantage is that the chroot environment can take up a significant amount of space.
The real problems arise if you need to install a 64 bit application which uses an installer which is built as 32 bit application. No one does this? Sure. Oracle does.
And they require a mixed installation. There seems currently no way to install the Oracle client on an amd64 debian installation.
I started to debug korganizer this evening, because the exchange plugin added appointments downloaded from an Exchange server one hour too early. After building kdepim from the debian source package, the first thing I learned is how to debug plugins (see KDE developers FAQ) (thanks, Mirko):
KDE searches its libraries in $KDEDIR/lib and in the lib directory of all the components of $KDEDIRS. So, while you are still developing your library and don't want to install it, you can use this trick:
- cd to your development directory, the one where your library is built.
- Set up KDEDIRS so that it include your development directory: export KDEDIRS=`pwd`:$KDEDIR
- Create a pseudo lib directory where KDE should find your component: ln -s .libs lib
- Run kbuildsycoca to inform KDE that it KDEDIRS has changed.
Now, KDE should find your library when using KTrader or KLibLoader.
This worked perfectly, and after some time of debugging I found the reason for the problem: libkpimexchange/core/utils.cpp contains the functin utcAsZone() which returns the local time for a given UTC time and time zone. The time zone is passed as id in the form "Country/City", like "Europe/Berlin". Inside this function, the function icaltimezone_get_builtin_timezone_from_tzid() from the ical library is called which shall return a time zone structure by its id. However, this function does something different: it expects the passed string to be in a specific format (it has to start with the prefix "/softwarestudio.org/", for example) and extracts the time zone id from this string. So, of course, it could never find a matching time zone...
The fix seems to be quite simple: just use icaltimezone_get_builtin_timezone() instead, which directly works on the "Country/City" format. Then, downloading appointments from the exchange server works well again.
I checked in the KDE svn repository: The very same fix has already been committed about two weeks ago :-)
After I came across the Haskell programming language three times today (twice while scanning the latest debian-devel postings, and later again while searching for some documentation about the python distutils package) I had a closer look at it. Other than wide spread languages like C++, Java or Python, which are imperative languages, Haskell is a functional language (until know, I thought that these are those languages which are rarely used in practical programming because they are too complicated... I am curious if Haskell can argue the converse ;-) ) The introduction at the start page looks quite interesting, at least the implementation of the quicksort algorithm is much shorter in Haskell than in C.
For the new year, I had the intention to write blog entries more regularly, but currently I don't see any improvement yet ;-)
Well, the new AMD64 system is running quite good, it sometimes looses the mouse after booting (i.e. the pointer simply is simply frozen), but this could be a problem with a conflict of the ehci_hcd USB kernel module. Some hints suggest to load it directly at boot time instead of automatically when it is needed during the boot process.
Apart of that, I continue to collect a list of applications which are not yet available as 64 bit version, among them are the RealPlayer (the helix-player is available but crashes) and the Adobe Acrobat Reader. Hopefully this situation will get better soon...