Bugzilla Bug 98593

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).