This is an updated ebuild for GDAL 1.2.6, a geospatial package. It now USEs the sqlite flag, and can be built with sqlite support. It is basicly a re-versioned 1.2.5 ebuild. Reproducible: Always Steps to Reproduce:
Created attachment 56220 [details] New GDAL 1.2.6 ebuild
This ebuild fails to build. USE= -debug -fits +gif +jpeg -mysql -ogdi +png -postgres +python -sqlite As You can see from USE flags - I have NOT set Netcdf or HDF4, but they are used as they exist on my system and worse - they make gdal building to fail. IMHO Bugs #39942 ebuild was better as it was working. MSG: g++ gdalinfo.o \ /var/tmp/portage/gdal-1.2.6-r1/work/gdal-1.2.6/libgdal.a /var/tmp/portage/gdal-1.2.6-r1/work/gdal-1.2.6/libgdal.a -L/usr/lib -lgeos -ljasper -lmfhdf -ldf -ljpeg -lgeotiff -ltiff -lpng -lnetcdf -lz -lm -ldl -o gdalinfo /usr/lib/libnetcdf.a(attr.o): In function `NC_findattr': attr.c:(.text+0x760): multiple definition of `NC_findattr' /usr/lib/libmfhdf.a(attr.o):attr.c:(.text+0x0): first defined here /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/ld: Warning: size of symbol `NC_findattr' changed from 109 in /usr/lib/libmfhdf.a(attr.o) to 188 in /usr/lib/libnetcdf.a(attr.o) etc..
HDF4 and NetCDF _CANNOT_ be compiled into the same package. HDF4 contains some of the code from NetCDF 2.x, and thus there are symbol conflicts. I mentioned this in bug #39942, but I guess it was missed. This same problem also currently affects the GDAL 1.2.5 ebuild.
*** Bug 96280 has been marked as a duplicate of this bug. ***
No. They can. I solved this problem. Take ebuild from Bug #96280. That ebuild also has GRASS and GEOS support, etc. I have no HDF4 or NetCDF data to test how it works, but it compiles fine. (In reply to comment #3) > HDF4 and NetCDF _CANNOT_ be compiled into the same package. HDF4 contains some > of the code from NetCDF 2.x, and thus there are symbol conflicts. I mentioned > this in bug #39942, but I guess it was missed. This same problem also currently > affects the GDAL 1.2.5 ebuild.
Can you clarify what in that ebuild solves the problem? I didn't see anything special there to handle the conflict, and I know for a fact that the currect GDAL ebuild fails to compile when it tries to use HDF4 and NetCDF at the same time.
Alright, well the ebuild DOES work. I just wish I understood why. Can you explain why compiling HDF4 with szip support fixes the conflicts?
Umm. Dunno :) I just did the RTFM thing and found Bug#41146. It worked. Have You any HDF4 and NetCDF data to test it? I don't. W0ps! I just found Bug#96187 and it says - "Also this is not easy to catch because it compiles fine and only causes problems at runtime when the wrong function gets linked / called." Hm. Previusly GDAL failed to compile, maybee now it will fail to use HDF4 and NetCDF? Anybody having data to test it? Can You try out GRASS-6.0.0-r1 and GDAL-1.2.6 to confirm that they work if compiled in right way? See Bug#96278. (In reply to comment #7) > Alright, well the ebuild DOES work. I just wish I understood why. Can you > explain why compiling HDF4 with szip support fixes the conflicts?
Fails to build with xerces flag ------------------------------ configure:24876: checking for Xerces C++ configure:24943: result: requested, but compile or link fails! g++ -I/usr/include -I/usr/include/xercesc -o conftest conftest.cpp -L/usr/lib -lxerces-c -lpthread -ljasper -lmfhdf -ldf -logdi31 -ljpeg -lgeotiff -ltiff -lpng -lnetcdf -lz -lm -ldl conftest.cpp:1:34: util/PlatformUtils.hpp: No such file or directory conftest.cpp: In function `int main()': conftest.cpp:5: error: `XMLPlatformUtils' has not been declared conftest.cpp:5: error: `Initialize' undeclared (first use this function) conftest.cpp:5: error: (Each undeclared identifier is reported only once for each function it appears in.) configure: error: Please correct Xerces options, or don't enable Xerces. ------------------------------ Installing xerces-c beforehand seems to solve this problem
I'm trying to build gdal with +ogdi USE flag. It compiles fine, but if I try to run any of the ogr binaries (ogrinfo, ogr2ogr, etc'), they fail with "Floating point exception" error. USE="-debug -fits +gif +jpeg +mysql +ogdi +png -postgres +python +sqlite"
*** Bug 99165 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > I'm trying to build gdal with +ogdi USE flag. It compiles fine, but if I try to > run any of the ogr binaries (ogrinfo, ogr2ogr, etc'), they fail with "Floating > point exception" error. > > USE="-debug -fits +gif +jpeg +mysql +ogdi +png -postgres +python +sqlite" Same here (P4-EMT64, ogdi-3.1.4, gdal-1.2.6). a gdalinfo --version crashes with a floating point exception. In addition, emerging gdal with USE="-ogdi", while ogdi is still present, crashes gdalinfo/ogrinfo/... with a segfault, cf gdb trace below ----- >gdb gdalinfo GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run GA_Flint_LL83a.tif Starting program: /usr/bin/gdalinfo GA_Flint_LL83a.tif [Thread debugging using libthread_db enabled] [New Thread 46912527128160 (LWP 17533)] Driver: GTiff/GeoTIFF Size is 101, 217 Coordinate System is: GEOGCS["NAD83", DATUM["North_American_Datum_1983", SPHEROID["GRS 1980",6378137,298.2572221010002, AUTHORITY["EPSG","7019"]], AUTHORITY["EPSG","6269"]], PRIMEM["Greenwich",0], UNIT["degree",0.0174532925199433], AUTHORITY["EPSG","4269"]] Origin = (-85.025556,33.708056) Pixel Size = (0.01389439,-0.01387865) Corner Coordinates: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 46912527128160 (LWP 17533)] 0x00002aaaabec6e2c in pj_init () from /usr/lib/libogdi31.so (gdb) q ----- Now, emerge -C ogdi emerge -C gdal USE="-ogdi" emerge gdal compiles OK, but gdalinfo exits with --- gdalinfo: error while loading shared libraries: libogdi31.so: cannot open shared object file: No such file or directory --- a ldd /usr/bin/gdalinfo gives me libgdal.so.1 => /usr/local/lib/libgdal.so.1 (0x00002aaaaabc1000) libgeos.so.2 => /usr/lib/libgeos.so.2 (0x000000381cc00000) libodbc.so.1 => /usr/lib/libodbc.so.1 (0x00002aaaab146000) libxerces-c.so.26 => /usr/lib/libxerces-c.so.26 (0x000000381d200000) libpthread.so.0 => /lib/tls/libpthread.so.0 (0x00002aaaab2aa000) libjasper-1.701.so.1 => /usr/lib/libjasper-1.701.so.1 (0x00002aaaab3c0000) libmfhdf.so.0 => /usr/lib/libmfhdf.so.0 (0x00002aaaab512000) libdf.so.0 => /usr/lib/libdf.so.0 (0x00002aaaab63a000) libsz.so.1 => /usr/lib/libsz.so.1 (0x00002aaaab7e8000) libgif.so.4 => /usr/lib/libgif.so.4 (0x00002aaaab8f7000) libSM.so.6 => /usr/lib/libSM.so.6 (0x00002aaaab9ff000) libICE.so.6 => /usr/lib/libICE.so.6 (0x00002aaaabb0a000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00002aaaabc25000) libgeotiff.so => /usr/lib/libgeotiff.so (0x00002aaaabe01000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0x00002aaaabf2e000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x00002aaaac081000) libpng.so.3 => /usr/lib/libpng.so.3 (0x00002aaaac1a1000) libcfitsio.so => /usr/lib/libcfitsio.so (0x00002aaaac2d8000) libgrass_I.so => /usr/grass60/lib/libgrass_I.so (0x000000381e100000) libgrass_vask.so => /usr/grass60/lib/libgrass_vask.so (0x000000381df00000) libgrass_gmath.so => /usr/grass60/lib/libgrass_gmath.so (0x000000381ca00000) libgrass_gis.so => /usr/grass60/lib/libgrass_gis.so (0x000000381e300000) libgrass_datetime.so => /usr/grass60/lib/libgrass_datetime.so (0x000000381ce00000) libdl.so.2 => /lib/libdl.so.2 (0x00002aaaac557000) libpq.so.4 => /usr/lib/libpq.so.4 (0x000000381d000000) libmysqlclient.so.12 => /usr/lib/libmysqlclient.so.12 (0x00002aaaac65a000) libz.so.1 => /lib/libz.so.1 (0x00002aaaac7a2000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x00002aaaac8b4000) libnsl.so.1 => /lib/libnsl.so.1 (0x00002aaaac9e8000) libssl.so.0.9.7 => /usr/lib/libssl.so.0.9.7 (0x00002aaaacafe000) libcrypto.so.0.9.7 => /usr/lib/libcrypto.so.0.9.7 (0x00002aaaacc33000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/libstdc++.so.6 (0x00002aaaace5a000) libm.so.6 => /lib/tls/libm.so.6 (0x00002aaaad045000) libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/libgcc_s.so.1 (0x00002aaaad1c8000) libc.so.6 => /lib/tls/libc.so.6 (0x00002aaaad2d3000) libogdi31.so => not found libpq.so.3 => /usr/lib/libpq.so.3 (0x00002aaaad4f5000) /lib64/ld-linux-x86-64.so.2 (0x00002aaaaaaab000) libg2c.so.0 => /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/libg2c.so.0 (0x00002aaaad615000) libproj.so.0 => /usr/lib/libproj.so.0 (0x00002aaaad735000) libncurses.so.5 => /lib/libncurses.so.5 (0x00002aaaad875000) libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x00002aaaad9ce000) libresolv.so.2 => /lib/libresolv.so.2 (0x00002aaaadb45000) libgpm.so.1 => /lib/libgpm.so.1 (0x00002aaaadc5a000) libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x00002aaaadd60000) libcom_err.so.2 => /lib/libcom_err.so.2 (0x00002aaaade85000) libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0 (0x00002aaaadf87000) How can I get rid of this call to libogdi31 ?
(In reply to comment #12) > How can I get rid of this call to libogdi31 ? Duh, by first making sure I didn't have an extra libgdal.so.1 in /usr/local/lib that needed libogdi31.so and that came from a previous test, of course... This is fixed. Now that there's no longer any dependency on ogdi, gdalinfo works fine
Ogdi and the latest gdal should all be fixed now; as always, open a bug if you find any problems.
