Bug 230191 - databases/db5 databases/db6: Enable DBM compatible functions and etc
Summary: databases/db5 databases/db6: Enable DBM compatible functions and etc
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Matthias Andree
Depends on:
Blocks: 230289
  Show dependency treegraph
Reported: 2018-07-30 14:36 UTC by Yasuhiro KIMURA
Modified: 2018-08-05 10:22 UTC (History)
0 users

See Also:
mandree: maintainer-feedback+

patch file (2.09 KB, patch)
2018-07-30 14:36 UTC, Yasuhiro KIMURA
no flags Details | Diff
updated patch file (3.82 KB, patch)
2018-07-31 07:36 UTC, Yasuhiro KIMURA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yasuhiro KIMURA 2018-07-30 14:36:43 UTC
Created attachment 195635 [details]
patch file

* Add --enable-dbm to CONFIGURE_ARGS in order to enable DBM compatible functions.
* Add 'USE_GCC=yes' because build fails with clang++ and libc++. See https://community.oracle.com/thread/3952592 for detail.
* Reorder license information of db5/Makefile to fix portlint warning.
Comment 1 Yasuhiro KIMURA 2018-07-31 07:36:18 UTC
Created attachment 195681 [details]
updated patch file

Add command creating symbolic link such as ${PREFIX}/lib/libdb-6.so to post-install target of db6/Makefile.
So please commit attached patch instead of original one.
Comment 2 Matthias Andree freebsd_committer 2018-07-31 09:13:00 UTC
Hello Kimura-san,

is there evidence (build log) that we have failing builds? The thread you are linking to is two years old, and I would rather use patches than USE_GCC - I am loathe to add USE_GCC so that we do not change the default C++ standard (template) libraries for ports that require db5/db6.

Also, what is the use case for enabling the DBM interface? It appears to trigger incompatibilities with libc++ in the first place, according to the thread you are linking to.

Best regards,
Comment 3 Yasuhiro KIMURA 2018-08-01 01:04:56 UTC
(In reply to Matthias Andree from comment #2)

> is there evidence (build log) that we have failing builds?

I applied following patch to port tree and build database/db[56] with poudriere and 10.4-RELEASE/11.1-RELEASE/11.2-RELEASE/12.0-CURRENT(r336739) jails.

yasu@rolling-vm-freebsd1[2033]% svn info
Path: .
Working Copy Root Path: /usr0/freebsd/ports/head
URL: https://svn.freebsd.org/ports/head
Relative URL: ^/head
Repository Root: https://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 475999
Node Kind: directory
Schedule: normal
Last Changed Author: gahr
Last Changed Rev: 475999
Last Changed Date: 2018-07-31 22:05:38 +0900 (Tue, 31 Jul 2018)

yasu@rolling-vm-freebsd1[2034]% svn diff
Index: databases/db5/Makefile
--- databases/db5/Makefile      (revision 475999)
+++ databases/db5/Makefile      (working copy)
@@ -23,7 +23,7 @@
 BDBVER=                ${PORTVERSION:R}
 BDBMAJ=                ${BDBVER:R}
-CONFIGURE_ARGS=        --enable-cxx --enable-stl \
+CONFIGURE_ARGS=        --enable-cxx --enable-stl --enable-dbm \
                --enable-compat185 --enable-dump185 \
                --includedir=${PREFIX}/include/${PORTNAME} \
                --libdir=${PREFIX}/lib/${PORTNAME} \
Index: databases/db6/Makefile
--- databases/db6/Makefile      (revision 475999)
+++ databases/db6/Makefile      (working copy)
@@ -19,7 +19,7 @@
 BDBVER=                ${PORTVERSION:R}
 BDBMAJ=                ${BDBVER:R}
-CONFIGURE_ARGS=        --enable-cxx --enable-stl \
+CONFIGURE_ARGS=        --enable-cxx --enable-stl --enable-dbm \
                --enable-compat185 --enable-dump185 \
                --includedir=${PREFIX}/include/${PORTNAME} \
                --libdir=${PREFIX}/lib/${PORTNAME} \

And got following build logs.

10.4-RELEASE, databases/db5:
10.4-RELEASE, databases/db6:
11.1-RELEASE, databases/db5:
11.1-RELEASE, databases/db6:
11.2-RELEASE, databases/db5:
11.2-RELEASE, databases/db6:
12.0-CURRENT, databases/db5:
12.0-CURRENT, databases/db6:

Build succeeds with 10.4-RELEASE, but fails with 11.1-RELEASE and later.

> Also, what is the use case for enabling the DBM interface?

My intention is adding native Berkeley DB support to 'DBM' class library of Ruby language on FreeBSD. Document says as following.

The DBM class provides a wrapper to a Unix-style
{dbm}[http://en.wikipedia.org/wiki/Dbm] or Database Manager library.

Dbm databases do not have tables or columns; they are simple key-value data
stores, like a Ruby Hash except not resident in RAM. Keys and values must be

The exact library used depends on how Ruby was compiled. It could be any of
the following:

* The original ndbm library is released in 4.3BSD. It is based on dbm library
  in Unix Version 7 but has different API to support multiple databases in a
* {Berkeley DB}[http://en.wikipedia.org/wiki/Berkeley_DB] versions 1 thru 5,
  also known as BDB and Sleepycat DB, now owned by Oracle Corporation.
* Berkeley DB 1.x, still found in 4.4BSD derivatives (FreeBSD, OpenBSD, etc).
* {gdbm}[http://www.gnu.org/software/gdbm/], the GNU implementation of dbm.
* {qdbm}[http://fallabs.com/qdbm/index.html], another open source
  reimplementation of dbm.

All of these dbm implementations have their own Ruby interfaces available,
which provide richer (but varying) APIs.

On many Linux distributions some version of Berkeley DB is used as backend. But on FreeBSD dbm_* functions in libc is used. Instead there is databases/ruby-bdb port. This port add support of Berkeley DB to DBM class of Ruby. However there is one problem about it. Since it accesses to internal data structure of Ruby implementation whose compatibility is not guaranteed, it sometimes got broken when new version of Ruby (2.x -> 2.x+1) is released. It happened when Ruby 2.1, 2.3 and 2.5 were released. Right now it is still broken with 2.5 and I think there is little chance the breakage is fixed. So I would like to add native Berkeley DB support to 'DBM' class directly. And implementation of 'DBM' class uses dbm_{open,close,store,delete,...} functions to access backend DB libraries. That why I would like to enable DBM compatible functions database/db[56] ports.

Since adding GCC as dependency is huge overhead when building package and there are many ports that depends on Berkeley DB, I also would like to avoid to use USE_GCC if possible. At first I tried to use '-stdlib=libstdc++' option of clang++. But unfortunately this option is broken with both base and ports clang++ (See bug #230184 and Bug #230185 for detail). Next I searched web hoping someone already made patch to fix this problem. But what I found is only discussion in support page referred in comment #0. So right now I have no way to avoid to use USE_GCC.
Comment 4 commit-hook freebsd_committer 2018-08-02 16:05:41 UTC
A commit references this bug:

Author: mandree
Date: Thu Aug  2 16:05:17 UTC 2018
New revision: 476241
URL: https://svnweb.freebsd.org/changeset/ports/476241

  databases/db5, db6: enable DBM compatibility

  Enable DBM API. [1]
  Reorder license information of db5/Makefile to fix portlint warning. [1]
  Add command creating symbolic link such as ${PREFIX}/lib/libdb-6.so to
  post-install target of db6/Makefile. [1]

  Instead of USE_GCC, patch src/dbinc/db.in to not expose the store() macro under C++.
  Mark db6 broken on MIPS64 for now, we do not have a workable MUTEX implementation.
  Unbreak build on AARCH64, where the db6 autoconfiguration chooses the wrong MUTEX.

  PR:		230191
  Submitted by:	Yasuhiro Kimura