I'm working on the gdal and related stuff, and I'd like some confirmation that it builds/runs on the arches I don't have access to (I can currently test on x86 and sparc). The gdal tools can be used to confirm images can be converted; I guess I should have some test images at some point, but at least I'm getting some user-feedback (which is a good thing). Thanks in advance...
sci-libs/gdal: alpha, amd64, hppa, ppc, sparc sci-libs/libgeotiff: alpha, amd64, hppa, mips, ppc, ppc64, sparc sci-libs/ogdi: alpha, amd64, hppa, ppc, ppc64, sparc CCing arches that have keywords for these ebuilds...
Sorry, forgot about proj...
nerdboy: assign arch-testing bugs to yourself and cc relevent archs (as you have done) reassigning
Removing SPARC as nerdboy already took care of us.
gdal: added ~ppc64, will get stable in 30 days of testing period. libgeotiff/ogdi: stable on ppc64
gdal, libgeotiff & ogdi ppc stable
ogdi fails here: Making shared library: /var/tmp/portage/ogdi-3.1.4/work/ogdi-3.1.4/bin/linux/libogdi31.so gcc -shared -O -o /var/tmp/portage/ogdi-3.1.4/work/ogdi-3.1.4/bin/linux/libogdi31.so ecs_dyna.o ecsregex.o ecssplit.o ecsassoc.o ecshash.o ecstile.o server.o ecsdist.o ecslist.o ecsinfo.o ecsgeo.o ecs_xdr.o ecs_xdrz.o gmath.o client.o ecs_capabilities.o -ldl -L/var/tmp/portage/ogdi-3.1.4/work/ogdi-3.1.4/bin/linux -lzlib_ogdi31 -L/var/tmp/portage/ogdi-3.1.4/work/ogdi-3.1.4/bin/linux -lexpat_ogdi31 -L/var/tmp/portage/ogdi-3.1.4/work/ogdi-3.1.4/lib/linux/static -lproj -lm /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.4/../../../../x86_64-pc-linux-gnu/bin/ld: errno: TLS definition in /lib64/libc.so.6 section .tbss mismatches non-TLS reference in /var/tmp/portage/ogdi-3.1.4/work/ogdi-3.1.4/lib/linux/static/libproj.a(pj_init.o) /lib64/libc.so.6: could not read symbols: Bad value collect2: ld returned 1 exit status make[3]: *** [/var/tmp/portage/ogdi-3.1.4/work/ogdi-3.1.4/bin/linux/libogdi31.so] Error 1 make[3]: Leaving directory `/var/tmp/portage/ogdi-3.1.4/work/ogdi-3.1.4/ogdi/c-api/OBJ.linux' make[2]: *** [all] Error 2 make[2]: Leaving directory `/var/tmp/portage/ogdi-3.1.4/work/ogdi-3.1.4/ogdi/c-api' make[1]: *** [c-api] Error 2 make[1]: Leaving directory `/var/tmp/portage/ogdi-3.1.4/work/ogdi-3.1.4/ogdi' make: *** [ogdi] Error 2 !!! ERROR: sci-libs/ogdi-3.1.4 failed. !!! Function src_compile, Line 25, Exitcode 2 !!! make failed
Is that the same TLS bug that bit some other packages (gossip was one, I think)? Or do you think it's a 64-bit glitch?
i don't think it's related to ogdi, although i must admit that it's the first time i see such an error message. perhaps another amd64-dev can test it?
Simon, if this is still a problem for you, after trying the just-now updated ogdi ebuilds, please file a new bug on it. Other arch-devs (other than x86 and sparc) please test and make sure all the libs get properly installed (thanks). You should have the following after a successful build: qpkg -l ogdi sci-libs/ogdi-3.1.5 * CONTENTS: /usr /usr/bin /usr/bin/example1 /usr/bin/example2 /usr/bin/gltpd /usr/bin/ogdi_import /usr/bin/ogdi_info /usr/include /usr/include/ecs.h /usr/include/ecs_util.h /usr/lib /usr/lib/libadrg.so /usr/lib/libdtcanada.so /usr/lib/libdted.so /usr/lib/libdtusa.so /usr/lib/libogdi31.so /usr/lib/libremote.so /usr/lib/librpf.so /usr/lib/libskeleton.so /usr/lib/libvrf.so /usr/lib/libogdi.so -> /usr/lib/libogdi31.so 1122756708 /usr/share /usr/share/doc /usr/share/doc/ogdi-3.1.5 /usr/share/doc/ogdi-3.1.5/ChangeLog.gz /usr/share/doc/ogdi-3.1.5/LICENSE.gz /usr/share/doc/ogdi-3.1.5/NEWS.gz /usr/share/doc/ogdi-3.1.5/README.gz /usr/share/doc/ogdi-3.1.5/VERSION.gz
the link from libogdi31.so to libogdi.so cannot be created (running on ppc64): [...] >>> Install ogdi-3.1.5 into /var/tmp/portage/ogdi-3.1.5/image/ category sci-libs ln: creating symbolic link `/var/tmp/portage/ogdi-3.1.5/image//usr/lib/libogdi.so' to `/usr/lib/libogdi31.so': No such file or directory man: [...] # qpkg -l ogdi sci-libs/ogdi-3.1.5 * CONTENTS: /usr /usr/bin /usr/bin/example1 /usr/bin/example2 /usr/bin/gltpd /usr/bin/ogdi_import /usr/bin/ogdi_info /usr/include /usr/include/ecs.h /usr/include/ecs_util.h /usr/lib64 /usr/lib64/libadrg.so /usr/lib64/libdtcanada.so /usr/lib64/libdted.so /usr/lib64/libdtusa.so /usr/lib64/libogdi31.so /usr/lib64/libremote.so /usr/lib64/librpf.so /usr/lib64/libskeleton.so /usr/lib64/libvrf.so /usr/share /usr/share/doc /usr/share/doc/ogdi-3.1.5 /usr/share/doc/ogdi-3.1.5/ChangeLog.gz /usr/share/doc/ogdi-3.1.5/LICENSE.gz /usr/share/doc/ogdi-3.1.5/NEWS.gz /usr/share/doc/ogdi-3.1.5/README.gz /usr/share/doc/ogdi-3.1.5/VERSION.gz
while ogdi now compiles and installs fine, i've some troubles with gdal: ./install-sh -d /usr/lib64 for f in ./libgdal.la ; do /bin/sh ./libtool --mode=install ./install-sh -c $f /usr/lib64 ; done ./install-sh -c ./.libs/libgdal.so.1.7.0 /usr/lib64/libgdal.so.1.7.0 ACCESS DENIED open_wr: /usr/lib64/#inst.26103# cp: cannot create regular file `/usr/lib64/#inst.26103#': Permission denied make: *** [install-lib] Error 1 man: >>> Completed installing gdal-1.2.6-r2 into /var/tmp/portage/gdal-1.2.6-r2/image/ --------------------------- ACCESS VIOLATION SUMMARY --------------------------- LOG FILE = "/tmp/sandbox-sci-libs_-_gdal-1.2.6-r2-25938.log" open_wr: /usr/lib64/#inst.26103# -------------------------------------------------------------------------------- This is when i try to make it install libraries to /usr/$(get_libdir) instead of /usr/lib, and I'd rather mark it not stable as long as it installs its libraries to /usr/lib
Markus, please sync up and try the new ogdi ebuild; Simon, I'm working on a new gdal with hopefully enough configure options to make it behave.
Steve and Simon: I already added a fix to gdal to fix the multilib issue, sorry hadn't read the bug report recently. Steve: I have another prob with ogdi checking for -shared ... no(1) checking for ld -shared ... yes checking how to run the C preprocessor... gcc -E checking for rpc/pmap_clnt.h... yes checking for float.h... yes checking for dlfcn.h... yes checking whether byte ordering is bigendian... no checking for /usr/include/projects.h ... found configure: error: Unable to find /usr/lib/libproj.{so,a} Note libproj is installed in /usr/lib64 not in /usr/lib. I added a fix for this last night: -econf --with-proj=/usr --with-projlib="-L/usr/lib -lproj" \ +econf --with-projlib="-L/usr/$(get_libdir) -lproj" \ but that got removed in your last commit, any reason?
ogdi-3.1.5-r1 installs the sym link correct on ppc64 now.
Okay, both ogdi and gdal should be fixed up and ready for more arch testing. If you find more bugs, feel free to file a new bug report on specific issues. Thanks for your support; everyone gets a cookie :)
Removing ppc from cc list bcs everything still builds ok after the latest changes. Re-add if we need to do anything else (for instance if test images become available).
I get some strange behaviour with gdal: $ gdal-config --libs /usr/lib/libgdal.a /usr/lib/lib /usr/lib/-lpq /usr/lib/libgdal.a -lodbc -ljpeg -lgeotiff -ltiff -lpng -lnetcdf -lz -lm -ldl -L/usr/lib -lpq -L/usr/lib/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -L/usr/lib -lssl -lcrypto Especially "/usr/lib/lib /usr/lib/-lpq" looks suspicious, because those files or directories do not exist. Obviously this makes packages that depend on gdal unbuildable.
Something must be dorked on your system, since I get this on both x86 and sparc: $ gdal-config --libs -L/usr/lib -lgdal Are you sure you don't have anything weird or old lurking in your overlay or maybe /usr/local? Othwerwise, please post your arch/einfo.
Where is the overlay? I have 68 MB in /usr/local. find -name *gdal* gives nothing. I have linux 2.6.11.11 on Pentium M, Portage 2.0.51.22-r2.
sci-libs/libgeotiff and proj compiles without errors here on amd64.
we're currently testing a new alias system, sorry for the bugspam
while the latest ogdi compiles fine, 3.1.4-r1 fails: Making shared library: /var/tmp/portage/ogdi-3.1.4-r1/work/ogdi-3.1.4/bin/Linux/libogdi31.so gcc -shared -O -o /var/tmp/portage/ogdi-3.1.4-r1/work/ogdi-3.1.4/bin/Linux/libogdi31.so ecs_dyna.o ecsregex.o ecssplit.o ecsassoc.o ecshash.o ecstile.o server.o ecsdist.o ecslist.o ecsinfo.o ecsgeo.o ecs_xdr.o ecs_xdrz.o gmath.o client.o ecs_capabilities.o -ldl -lz -lexpat -L/usr/lib64 -lproj -lm /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: ecs_dyna.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC ecs_dyna.o: could not read symbols: Bad value collect2: ld returned 1 exit status make[3]: *** [/var/tmp/portage/ogdi-3.1.4-r1/work/ogdi-3.1.4/bin/Linux/libogdi31.so] Error 1 make[3]: Leaving directory `/var/tmp/portage/ogdi-3.1.4-r1/work/ogdi-3.1.4/ogdi/c-api/OBJ.Linux' make[2]: *** [all] Error 2 make[2]: Leaving directory `/var/tmp/portage/ogdi-3.1.4-r1/work/ogdi-3.1.4/ogdi/c-api' make[1]: *** [c-api] Error 2 make[1]: Leaving directory `/var/tmp/portage/ogdi-3.1.4-r1/work/ogdi-3.1.4/ogdi' make: *** [ogdi] Error 2 !!! ERROR: sci-libs/ogdi-3.1.4-r1 failed. !!! Function src_compile, Line 28, Exitcode 2 !!! make failed !!! If you need support, post the topmost build error, NOT this status message
Try it now...
yup, everything seems fine now on amd64 :)
(In reply to comment #0) > I'm working on the gdal and related stuff, and I'd like some confirmation that > it builds/runs on the arches I don't have access to (I can currently test on > x86 and sparc). The gdal tools can be used to confirm images can be > converted; I guess I should have some test images at some point, but at least > I'm getting some user-feedback (which is a good thing). Thanks in advance... Generally the alpha team doesn't keyword new packages unless a user requests it, or if it could be really useful to a lot of users, or if it is needed as a dependency of an already keyworded package. This is because we don't have the man power to test and keyword every package in the tree. agriffis has already done ogdi and libgeotiff. We'll wait until we get a user request to keyword gdal.
sci-libs/gdal seems to have been erroneously marked ~hppa in the past. It's not keyworded for hppa now so I'm going to leave it that way. sci-libs/libgeotiff-1.2.1-r1 fails to compile so I removed hppa keywording, which seems to have been set improperly in the past anyway. sci-libs/proj-4.4.9 is a dependency for sci-libs/ogdi-3.1.5-r1. Both compile properly and were marked ~hppa, so I marked them stable. HPPA done.
This seems pretty much done (or at least OBE).
