Summary: | sci-geosciences/mapnik-0.7.1-r1: missing dependencies | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Robin Johnson <robbat2> |
Component: | New packages | Assignee: | Steve Arnold <nerdboy> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Robin Johnson
2011-06-08 00:16:18 UTC
Cool, you have just a previously reported and unreproducible bug, and now *you* get to help track it down. Since I get no such errors on either amd64 or x86, can you please provide some additional system info and anything else you think might be relevant?
Note that I do *not* have mod_python installed, so the only thing I can think of is that somehow scons is doing something different. I'll have to check, but I don't think the previous bug had any gdal symbol issues, but that's also something you shouldn't have. Can you do an ldd -r on libgdal.so and see if anything looks funky?
I just built it again, now against python 2.7, and still with no errors:
...
x86_64-pc-linux-gnu-g++ -o utils/shapeindex/shapeindex -pthread utils/shapeindex/shapeindex.o src/envelope.o plugins/input/shape/shapefile.o -Lsrc -L/usr/lib64 -L/usr/lib -L/usr/lib64/boost-1_46 -L/usr/lib64/postgresql-9.0/lib64 -lboost_program_options -lboost_iostreams -lboost_filesystem -lboost_system
scons: done building targets.
>>> Source compiled.
[ebuild R ] sci-geosciences/mapnik-0.7.1-r1 USE="cairo curl doc gdal postgres python sqlite -debug" 0 kB [1]
[ebuild R ] sci-libs/gdal-1.8.0-r1 USE="aux_xml curl fits geos gif gml hdf5 jpeg jpeg2k mysql netcdf ogdi pdf perl png postgres python ruby sqlite threads -debug -doc -ecwj2k -odbc" RUBY_TARGETS="ruby18" 0 kB
The above gdal USE flags should produce this:
$ ldd -r /usr/lib64/libgdal.so.1
linux-vdso.so.1 => (0x00007fff418fb000)
libpoppler.so.13 => /usr/lib64/libpoppler.so.13 (0x00007f342671c000)
libgeos_c.so.1 => /usr/lib64/libgeos_c.so.1 (0x00007f34264fd000)
libsqlite3.so.0 => /usr/lib64/libsqlite3.so.0 (0x00007f3426260000)
libexpat.so.1 => /usr/lib64/libexpat.so.1 (0x00007f3426037000)
libjasper.so.1 => /usr/lib64/libjasper.so.1 (0x00007f3425ddd000)
libhdf5.so.7 => /usr/lib64/libhdf5.so.7 (0x00007f342592e000)
libogdi.so.3 => /usr/lib64/libogdi.so.3 (0x00007f342570b000)
libgif.so.4 => /usr/lib64/libgif.so.4 (0x00007f3425501000)
libjpeg.so.8 => /usr/lib64/libjpeg.so.8 (0x00007f34252c5000)
libgeotiff.so.2 => /usr/lib64/libgeotiff.so.2 (0x00007f3425093000)
libtiff.so.5 => /usr/lib64/libtiff.so.5 (0x00007f3424e21000)
libpng14.so.14 => /usr/lib64/libpng14.so.14 (0x00007f3424bf9000)
libnetcdf.so.6 => /usr/lib64/libnetcdf.so.6 (0x00007f34248b0000)
libcfitsio.so.3 => /usr/lib64/libcfitsio.so.3 (0x00007f34244f3000)
libpq.so.5 => /usr/lib64/libpq.so.5 (0x00007f34242c9000)
libz.so.1 => /lib64/libz.so.1 (0x00007f3424077000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3423e5a000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f3423c55000)
libcurl.so.4 => /usr/lib64/libcurl.so.4 (0x00007f34239fc000)
libmysqlclient.so.16 => /usr/lib64/libmysqlclient.so.16 (0x00007f3423678000)
libm.so.6 => /lib64/libm.so.6 (0x00007f34233f6000)
libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.2/libstdc++.so.6 (0x00007f34230ee000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f3422ed8000)
libc.so.6 => /lib64/libc.so.6 (0x00007f3422b6f000)
libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x00007f34228d6000)
libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x00007f34226a0000)
libopenjpeg.so.1.4 => /usr/lib64/libopenjpeg.so.1.4 (0x00007f342247f000)
liblcms.so.1 => /usr/lib64/liblcms.so.1 (0x00007f3422246000)
libgeos-3.2.2.so => /usr/lib64/libgeos-3.2.2.so (0x00007f3421ece000)
libsz.so.2 => /usr/lib64/libsz.so.2 (0x00007f3421cb9000)
libmpich.so.3 => /usr/lib64/libmpich.so.3 (0x00007f34218d0000)
libmpl.so.1 => /usr/lib64/libmpl.so.1 (0x00007f34216cb000)
libproj.so.0 => /usr/lib64/libproj.so.0 (0x00007f3421485000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x00007f3421145000)
liblzma.so.5 => /usr/lib64/liblzma.so.5 (0x00007f3420f22000)
libjbig.so => /usr/lib64/libjbig.so (0x00007f3420d15000)
libhdf5_hl.so.7 => /usr/lib64/libhdf5_hl.so.7 (0x00007f3420ae7000)
libssl.so.1.0.0 => /usr/lib64/libssl.so.1.0.0 (0x00007f342088a000)
libcrypto.so.1.0.0 => /usr/lib64/libcrypto.so.1.0.0 (0x00007f34204dc000)
libldap_r-2.4.so.2 => /usr/lib64/libldap_r-2.4.so.2 (0x00007f342028d000)
/lib64/ld-linux-x86-64.so.2 (0x00007f3427585000)
libldap-2.4.so.2 => /usr/lib64/libldap-2.4.so.2 (0x00007f3420045000)
liblber-2.4.so.2 => /usr/lib64/liblber-2.4.so.2 (0x00007f341fe36000)
libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00007f341fc1b000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f341f9e3000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f341f7cc000)
libgnutls.so.26 => /usr/lib64/libgnutls.so.26 (0x00007f341f520000)
libtasn1.so.3 => /usr/lib64/libtasn1.so.3 (0x00007f341f30e000)
libgcrypt.so.11 => /usr/lib64/libgcrypt.so.11 (0x00007f341f094000)
libgpg-error.so.0 => /usr/lib64/libgpg-error.so.0 (0x00007f341ee90000)
librt.so.1 => /lib64/librt.so.1 (0x00007f341ec86000)
libssl3.so => /usr/lib64/libssl3.so (0x00007f341ea4c000)
libsmime3.so => /usr/lib64/libsmime3.so (0x00007f341e81e000)
libnssutil3.so => /usr/lib64/libnssutil3.so (0x00007f341e5fd000)
libnss3.so => /usr/lib64/libnss3.so (0x00007f341e2cf000)
libplds4.so => /usr/lib64/libplds4.so (0x00007f341e0cb000)
libplc4.so => /usr/lib64/libplc4.so (0x00007f341dec5000)
libnspr4.so => /usr/lib64/libnspr4.so (0x00007f341dc87000)
libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x00007f341da68000)
libXau.so.6 => /usr/lib64/libXau.so.6 (0x00007f341d863000)
libXdmcp.so.6 => /usr/lib64/libXdmcp.so.6 (0x00007f341d65d000)
Looks like it should really have pycairo as a dep, at least with USE=python so please make sure you have that installed (fixed in my overlay). The only workaround I could see for this is removing the "|| die" after the epydoc script. According the the upstream devs (who didn't seem to want a bug on this) the inconsistent mod_python failure shouldn't be a problem if it occurs, and there's nothing in the epydoc script for us to fix on our end. Maybe they'll fix it before the next release, which is coming in the next month or two. One can always hope... Oh, and please try the updated ebuild and make sure it doesn't have a hard failure; I couldn't even reproduce this on my son's box without mod_python. |