[GRASS5] Re: GRASS <-> GDAL circular references

[Paul Kelly]

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