Berkeley DB v6 compatibility fix #8626

netsafe · 2016-08-30T06:01:50Z

Fixes building error looking like this:
CXX wallet/libbitcoin_wallet_a-db.o
wallet/db.cpp: In member function ‘void CDBEnv::EnvShutdown()’:
wallet/db.cpp:46:16: error: call of overloaded ‘DbEnv(int)’ is ambiguous
DbEnv(0).remove(strPath.c_str(), 0);
^
wallet/db.cpp:46:16: note: candidates are:
In file included from wallet/db.h:21:0,
from wallet/db.cpp:6:
/usr/include/db_cxx.h:916:2: note: DbEnv::DbEnv(const DbEnv&)
DbEnv(const DbEnv &);
^
/usr/include/db_cxx.h:518:2: note: DbEnv::DbEnv(DB_ENV)
DbEnv(DB_ENV dbenv);
^
/usr/include/db_cxx.h:516:2: note: DbEnv::DbEnv(u_int32_t)
DbEnv(u_int32_t flags);
^
Makefile:5780: recipe for target 'wallet/libbitcoin_wallet_a-db.o' failed
make[2]: * [wallet/libbitcoin_wallet_a-db.o] Error 1

Fixes building error looking like this: CXX wallet/libbitcoin_wallet_a-db.o wallet/db.cpp: In member function ‘void CDBEnv::EnvShutdown()’: wallet/db.cpp:46:16: error: call of overloaded ‘DbEnv(int)’ is ambiguous DbEnv(0).remove(strPath.c_str(), 0); ^ wallet/db.cpp:46:16: note: candidates are: In file included from wallet/db.h:21:0, from wallet/db.cpp:6: /usr/include/db_cxx.h:916:2: note: DbEnv::DbEnv(const DbEnv&) DbEnv(const DbEnv &); ^ /usr/include/db_cxx.h:518:2: note: DbEnv::DbEnv(DB_ENV) DbEnv(DB_ENV *dbenv); ^ /usr/include/db_cxx.h:516:2: note: DbEnv::DbEnv(u_int32_t) DbEnv(u_int32_t flags); ^ Makefile:5780: recipe for target 'wallet/libbitcoin_wallet_a-db.o' failed make[2]: ** [wallet/libbitcoin_wallet_a-db.o] Error 1

netsafe · 2016-08-30T06:09:18Z

I've originally found it for namecoin - all the detalis there namecoin/namecoin-core#101

jonasschnelli · 2016-08-30T06:38:19Z

I think this change makes sense.
BDB upstream documentation for the DbEnv constructor: https://docs.oracle.com/cd/E17276_01/html/api_reference/CXX/envcreate.html

luke-jr · 2016-08-30T07:21:30Z

It might actually be a good idea to fail to build against BDB 6... it changed the license to AGPL, and so users will by default be infringing if they just use Bitcoin Core as-is this way (as AGPL requires providing source code to every peer).

That said, I don't really care strongly either way. Perhaps a clear warning somewhere would be better.

netsafe · 2016-08-30T07:25:45Z

@luke-jr and the code is open to every peer, actually - the peer is running an open-source Bitcoin core. What exact do you mean by infringing the license? I see no license is broken here http://www.oracle.com/technetwork/database/berkeleydb/downloads/oslicense-093458.html

luke-jr · 2016-08-30T07:33:19Z

@netsafe It's not enough that someone else is sharing the code; the person running the software would need to do so, or at least provide notice to each peer how to get it. Right now, Bitcoin Core doesn't do even the notice. That being said, skimming over the AGPL again it seems this requirement exists only for modified versions, so it's probably less of an issue than it seems at face value. But IANAL and it seems like not the best idea to have the license transparently change like this.

In any case, I still don't really care strongly either way. :)

netsafe · 2016-08-30T07:41:28Z

@luke-jr I'm not caring that deep too. As far as I understood this situation, AGPL will fire the way we're speaking only if it's a client-server architecture. But in a P2P case - which is a case for Bitcoin - all peers not just should have the same source code, but they're explicitly obliged to : or the network will fall apart because it's nodes won't be able to work together in the same way.

luke-jr · 2016-08-30T07:45:45Z

P2P is just "everyone is a client and server to each other". It's stronger with AGPL, not weaker.

There is absolutely no requirement for all nodes to be running the same source code, only that they be using the same consensus logic, which is a subset of the full program (and doesn't touch the BDB-related code at all).

laanwj · 2016-08-30T08:06:45Z

It might actually be a good idea to fail to build against BDB 6...

Let's not get involved in copyfights here but focus on the technical side - apparently someone wants to fix building with BDB 6, and if the code changes are acceptable (and don't regress BDB 4/5 support), let's just accept that.

netsafe · 2016-08-30T08:24:52Z

@laanwj It does not breaks 4/5 BDB support - test build confirms it too

Official docs http://docs.oracle.com/cd/E17076_02/html/api_reference/CXX/BDB-CXX_APIReference.pdf page 226 :

#include <db_cxx.h>
class DbEnv {
public:
DbEnv(u_int32 flags);
~DbEnv();
DB_ENV *DbEnv::get_DB_ENV();
const DB_ENV *DbEnv::get_const_DB_ENV() const;
static DbEnv *DbEnv::get_DbEnv(DB_ENV *dbenv);
static const DbEnv *DbEnv::get_const_DbEnv(const DB_ENV *dbenv);
...
};

laanwj · 2016-08-30T08:42:31Z

src/wallet/db.cpp

        LogPrintf("CDBEnv::EnvShutdown: Error %d shutting down database environment: %s\n", ret, DbEnv::strerror(ret));
    if (!fMockDb)
-        DbEnv(0).remove(strPath.c_str(), 0);
+        DbEnv((u_int32_t)0).remove(strPath.c_str(), 0);


Would the c++11 keyword nullptr work here?

No, it must be zero and explicitly of type u_int32_t : "The flags parameter must be set to 0." in the docs it's stated strictly

Oh right! I was misreading, you're not casting 0 to a pointer.

paveljanik · 2016-08-30T09:01:27Z

ACK 323a5fe

netsafe · 2016-08-30T09:09:38Z

the configuration string that I'm using for Berkeley DB is - in build_unix folder :

../dist/configure --prefix=/usr --enable-dbm --enable-cxx --enable-compat185 --enable-server --enable-o_direct --with-cryptography=yes --enable-sql --enable-sql_compat --enable-sql_codegen --enable-stl --enable-localization

versions 6.2.23, 5.3.28 and 4.8.30 are producing db_cxx.h that contains the same definition

laanwj · 2016-08-30T10:19:11Z

utACK 323a5fe

sipa · 2016-08-30T13:14:19Z

utACK 323a5fe

323a5fe Berkeley DB v6 compatibility fix (Alexey Vesnin)

Fixes building error looking like this: CXX wallet/libbitcoin_wallet_a-db.o wallet/db.cpp: In member function ‘void CDBEnv::EnvShutdown()’: wallet/db.cpp:46:16: error: call of overloaded ‘DbEnv(int)’ is ambiguous DbEnv(0).remove(strPath.c_str(), 0); ^ wallet/db.cpp:46:16: note: candidates are: In file included from wallet/db.h:21:0, from wallet/db.cpp:6: /usr/include/db_cxx.h:916:2: note: DbEnv::DbEnv(const DbEnv&) DbEnv(const DbEnv &); ^ /usr/include/db_cxx.h:518:2: note: DbEnv::DbEnv(DB_ENV) DbEnv(DB_ENV *dbenv); ^ /usr/include/db_cxx.h:516:2: note: DbEnv::DbEnv(u_int32_t) DbEnv(u_int32_t flags); ^ Makefile:5780: recipe for target 'wallet/libbitcoin_wallet_a-db.o' failed make[2]: ** [wallet/libbitcoin_wallet_a-db.o] Error 1 Github-Pull: bitcoin#8626 Rebased-From: 323a5fe

323a5fe Berkeley DB v6 compatibility fix (Alexey Vesnin)

7105e7a Berkeley DB v6 compatibility fix (Alexey Vesnin) Pull request description: Fixes linking problem as seen on GA CMake-macOS [here](https://github.com/PIVX-Project/PIVX/runs/2032160204). From bitcoin#8626 ACKs for top commit: furszy: utACK 7105e7a Fuzzbawls: utACK 7105e7a Tree-SHA512: d14fe2e24a69a7511fe93526bf7c1a56bbe8cd2e60d95dd29aed8a0e13e92a52270cf44ee38c3a5319177f5f8f55adae4b30bb6a1fb288e7c3d867d467af8d5b

jonasschnelli added Wallet Build system labels Aug 30, 2016

laanwj reviewed Aug 30, 2016
View reviewed changes

laanwj merged commit 323a5fe into bitcoin:master Aug 31, 2016

laanwj added a commit that referenced this pull request Aug 31, 2016

Merge #8626: Berkeley DB v6 compatibility fix

df3f12d

323a5fe Berkeley DB v6 compatibility fix (Alexey Vesnin)

codablock pushed a commit to codablock/dash that referenced this pull request Jan 9, 2018

Merge bitcoin#8626: Berkeley DB v6 compatibility fix

e5702cd

323a5fe Berkeley DB v6 compatibility fix (Alexey Vesnin)

codablock pushed a commit to codablock/dash that referenced this pull request Jan 9, 2018

Merge bitcoin#8626: Berkeley DB v6 compatibility fix

3b45cae

323a5fe Berkeley DB v6 compatibility fix (Alexey Vesnin)

andvgal pushed a commit to energicryptocurrency/gen2-energi that referenced this pull request Jan 6, 2019

Merge bitcoin#8626: Berkeley DB v6 compatibility fix

0421462

323a5fe Berkeley DB v6 compatibility fix (Alexey Vesnin)

random-zebra mentioned this pull request Mar 4, 2021

[Wallet] Berkeley DB v6 compatibility fix PIVX-Project/PIVX#2232

Merged

lyricidal mentioned this pull request Jun 15, 2021

[Upstream] [Wallet] Berkeley DB v6 compatibility fix PRCYCoin/PRCYCoin#58

Merged

bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021

Berkeley DB v6 compatibility fix #8626

Berkeley DB v6 compatibility fix #8626

Uh oh!

Conversation

netsafe commented Aug 30, 2016

Uh oh!

netsafe commented Aug 30, 2016

Uh oh!

jonasschnelli commented Aug 30, 2016

Uh oh!

luke-jr commented Aug 30, 2016

Uh oh!

netsafe commented Aug 30, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

luke-jr commented Aug 30, 2016

Uh oh!

netsafe commented Aug 30, 2016

Uh oh!

luke-jr commented Aug 30, 2016

Uh oh!

laanwj commented Aug 30, 2016

Uh oh!

netsafe commented Aug 30, 2016 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

laanwj Aug 30, 2016

Choose a reason for hiding this comment

Uh oh!

netsafe Aug 30, 2016

Choose a reason for hiding this comment

Uh oh!

laanwj Aug 30, 2016

Choose a reason for hiding this comment

Uh oh!

paveljanik commented Aug 30, 2016

Uh oh!

netsafe commented Aug 30, 2016

Uh oh!

laanwj commented Aug 30, 2016

Uh oh!

sipa commented Aug 30, 2016

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

netsafe commented Aug 30, 2016 •

edited

Loading

netsafe commented Aug 30, 2016 •

edited

Loading