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)
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'
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'and the python plugin doesn't work:
what(): St9bad_alloc
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.
Comments
megadog.livejournal.com 16 years, 10 months ago
You are trapped in a maze of twisty little libraries, none of them compatible.
Been there myself on plenty of occasions, though thankfully it's rather less of a problem in the sort of industrial/commercial production environments I inhabit [which change little from month to month and even then only because the latest release of Oracle requires some patches] and Sun's Solaris.
Link | Replylynard-.livejournal.com 16 years, 10 months ago
Reading that it gives me the feeling that M$ has injected some of its problems into Linux.... It is a sad thing though
Link | ReplyNew Comment