tdb_chainlock() in tdb1, tdb2 and tdb_compat ?

[Volker Lendecke]

On Fri, Apr 13, 2012 at 10:37:42AM +1000, Andrew Bartlett wrote:
> There are certainly a lot of issues with the nature and timing of the
> introduction of tdb2 to Samba, but one of the advantages of the waf
> build system is that the duplicate symbol issue you fear won't happen.
> tdb2 is a versioned library, and so the symbol won't collide with any
> static or imported tdb1 symbol. 

For my taste this is non-obvious enough that I don't like
it. Samba has not used libtool because it created
non-obvious dependencies and magic foo that makes potential
debugging issues one significant step more difficult. Please
correct me if I got history wrong. Now we are solving a
problem that we introduced for ourselves with such
non-obvious technology where we could pretty easily use
Simo's approach to not artificially introduce API naming
clashes that we need to clean up later.

Back to the original question that started this thread: Does
symbol versioning also solve the TDB_ERROR vs int return
problem I saw? How does waf guarantee that from within code
that is not properly converted yet we do not call
tdb_chainlock that returns TDB_ERROR but the int version
from tdb1? This to me is much more serious because the
compiler does not catch it as an error as it does with
tdb_fetch.

Thanks,

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de