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. * Bump PORTREVISON.
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.
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, Matthias
(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} \ yasu@rolling-vm-freebsd1[2035]% ---------------------------------------------------------------------- And got following build logs. 10.4-RELEASE, databases/db5: https://www.utahime.org/FreeBSD/poudriere/data/logs/bulk/104amd64-local/2018-08-01_07h59m29s/logs/db5-5.3.28_6.log 10.4-RELEASE, databases/db6: https://www.utahime.org/FreeBSD/poudriere/data/logs/bulk/104amd64-local/2018-08-01_07h59m29s/logs/db6-6.2.32.log 11.1-RELEASE, databases/db5: https://www.utahime.org/FreeBSD/poudriere/data/logs/bulk/111amd64-local/2018-08-01_08h04m13s/logs/db5-5.3.28_6.log 11.1-RELEASE, databases/db6: https://www.utahime.org/FreeBSD/poudriere/data/logs/bulk/111amd64-local/2018-08-01_08h04m13s/logs/db6-6.2.32.log 11.2-RELEASE, databases/db5: https://www.utahime.org/FreeBSD/poudriere/data/logs/bulk/112amd64-local/2018-08-01_08h07m52s/logs/db5-5.3.28_6.log 11.2-RELEASE, databases/db6: https://www.utahime.org/FreeBSD/poudriere/data/logs/bulk/112amd64-local/2018-08-01_08h07m52s/logs/db6-6.2.32.log 12.0-CURRENT, databases/db5: https://www.utahime.org/FreeBSD/poudriere/data/logs/bulk/curamd64-local/2018-08-01_08h11m48s/logs/db5-5.3.28_6.log 12.0-CURRENT, databases/db6: https://www.utahime.org/FreeBSD/poudriere/data/logs/bulk/curamd64-local/2018-08-01_08h11m48s/logs/db6-6.2.32.log 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 strings. 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 process. * {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.
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 Log: databases/db5, db6: enable DBM compatibility Enable DBM API. [1] Reorder license information of db5/Makefile to fix portlint warning. [1] Bump PORTREVISON. [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 Changes: head/databases/db5/Makefile head/databases/db5/files/patch-src_dbinc_db.in head/databases/db6/Makefile head/databases/db6/files/patch-src_dbinc_db.in head/databases/db6/pkg-plist