There are more Unixes than Ubuntu

Posted by: o'wolf 16 years, 3 months ago

(2 comments)

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 Mapnik 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 at least 2.4, but exactly 2.4. However, both Boost and Mapnik link against the system python version 2.3 and install in the directories of version 2.4.

To get it build the python bindings correctly:

ln -sf /opt/local/bin/python2.4 /usr/bin/python
ln -sf /opt/local/bin/pythonw2.4 /usr/bin/pythonw
ln -sf /opt/local/Library/Frameworks/Python.framework/Versions/2.4 /System/Library/Frameworks/Python.framework/Versions/Current

Next, Mapnik does not set the library name of libmapnik.dylib correctly:

trochos:~ jreuter$ otool -L /opt/local/lib/libmapnik.dylib | head -2
/opt/local/lib/libmapnik.dylib:
src/libmapnik.dylib (compatibility version 0.0.0, current version 0.0.0)

Thus, even if it was in the library search path it doesn't get found as the loader would look for it in $PREFIX/lib/src/libmapnik.dylib. Solution: edit src/SConscript in the Mapnik source dir and change the linkflags definition for Darwin:

if env['PLATFORM'] == 'Darwin':
  linkflags = '-Wl,-install_name,/opt/local/lib/libmapnik.dylib'
else: # Linux and others
  linkflags = '-Wl,-rpath-link,. -Wl,-soname,libmapnik.so'

Of course, /opt/local/lib/libmapnik.dylab has to be changed to the actual destination path, for example by automatically constructing the path from PREFIX and DESTDIR.

Speaking about SCons: what a steaming pile of bovine excrements. It is supposed to be a build system that avoids the conceptual faults of make, however it isn't easier to learn, it is inconsistent. There is a target install, but not clean. For the latter I need a command line switch. It doesn't even clean properly, nobody using SCons apparently bothers to write an uninstall 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 scons/scons install does not replace the old version. Only after I remove it.

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 iconv() is a const char **, but it gets a (const char *)*, which isn't quite the same. Hence,

iconv(desc_,(const char **)&in,&inleft,&out,&outleft);
output = output.substr(0,output.size()-(outleft/sizeof(wchar_t)));

To actually compile programs using Mapnik, the header files for agg have to be installed manually:

cp agg/include/*h /opt/local/include/mapnik/

Some programs call freetype_engine::instance()->register_font("/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf");, but the method instance() isn't present (anymore) in Mapnik. I uses fixed font paths internally anyway, I just commented it out.

Now everything compiles without errors, the library paths are correct, but Gpsdrive doesn't draw any streets, the Mapnik demo program aborts with

terminate called after throwing an instance of 'std::bad_alloc'
what(): St9bad_alloc

and the python plugin doesn't work:

trochos:~ jreuter$ python
Python 2.4.4 (#1, Dec 28 2007, 18:46:04)
[GCC 4.0.1 (Apple Computer, Inc. build 5370)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from mapnik import *
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/opt/local/Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/mapnik/__init__.py", line 31, in ?
from _mapnik import *
TypeError: attribute name must be string
>>>

On a web page for a different project I found:

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.

Aaaaaaaaarggghhhhh!!!

Edit: Building with Boost 1.33 makes the std::bad_alloc and the TypeError go away, but the the demo script and any python script using Mapnik just crashes with a segmentation fault. Building the demo script with -DBOOST_SPIRIT_THREADSAFE 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.

• Tags:
• gps
• mac
• wtf?!

• ← MacOS X is so much better than, say, Linux, right?
• Holy sh... →