Wölfischhttps://woelfisch.de/blog/2007-12-29T14:09:00+00:00Jörg's BlogThere are more Unixes than Ubuntu2007-12-29T14:09:00+00:00o'wolfhttps://woelfisch.de/blog/author/owolfhttps://woelfisch.de/blog/there-are-more-unixes-than-ubuntu<p>No rant about MacOS today, but a rant about software authors who apparently know nothing else than their favourite Linux distribution. I'm trying to get <a href="http://www.mapnik.org/">Mapnik</a> to work. They claim that it now works on MacOS. On 10.5, perhaps. On 10.4 you'll need a newer Python version. Not <em>at least</em> 2.4, but <em>exactly</em> 2.4. However, both Boost and Mapnik link against the system python version 2.3 and install in the directories of version 2.4.</p><p>To get it build the python bindings correctly:<blockquote><kbd>ln -sf /opt/local/bin/python2.4 /usr/bin/python<br/>ln -sf /opt/local/bin/pythonw2.4 /usr/bin/pythonw<br/>ln -sf /opt/local/Library/Frameworks/Python.framework/Versions/2.4 /System/Library/Frameworks/Python.framework/Versions/Current</kbd></blockquote></p><p>Next, Mapnik does not set the library name of <kbd>libmapnik.dylib</kbd> correctly:<blockquote><kbd>trochos:~ jreuter$ otool -L /opt/local/lib/libmapnik.dylib | head -2<br/>/opt/local/lib/libmapnik.dylib:<br/> src/libmapnik.dylib (compatibility version 0.0.0, current version 0.0.0)</kbd></blockquote><br/>Thus, even if it was in the library search path it doesn't get found as the loader would look for it in <kbd>$PREFIX/lib/src/libmapnik.dylib</kbd>. Solution: edit <kbd>src/SConscript</kbd> in the Mapnik source dir and change the linkflags definition for Darwin: <blockquote><kbd>if env['PLATFORM'] == 'Darwin':<br/> linkflags = '-Wl,-install_name,/opt/local/lib/libmapnik.dylib'<br/>else: # Linux and others<br/> linkflags = '-Wl,-rpath-link,. -Wl,-soname,libmapnik.so'</kbd></blockquote><br/>Of course, <kbd>/opt/local/lib/libmapnik.dylab</kbd> has to be changed to the actual destination path, for example by automatically constructing the path from PREFIX and DESTDIR.</p><p>Speaking about SCons: what a steaming pile of bovine excrements. It is supposed to be a build system that avoids the conceptual faults of <em>make</em>, however it isn't easier to learn, it is inconsistent. There is a target <em>install</em>, but not <em>clean</em>. For the latter I need a command line switch. It doesn't even clean properly, nobody using SCons apparently bothers to write an <em>uninstall</em> target. SCons sometimes rebuilds everything if just called with different defines, sometimes it doesn't do anything. It misses dependencies: I rebuild the python bindings of Mapnik, but <kbd>scons/scons install</kbd> does not replace the old version. Only after I remove it.</p><p>Mapnik needs some patches, too. This one hasn't been fixed in SVN for weeks now: There is a missing typecast in unicode.hpp, line 194. The second parameter of <kbd>iconv()</kbd> is a <kbd>const char **</kbd>, but it gets a <kbd>(const char *)*</kbd>, which isn't quite the same. Hence,<blockquote><kbd>iconv(desc_,(const char **)∈,&inleft,&out,&outleft);<br/> output = output.substr(0,output.size()-(outleft/sizeof(wchar_t)));</kbd></blockquote></p><p>To actually compile programs using Mapnik, the header files for <em>agg</em> have to be installed manually:<blockquote><kbd>cp agg/include/*h /opt/local/include/mapnik/</kbd></blockquote> Some programs call <kbd>freetype_engine::instance()->register_font("/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf");</kbd>, but the method <kbd>instance()</kbd> isn't present (anymore) in Mapnik. I uses fixed font paths internally anyway, I just commented it out.</p><p>Now everything compiles without errors, the library paths are correct, but Gpsdrive doesn't draw any streets, the Mapnik demo program aborts with <blockquote><kbd>terminate called after throwing an instance of 'std::bad_alloc'<br/> what(): St9bad_alloc</kbd></blockquote> and the python plugin doesn't work:<blockquote><kbd>trochos:~ jreuter$ python<br/>Python 2.4.4 (#1, Dec 28 2007, 18:46:04) <br/>[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin<br/>Type "help", "copyright", "credits" or "license" for more information.<br/>>>> from mapnik import *<br/>Traceback (most recent call last):<br/> File "<stdin>", line 1, in ?<br/> File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/mapnik/__init__.py", line 31, in ?<br/> from _mapnik import *<br/>TypeError: attribute name must be string<br/>>>> </kbd></blockquote></p><p>On a web page for a different project I found:<blockquote><em>If you get a TypeError: Attribute name must be string error when launching IPLT, you most probably have boost version 1.34 installed. This version is known to cause troubles. Unfortunately, there is no other fix than to install boost version 1.33 which is not in the MacPorts repository. You might want to read Installing Boost on MacOS X as a primer.</em></blockquote></p><p>Aaaaaaaaarggghhhhh!!!</p><p><strong>Edit:</strong> Building with Boost 1.33 makes the <kbd>std::bad_alloc</kbd> and the <kbd>TypeError</kbd> go away, but the the demo script and any python script using Mapnik just crashes with a segmentation fault. Building the demo script with <kbd>-DBOOST_SPIRIT_THREADSAFE</kbd> avoids the crash, but now it just runs in an infinite loop. I didn't bother to rebuild the python bindings. It's a waste of time.</p>MacOS X is so much better than, say, Linux, right?2007-12-21T09:11:00+00:00o'wolfhttps://woelfisch.de/blog/author/owolfhttps://woelfisch.de/blog/macos-x-is-so-much-better-than-say-linux-right<p>Apparently their scheduler isn't. I had an I/O and CPU intensive job running over night on the PowerBook. The system did not run out of memory. But it swapped out sshd, which resulted in the active SSH clients to time out with <em>server does not respond</em>. Which subsequently killed the running job. After six hours.</p><p>The next one bragging about how wonderful MacOS X is compared to Linux gets a hit with my PowerBook over the head. At least the hardware is solid.</p>Making MacOS X usable2007-11-27T19:49:00+00:00o'wolfhttps://woelfisch.de/blog/author/owolfhttps://woelfisch.de/blog/making-macos-x-usable<p>Luckily, MacOS X is based on some kind of BSD, in other words: it is a Unix system. It even comes with X11. However, as a desktop system many tools I like and need aren't present. I already had an ancient version of Darwinports running since 10.2. That old installation was terribly broken, though, and almost nothing compiled anymore on 10.4. Thus, I removed it and started again. There are several alternatives available, two of them being based on (Free)BSD ports, and one on Debian packaging. </p><p><h3>Fink</h3><br/>You think Debian <stroke>Stale</stroke>Stable is old? Wait till you see Fink. With every new version of MacOS X a new version of Fink comes out, but apparently based on a very old version of Debian. Virtually no updates are available in between. No, I'm not going to upgrade to 10.5 just to get a slightly newer version of Fink. It won't perform very well on my PowerBook G4 anyway. At least they provide binary packages. However, those were far too old to compile gspdrive.</p><p><h3>Gentoo</h3><br/>Yes, there is a version of Gentoo available for MacOS X. The description on how to bootstrap it is very good, with only one minor issue (I think it is the automake-wrapper package that has to get selected by prepending the port category.) It is a bit annoying, though, that you have to compile the same packages from the system selection three times during bootstrap. Yes, that is a design concept of Gentoo, however on a 1 GHz PPC system with only 512 MB RAM and a 2,5" laptop disk drive quite unnerving. </p><p>Everything works well until you have want to compile an X11 application. Some required X11 libraries (that aren't even provided by the system X11) are masked and I wasn't able to unmask them. At least not by following the documentation of <em>emerge</em>. Apparently, it doesn't work with prefixed portage. What a pity, Gentoo has the most current packages of all three solutions.</p><p><h3>Macports</h3><br/>Macports is the new name of Darwinports after the Darwin project close down. It works very well, if you know that you need to have the most current version of Apple's XCode, including the X11 SDK, and should have the last update of X11 for 10.4. Additionally, whatever you do: be very careful to avoid the installation of Macport's on libX11. The port is not complete, for example libXext is missing. Some X11 applications may work, but others are linked to both MacOS' native and Macports onw X11 libraries. You will get a NULL pointer dereference in libX11 called from libXext on start of those programs. It took me two days to find out what's wrong. Install only the x11/xorg-proto packages (those are safe)</p><p>What is missing indeed is some meta-package for X11 which provides the appropriate pgk-config definition files for the non-proto elements of the native X11 installation. These should have been provided by Apple, but unfortunately aren't. Apple's X11 is quite outdated anyway (it already was when Tiger was released), expect to manually install some newer versions of libXcursor and libXfixes.</p><p>Thanks to Macports I now have all my favourite tools back, including konversation and gpsdrive.</p>