[GRASS5] Fwd: [winGRASS] db driver problem?
grass4u at gmail.com
Thu Nov 4 00:39:25 EST 2004
Is no body interested in this issue just because the number of
winGRASS users is small? :-)
---------- Forwarded message ----------
From: Glynn Clements <glynn at gclements.plus.com>
Date: Sun, 24 Oct 2004 02:15:59 +0100
Subject: Re: [winGRASS] db driver problem?
To: Huidae Cho <grass4u at gmail.com>
Cc: 2win <wingrass at grass.itc.it>
Huidae Cho wrote:
> I compiled grass 5.7 but I couldn't use any db driver. For example,
> dbf.exe calls db_driver_* functions in libgrass_dbstubs.dll which do
> nothing. But after installing pre-compiled 5.7, it worked! what's a
The way that the stub functions work makes certain assumptions about
the way in which the linker resolves multiply-defined symbols.
The drivers all depend upon libgrass_dbmidriver, which in turn
requires all of the db_driver_* symbols. libgrass_dbstubs provides
dummy versions of all of those functions, while individual drivers
provide real versions of some of them.
The intention is that libgrass_dbmidriver will use the real
implementation from the executable if it exists, and the dummy
implementation from libgrass_dbstubs if it doesn't. However, it's
possible that, depending upon the behaviour of the linker, the dummy
versions may override the actual implementation.
In fact, on Windows, I would expect this to happen; I'm not sure how
the pre-compiled version managed to avoid this issue.
A more robust solution would be for the stubs to have different names,
and for each driver to provide every symbol itself. For unimplemented
functions, the driver would have to include a wrapper around the stub
Relying upon the linker to get the priorities right saves the effort
of writing the wrappers, but it's rather fragile.
Glynn Clements <glynn.clements at virgin.net>
More information about the grass-dev