[winGRASS] db driver problem?

[Huidae Cho]

Yeah, I agree with you. Nothing should be dependent on the behaviour
of the linker.
I found that there are no db_driver_* symbols in dbf.exe in the
pre-compiled version.
To my knowledge, I don't understand what's going on here. But it would
be safer to use a wrapper than a kind of assumption.

Huidae Cho

On Sun, 24 Oct 2004 02:15:59 +0100, Glynn Clements
<glynn at gclements.plus.com> wrote:
> 
> 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 at virgin.net>
>