[GRASS-dev] Re: [GRASS GIS] #110: db/drivers/dbf fail to build due to undefined reference to 'SASetupDefaultHooks' (SHAPELIB)

[GRASS GIS]

#110: db/drivers/dbf fail to build due to undefined reference to
'SASetupDefaultHooks' (SHAPELIB)
-----------------------+----------------------------------------------------
  Reporter:  marisn    |       Owner:  grass-dev at lists.osgeo.org
      Type:  defect    |      Status:  new                      
  Priority:  critical  |   Milestone:  6.4.0                    
 Component:  default   |     Version:  svn-trunk                
Resolution:            |    Keywords:  dbf                      
-----------------------+----------------------------------------------------
Comment (by rouault):

 In the Valgrind log, it's clear that it was the GDAL's SASetupDefaultHooks
 version that was used. I guess that if things are right now with GRASS
 r30956, it's because safileio.c has been added to the GRASS tree now, and
 that its SASetupDefaultHooks version that is used now.

 However, it's really risky to have a library 'A', namely GRASS, that
 contains SHAPELIB symbols and that links with another library 'B', namely
 GDAL, that also contains SHAPELIB symbols...
 I'm not sure there's a guarantee that the symbols that will be used will
 come entirely from library 'A' or entirely from library 'B'. I'd be afraid
 that there's a mix... And here, you really want that the GRASS DBF driver
 uses its SHAPELIB symbols, not the GDAL ones.

 To be really safe, I would recommend a change to SHAPELIB to add
 decoration to all its symbols, like that

 {{{

 #ifndef SHAPELIBDECORATE
 #define SHAPELIBDECORATE(x) x
 #endif


 DBFHandle SHPAPI_CALL
       SHAPELIBDECORATE(DBFOpen)( const char * pszDBFFile, const char *
 pszAccess );
 DBFHandle SHPAPI_CALL
       SHAPELIBDECORATE(DBFOpenLL) ( const char * pszDBFFile, const char *
 pszAccess,
                  SAHooks *psHooks );
 DBFHandle SHPAPI_CALL
       SHAPELIBDECORATE(DBFCreate) ( const char * pszDBFFile );
 DBFHandle SHPAPI_CALL
       SHAPELIBDECORATE(DBFCreateLL)( const char * pszDBFFile, SAHooks
 *psHooks );

 int     SHPAPI_CALL
       SHAPELIBDECORATE(DBFGetFieldCount)( DBFHandle psDBF );
 int     SHPAPI_CALL
       SHAPELIBDECORATE(DBFGetRecordCount) ( DBFHandle psDBF );
 int     SHPAPI_CALL
       SHAPELIBDECORATE(DBFAddField) ( DBFHandle hDBF, const char *
 pszFieldName,
                    DBFFieldType eType, int nWidth, int nDecimals );

 ...

 }}}

 The shapelib included within GDAL would be compiled with :

 #define SHAPELIBDECORATE(x)  GDAL##x

 The shapelib included within GRASS would be compiled with :

 #define SHAPELIBDECORATE(x)  GRASS##x


 That's a rather heavy and boring change to SHAPELIB headers and sources,
 and to GRASS and GDAL source code, but that would solve definitely the
 problems.

 (Side node, we should do the samething in GDAL with libtiff...)

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/110#comment:15>
GRASS GIS <http://grass.osgeo.org>
GRASS Geographic Information System (GRASS GIS) - http://grass.osgeo.org/