Hello Radim
On Tue, 25 May 2004, Radim Blazek wrote:
On Monday 24 May 2004 15:30, Paul Kelly wrote:
But I have since found that they need to be there when compiling with
shared libraries on Cygwin (as far as I can remember it was discussed on
the list that there was no way to allow undefined symbols in Cygwin DLLs).
Should we add somehow --no-undefined to make sure that it compiles on Cygwin?
It is not standard linker flag I guess. It is probably sufficient if
developers set this flag?
As far as I know I don't think that is possible for Cygwin DLLs; the dependencies on shared libraries have to be added to the linker command-line and there seems to be no way to create DLLs with undefined symbols. In 5.3 EXTRA_LIBS is called SLIBDEPS; it seems to be a fairly standard thing and I think it is correct for it to be there?
Could it be gproj staticaly linked with libgdal.a?
I think so yes---it wouldn't make the gproj library any bigger---it only
seems to check for undefined symbols there at that stage. libgdal.a would
only be linked into the binary of the module that actually used it. But it
would be linked into every module and if e.g. libgdal.a was linked into
every vector module it would make things rather big.
I don't think to link modules with libgdal.a but to link libgrass_gproj.so
with libgdal.a, that means the OSR* functions will be present in
libgrass_gproj.so only, but not in modules. libgrass_gproj.so
staticaly linked with libgdal.a has only 250KB (dynamicaly linked
with libgdal.so it has 60KB).
Well if that worked it would be an interesting idea but not very elegant I think to have a separate GDAL for GRASS statically linked in, but as I think about it more it might reduce a lot of problems.
But I don't know if it is possible to do that and make it work. When I was trying to get 5.3 to work with shared libraries on Cygwin I tried to compile libdig2 statically and then link it into a shared libvect by placing the full path to libdig2.a along with all the .o files in the linker command. It seemed to work and the file size of libgrass_vect.so increased but running nm on it none of the symbols from libdig2.a seemed to be there. Perhaps it is a simple problem but I could not get it to work. However I suppose it is much more likely to work on real Unix rather than Cygwin.
But OSR* probably use share/gdal/ files, which should be installed
somehow somewhere?
Well the ones that are relevant to datum and projection are already there in lib/proj and are copied into $GISBASE/etc/ogr_csv when compiling. GPJ_set_csv_loc() is a finder function to return the full path to that directory, and SetCSVFilenameHook( GPJ_set_csv_loc ); is used in g.proj and libgrass_gproj to tell OGR to look there for the .csv files.
To compile with libgdal.a we probably need a full path to the library
produced by gdal-config (new option)?
Yes you could maybe parse the output of gdal-config --libs with awk or sed or something and add .a to the end but it wouldn't be very elegant.
Maybe the functions in convert.c could go into a special GRASS/GDAL
interface library, something like a new version of libgrass. I only
noticed after I had done most of the work on GPJ_wkt_to_grass()
etc. that Frank had written some slightly similar projection information
conversion functions that are in libgrass but not in any version of GRASS
itself, or GDAL. I suppose the projection information conversion functions
are really only needed when importing or exporting data, so they should be
grouped with the other functions that do that.
Do you think that at least one function which produce a projection info in
a format known by GDAL OSR functions (WKT?) could be independent of GDAL
and put e.g. in libgrass_gis.so?
Well they know PROJ.4 format and that is produced independently of those functions, but to produce good quality WKT with all the information there requires more detail than is included in the PROJ.4 description so it is really best to produce the WKT inside GRASS where it can access datum.table for the EPSG datum names and other things. The OSR functions are vital for producing WKT though as it is so complicated and couldn't be done without them.
I like the idea of the functions in convert.c becoming part of the GRASS-access component of GDAL some day.but it's not clear to me at the minute what is the best way to go.
Paul