this is a submission of an ebuild for the gdal 1.1.9. i suggest that it be included under the category dev-libs. it is dependent on the cfitsio library v. 2.470 of which i also submitted an ebuild.
Created attachment 24676 [details] gdal-1.1.9.ebuild
add the cfitsio bugno to the 'depends on' field please I dunno, isn't this too specific a package to be featured and maintained in our main tree ? And this isn't a gnome app is it ? No i don't think so, please reassign wranglers.
I think this library should be added to the portage because many GIS sw use or will use it; next version of Grass (it's in portage) will use it and qgis (http://bugs.gentoo.org/show_bug.cgi?id=56262) too.
I support this one. Some major GIS packages like 'Mapserver' depend on the gdal library. btw, you can get the libgrass5 <a href="http://bugs.gentoo.org/show_bug.cgi?id=39314">here</a>
This ebuild worked for me. I'd like to see it become part of portage. Two things: 1. I had to add spaces on the DEPEND= line to avoid emerge errors. 2. I think that ogr should be included by default (the --with-ogr option)
Compilation worked for me, but when I tried to later link something with -lgdal, it failed. Turns out when the library is installed, it only installs libgdal.1.1.so in /usr/lib, but doesn't create appropriate symlinks for compiler and runtime linker to it. This is not problem with ebuild, and it's fixed with newer versions of library (certainly 1.2.1), but newer versions have their own issues. So far I was only able to succesfully install them after disabling python support, since libtool does some wierd relinking magic with python libraries that fails miserably inside sandbox. Besides, it has also new manpages added and it's Makefile ignores mandir, but at least listens to INST_MAN instead. That said, I'd like to see this enter portage too. If for nothing else, there's Debian package and we don't want to be behind Debian, do we?;) And it's used by Gazebo from playerstage robotic project.
Created attachment 44647 [details] Gdal-1.2.5 ebuild Hope this gdal ebuild will work better than prev. It worked fine with gdal-1.2.4 too. This ebuild is required for grass and qgis (hope to make ebuilds for them too) :)
Just to the 1.2.5 ebuild - configure requires for mysql path to /usr/bin/mysql_config and not the directory. And thanks for the gdal ebuild, I need grass-5.7.0 and it doesn't work well without this ebuild :-)
It doesn't compile on my machine :-( Here is the error (it doesn't say too much to me): /bin/sh ../libtool --mode=compile g++ -Wall -O2 -march=pentium4 -fomit-frame-pointer -Iogrsf_frmts -I. -I../port -I../gcore -I../ogr -I../alg -I../port -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include-I/usr/lib -I/usr/lib/include -c -o ogrgeometry.o ogrgeometry.cpp g++ -Wall -O2 -march=pentium4 -fomit-frame-pointer -I.. -I../.. -I/usr/include/mysql -I../../../port -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -c ogrmysqlresultlayer.cpp -fPIC -DPIC -o ../o/.libs/ogrmysqlresultlayer.o g++ -Wall -O2 -march=pentium4 -fomit-frame-pointer -I.. -I../.. -I/usr/include/mysql -I../../../port -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -c ogrmysqlresultlayer.cpp -o ../o/ogrmysqlresultlayer.o >/dev/null 2>&1 g++ -Wall -O2 -march=pentium4 -fomit-frame-pointer -Iogrsf_frmts -I. -I../port -I../gcore -I../ogr -I../alg -I../port -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -c ogrgeometry.cpp -fPIC -DPIC -o .libs/ogrgeometry.o make[3]: Leaving directory `/var/tmp/portage/gdal-1.2.5/work/gdal-1.2.5/ogr/ogrsf_frmts/mysql' make[2]: Leaving directory `/var/tmp/portage/gdal-1.2.5/work/gdal-1.2.5/ogr/ogrsf_frmts' make[1]: *** [sublibs] Error 2 make[1]: *** Waiting for unfinished jobs.... g++ -Wall -O2 -march=pentium4 -fomit-frame-pointer -Iogrsf_frmts -I. -I../port -I../gcore -I../ogr -I../alg -I../port -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -c ogrgeometry.cpp -o ogrgeometry.o >/dev/null 2>&1 make[1]: Leaving directory `/var/tmp/portage/gdal-1.2.5/work/gdal-1.2.5/ogr' make: *** [ogr-target] Error 2 !!! ERROR: dev-libs/gdal-1.2.5 failed. !!! Function src_compile, Line 123, Exitcode 2 !!! Error: emake failed! !!! If you need support, post the topmost build error, NOT this status message.
And the same for 1.2.4: /bin/sh ../../../libtool --mode=compile g++ -Wall -O2 -march=pentium4 -fomit-frame-pointer -I.. -I../.. -I/usr/include/mysql -I../../../port -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -c -o ../o/ogrmysqlresultlayer.o ogrmysqlresultlayer.cpp /bin/sh ../libtool --mode=compile g++ -Wall -O2 -march=pentium4 -fomit-frame-pointer -Iogrsf_frmts -I. -I../port -I../gcore -I../ogr -I../alg -I../port -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include-I/usr/lib -I/usr/lib/include -c -o ogrcurve.o ogrcurve.cpp g++ -Wall -O2 -march=pentium4 -fomit-frame-pointer -I.. -I../.. -I/usr/include/mysql -I../../../port -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -c ogrmysqlresultlayer.cpp -fPIC -DPIC -o ../o/.libs/ogrmysqlresultlayer.o g++ -Wall -O2 -march=pentium4 -fomit-frame-pointer -Iogrsf_frmts -I. -I../port -I../gcore -I../ogr -I../alg -I../port -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -c ogrcurve.cpp -fPIC -DPIC -o .libs/ogrcurve.o g++ -Wall -O2 -march=pentium4 -fomit-frame-pointer -I.. -I../.. -I/usr/include/mysql -I../../../port -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -c ogrmysqlresultlayer.cpp -o ../o/ogrmysqlresultlayer.o >/dev/null 2>&1 g++ -Wall -O2 -march=pentium4 -fomit-frame-pointer -Iogrsf_frmts -I. -I../port -I../gcore -I../ogr -I../alg -I../port -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -I/usr/lib -I/usr/lib/include -c ogrcurve.cpp -o ogrcurve.o >/dev/null 2>&1 make[3]: Leaving directory `/var/tmp/portage/gdal-1.2.4/work/gdal-1.2.4/ogr/ogrsf_frmts/mysql' make[2]: Leaving directory `/var/tmp/portage/gdal-1.2.4/work/gdal-1.2.4/ogr/ogrsf_frmts' make[1]: *** [sublibs] Error 2 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory `/var/tmp/portage/gdal-1.2.4/work/gdal-1.2.4/ogr' make: *** [ogr-target] Error 2 !!! ERROR: dev-libs/gdal-1.2.4 failed. !!! Function src_compile, Line 123, Exitcode 2 !!! Error: emake failed! !!! If you need support, post the topmost build error, NOT this status message.
This combination of flags works fine for me: dev-libs/gdal-1.2.5 -cfitsio -geos +geotiff +gif -hdf4 -jasper +jpeg +mysql -odbc -ogdi +png -postgres +python -sqlite +tif The problem is probably related to sqlite use flag.
Sorry Miroslav! It's my first ebuild and I was working on it for about two weeks ;) Try to add "-j1" after emake and emerge (compile) then (I'm not on Linux box to create diffs etc.). That MySQL stuff shuld be corrected too ;) You shuld use geos use flag. Geos ebuild can be found at http://bugs.gentoo.org/show_bug.cgi?id=38060 I have working grass 5.7.0 ebuild too, but it needs some testing yet. Hope to finish it next week.
Thank you for your effort :-)
If you have the ebuild for qgis, I would be glad to test it. I need it little bit urgently ;-)
Created attachment 44931 [details] Working gdal ebuild Sorry - prev. ebuild was broken. My fault. Now its tested by me and Miroslav ?ulc.
Created attachment 45066 [details, diff] Patch for latest gdal-1.2.5 ebuild I had some problems using this ebuild because I don't have geotiff installed. GDAL requires geotiff in some form, even if it is its own internal version. This patch fixes this problem by specifying --with-geotiff=internal if the geotiff use flag is not set. The patch also fixes a similar problem for libtiff and allows for compilation with netcdf support. The problem with netcdf is that netcdf and hdf4 have symbol collisions (hdf4 contains old an netcdf version), so you cannot compile it with support for both. The patch allows the ebuild to work around this. Any developers care to comment? I've been able to install the package using this (patched) ebuild and compile my own program with gdal support. I'd really like to get this into portage.
Your patch has bug - no netcdf in IUSE. Question of geotiff etc. is a bit political - if user doesn't set some flag does it mean, that he wants to use gdal built in library or he wants gdal to be built w/o this library at all? My ebuild was created with idea, that if user doesn't sets some USE flag, then gdal is built w/o this lib, but if it is set, then is used external library (external library can be newer than gdal built in!). Any arguments in flawor of any of those two ways? Oh, yeah - if two USE flags cannot be used together, IMHO build must be stopped until user decides what flags to use and what not. Only shuld it fail with errmsg or wait for user input?
Thanks for catching the lack of netcdf in IUSE -- obviously I missed it. As to the question of use flags and optional packages, it's kinda pointless. GeoTiff and all others I changed to be set internal are REQUIRED packages. I don't have a use flag set for geotiff and when I tried to build the package with the original ebuild, it failed. In this case, I think it's fine to use the built-in version if the user hasn't specified otherwise. For the handling of the netcdf/hdf4 conflicts and use flags, I think we need a higher power to step in and tell us what the proper solution is -- unless anyone knows of another package in portage that has handled this same issue?
Created attachment 49457 [details] Gdal-1.2.5 ebuild As most of GIS related stuff has moved to sci-*, I suggest to move gdal to sci-libs. This ebuild has correct dependencies to sci-* instead of old dev-libs etc. New Grass ebuilds will look for gdal in sci-libs. No update need for those already running gdal. PS. Netcdf issue is still open.
If I compile with standard USE flags (thus not setting anything), compilation crashes, precisely as mentioned by Miroslave in Additional Comment #9, 2004-11-25 01:27 PST Compilation with the USE flags as follows does compile cleanly however: USE="{$USE} -cfitsio -geos geotiff gif -hdf4 -jasper jpeg -mysql -odbc -ogdi png postgres python -sqlite tif" I think it has to do with the -sqlite or -ogdi USE flag, but am not sure...
Martijn Meijers - I was able to compile GDAL with and without sqlite and ogdi. Can You give more info - what use flags You used when compililing gdal failed and the error message etc.
Is there a reason this bug depends on libgrass? http://bugs.gentoo.org/show_bug.cgi?id=39314 I've been able to compile this package without libgrass. Not having any dependencies might help this package into portage.
Dunno why gdal depends on bug #39314. Only reason may be that gdal can be compiled with Grass and grass can be compiled with gdal. In current gdal ebuild this is ignored, because grasslib isnt in portage and settin dependence on grass will cause crossdependency. If somebody realy need to compile gdal with grass (grass lib) and not in reverse order (grass with gdal), he can drop msg. here and we will think how to solve it. It realy makes more sese to set dependency to bug #38060 - GEOS.
Should this bug really depend on the GEOS bug #38060, since you can still install GDAL without it? On another note, what can we do to get this into portage? This bug is now more than a year old, and DOES have working ebuilds....
GEOS has working ebuild too. They both can go into portage and that can be the best solution for both of them. GDAL can be built w/o GEOS, but GEOS adds important functionality to GDAL and, if there will be no GEOS in portage, we will have a non working USE flag for GDAL.
I'd really like to see this move forward. Could someone post the latest version of the ebuild? We do a lot of work with GDAL and I'm moving my entire lab to gentoo. Let me know if I can facilitate in any way.
Seems that gdal ebuild has made into portage as of 20050220. I suppose this bug should be closed now.
(In reply to comment #27) > Seems that gdal ebuild has made into portage as of 20050220. I suppose this bug should be closed now. Unfortunatly no. GDAL ebuild in portage has some limitations if compared to this bugs ebuild - it lacks GEOS, jasper, odbc and there are some tricks with ogdi and hdf/netcdf/porstgres/mysql. I will overlook portages and this bugs versions to create new full feature ebuild.
There is new, enchanced GDAL-1.2.6 ebuild at http://bugs.gentoo.org/show_bug.cgi?id=96280 It has GRASS support (for r.out.gdal) and can be merged with HDF4 and NetCDF at same time. Grab and test it.
Closing, sci-libs/gdal-1.2.6-r1 in portage. Please, open a new bug if there are still issues with the current ebuild version.
