Hi list,
Is no body interested in this issue just because the number of
winGRASS users is small? 
Huidae Cho
---------- Forwarded message ----------
From: Glynn Clements <glynn@gclements.plus.com>
Date: Sun, 24 Oct 2004 02:15:59 +0100
Subject: Re: [winGRASS] db driver problem?
To: Huidae Cho <grass4u@gmail.com>
Cc: 2win <wingrass@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
problem?
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
function, e.g.:
int db_driver_begin_transaction(void)
{
return db_stub_begin_transaction();
}
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@virgin.net>