[FGS] Re: [Gdal-dev] (no subject)
Frank Warmerdam
warmerdam at pobox.com
Thu Jul 8 12:08:42 EDT 2004
Silke Reimer wrote:
> Yes, I already had several looks on this page and I am subscribed to
> the list almost from the very beginning. I just didn't have the time
> by now to have a closer look. I think the project is very promising
> but Bernhards comments on the freegis-list (see [1]) are really
> worth to think about.
Silke,
I reviewed Bernhards comments (which I also read at the time). Picking
out a bit of what he said:
Bernhard said:
> There is not much market to put a lot of effort into the integration
> because GIS is still an expert topic which people tend to spend
> money differently on.
I would tend to agree that producing binary distributions of foss software
is not yet very commercially viable activity. However, I think a
non-commercial (aka for fun and advocacy) effort can make a valuable
contribution.
> Building of binaries should better be handled by the distributions
> and the individual project.
I don't necessarily agree with this for two main reasons:
o Software developers (such as me) don't necessarily have much expertise
with different operating systems and packaging systems. Despite being
a Red Hat and Debian user for instance, I still haven't mastered producing
RPMs and .debs. Much less properly preparing packages for OSes like
windows, MacOS X, Solaris and so on.
o A significant part of the value in a distribution like FGS or the
Freegis RPM CDs is in putting together the packages with appropriate
interlinkages properly. For instance, ensuring that all packages that
can utilize GDAL or PROJ are built with them, and having one central copy
of these base packages that are as functional as possible. This is not so
easy for someone who is primarily just a GRASS or MapServer developer
for instance.
> There is a competition going fueling
> the motivation. It helps to support both to do this properly
> and it seem to be a lot of fine tuning.
I'm not sure I follow this. I will say I think there is room for a number
of packaging efforts, and I for one wouldn't really want to distract Silke
from producing nice RPMs of packages. This is a valuable service beside the
FGS efforts.
> The Freegis team here
> as answered many questions and pushed quite some project
> to actually make their code available as Free Software.
> This base work will need to be continued on a broader basis.
Certainly Intevation and the FreeGIS team provide a very important role
in terms of maintaining the freegis.org (the focused freshmeat.net of
the geospatial world), freegis mailing list (a central place the whole
community can discuss projects), a variety of advocacy efforts and the
freegis CDs.
Silke says:
> I think that the main technical problem is that every distribution
> has its own specialities. I already experienced this when I tested
> the FreeGIS CD for "only" 4 distributions.
Certainly a goal of FGS is to provide a distribution that is as
multi-distribution as possible by providing required packages (ie. GTK)
that wouldn't be essentially ubiquitous to all Linux distributions and
by avoiding any platform specific packaging system.
> As far as I understood you are solving this by compiling every
> necessary library for fgs, right? How far do you go with this
> approach?
Well, we assume we don't need to provide the X libraries, and some other
core low level libraries. So for instance, for "gvtest" (a C core of OpenEV)
the ldd looks like this:
warmerda at gdal2200[189]% ldd gvtest
libgdal.so => /usr5/pkg/fgs/lib/libgdal.so (0x40016000)
libgtkgl.so.5 => /usr5/pkg/fgs/lib/libgtkgl.so.5 (0x402e1000)
libGLU.so.1 => /usr5/pkg/fgs/lib/Mesa/libGLU.so.1 (0x402e5000)
libGL.so.1 => /usr5/pkg/fgs/lib/Mesa/libGL.so.1 (0x4035b000)
libgtk-1.2.so.0 => /usr5/pkg/fgs/lib/libgtk-1.2.so.0 (0x40536000)
libgdk-1.2.so.0 => /usr5/pkg/fgs/lib/libgdk-1.2.so.0 (0x40655000)
libgmodule-1.2.so.0 => /usr5/pkg/fgs/lib/libgmodule-1.2.so.0 (0x40686000
)
libgthread-1.2.so.0 => /usr5/pkg/fgs/lib/libgthread-1.2.so.0 (0x40689000
)
libglib-1.2.so.0 => /usr5/pkg/fgs/lib/libglib-1.2.so.0 (0x4068c000)
libpthread.so.0 => /lib/i686/libpthread.so.0 (0x406c1000)
libdl.so.2 => /lib/libdl.so.2 (0x406f1000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x406f5000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40703000)
libstdc++.so.5 => /usr5/pkg/fgs/lib/libstdc++.so.5 (0x407e1000)
libm.so.6 => /lib/i686/libm.so.6 (0x40892000)
libgcc_s.so.1 => /usr5/pkg/fgs/lib/libgcc_s.so.1 (0x408b4000)
libc.so.6 => /lib/i686/libc.so.6 (0x42000000)
libpq.so.3 => /usr5/pkg/fgs/lib/libpq.so.3 (0x408bd000)
libproj.so.0 => /usr5/pkg/fgs/lib/libproj.so.0 (0x408cf000)
libodbc.so.1 => /usr5/pkg/fgs/lib/libodbc.so.1 (0x40904000)
libogdi31.so => /usr5/pkg/fgs/lib/libogdi31.so (0x40962000)
libjpeg.so.62 => /usr5/pkg/fgs/lib/libjpeg.so.62 (0x4097e000)
libgeotiff.so => /usr5/pkg/fgs/lib/libgeotiff.so (0x4099b000)
libtiff.so.3 => /usr5/pkg/fgs/lib/libtiff.so.3 (0x409be000)
libnetcdf.so => /usr5/pkg/fgs/lib/libnetcdf.so (0x40a0a000)
libz.so.1 => /usr5/pkg/fgs/lib/libz.so.1 (0x40a2b000)
libstdc++-libc6.1-1.so.2 => /usr/lib/libstdc++-libc6.1-1.so.2 (0x40a3800
0)
libvga.so.1 => /usr5/pkg/fgs/lib/Mesa/libvga.so.1 (0x40a7a000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40abf000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40ac9000)
libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40ae0000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x40af6000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
libcrypt.so.1 => /lib/libcrypt.so.1 (0x40afe000)
libresolv.so.2 => /lib/libresolv.so.2 (0x40b2b000)
libnsl.so.1 => /lib/libnsl.so.1 (0x40b3d000)
libexpat_ogdi31.so => /usr5/pkg/fgs/lib/libexpat_ogdi31.so (0x40b53000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40b75000)
The only system libraries are libpthread, libdl, libXext, libX11, libm, libc,
libstdc++, libSM, libICE, libXmu, LibXi, ld-linux, libcrypt, libresolv,
libnsl, and libXt. Of course, most are X related and I thin kthat libstdc++
should likely be distributed in FGS.
In short ... I would like to take the "include required libraries" pretty
far. That said, I would also like - in some circumstances - to be able to
use native versions of stuff like OpenGL if available, but have distributed
versions to fall back on.
>>I would like to see your grass work rolled in as an fgs package regardless
>>of whether you are involved. But here is an opportunity to help get grass
>>out there.
>
>
> It shouldn't be to difficult to build a fgs-conformant tar.gz out
> form the rpm-build process: Just
> rpmbuild -bi grass.spec
> cd ../BUILD/grass-root
> tar xz * > grass.tar.gz
In fact, that might be an interesting approach. To see if we can use
the binaries in your RPMs directly. There might be some issues with
dependent libraries (like PROJ) though.
> I am not aware though what adaptation will be necessary to adapt the
> Library-paths for the packages since (as far as I understood your
> procedure) you build everything which is necessary for the GIS-suite
> and set the LD_LIBRARY_PATHS in a way that no other system libraries
> are uses. Am I right?
I think the idea is to ensure that the FGS lib directory is ahead
of all other lib directories before running FGS binaries, but not
necessarily excluding other lib directories.
> Perhaps I will find some time to try it out this evening, but I am
> not sure about it.
Your expertise would be welcome, but as we all have to pick the
battles it is appropriate for us to fight. To try and get the best
leverage out of our own contributions. Just having you comment on
problems we might encounter in building GRASS ourselves on the FGS
mailing list would be a substantial help.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
More information about the Foss-gis-suite
mailing list