Bugzilla Bug 39942

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 an attachment (id=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 an attachment (id=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 an attachment (id=44931) [details]
Working gdal ebuild

Sorry - prev. ebuild was broken. My fault. Now its tested by me and Miroslav
?ulc. 

Created an attachment (id=45066) [details]
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 an attachment (id=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.