[GRASS5] Fwd: [winGRASS] db driver problem?

[Huidae Cho]

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 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
> 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>