[Bug 168719] Review Request: gdal

bugzilla at redhat.com bugzilla at redhat.com
Thu Sep 22 02:58:20 UTC 2005


Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Review Request: gdal


https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168719





------- Additional Comments From rc040203 at freenet.de  2005-09-21 22:58 EST -------
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #4)
> > > (In reply to comment #2)

> > > > - Probably a lot of missing package deps inside of devel package.
> > > > (c.f. /usr/lib/libgdal.la)
> > > 
> > > As far as I can see the dependencies are sufficient. gdal-devel is
sufficient to
> > >  build other packages against gdal. I tried with mapserver after removing all
> > > other devel-packages on my system.
> > Hmm, libgal is linked against various libraries. Normally you will not be able
> > to link against libgal unless you have all devel packages corresponding to these
> > libraries installed.

> gdal just creates something like an API to different raster and vector GIS
> formats. So no information about postgresql, hdf, mysql etc. is needed to have
> access to gdal. I furthermore checked the header files in /usr/include/gdal to
> see which header files they include and they just need either other gdal-header
> files or standards like stdio.h etc. So I am rather sure that the dependencies
> are sufficient. Have I overseen something?

Yes,

* check the output of
nm -sDC libgdal.so.1.8.0  | grep ' U '

libgdal.so.1.8.0 uses other libraries. In your testcase you probably just happen
to get away luckily, because your application just seems to happen not to use
functions from these other libs.

* The gdal headers use headers from other packages:
# cd /usr/include/gdal
# grep \#include *.h | sed 's,.*[\"\<]\(.*\)[\"\>],\1,' | \
while read a; do if [ ! -f $a ]; then echo "$a"; fi; done
sql.h
sqlext.h
...

> > > > Additional remarks:
> > > > - I recommend not to ship static libs.

> Most of these reasons are reasons against static linkage and for shared linkage
> and I fully agree with you in this issue. Nevertheless if really someone would
> like to statically link gdal I don't want my package to be the stopper - even if
> I would probably never need it myself. 
The point is: Probably nobody uses them! 

The only reason I can imagine for wanting to use static libs is application
vendors to ship application binaries, which are supposed to be "distribution
independent". From a distribution's view this doesn't make sense, because all
dependencies inside of the distribution can resolved inside of the distribution.

-- 
Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.




More information about the fedora-extras-list mailing list