Bug 208488 - databases/db48: rename atomic_init to prevent C++ <atomic> collisions
Summary: databases/db48: rename atomic_init to prevent C++ <atomic> collisions
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: freebsd-ports-bugs mailing list
URL:
Keywords:
Depends on:
Blocks: 208158
  Show dependency treegraph
 
Reported: 2016-04-03 18:56 UTC by Dimitry Andric
Modified: 2016-04-17 20:52 UTC (History)
4 users (show)

See Also:
mandree: maintainer-feedback-


Attachments
Rename atomic_init to db_atomic_init to prevent C++ <atomic> collisions (522 bytes, patch)
2016-04-03 18:56 UTC, Dimitry Andric
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitry Andric freebsd_committer 2016-04-03 18:56:19 UTC
Created attachment 168938 [details]
Rename atomic_init to db_atomic_init to prevent C++ <atomic> collisions

During the exp-run in bug 208158, it was found that databases/db48 gives errors with libc++ 3.8.0 [1]:

In file included from ./../dist/../cxx/cxx_db.cpp:13:
In file included from ./db_cxx.h:55:
In file included from /usr/include/c++/v1/iostream:38:
In file included from /usr/include/c++/v1/ios:216:
In file included from /usr/include/c++/v1/__locale:15:
In file included from /usr/include/c++/v1/string:439:
In file included from /usr/include/c++/v1/algorithm:628:
In file included from /usr/include/c++/v1/memory:616:
/usr/include/c++/v1/atomic:1107:13: error: expected unqualified-id
atomic_init(volatile atomic<_Tp>* __o, _Tp __d) _NOEXCEPT
            ^
/usr/include/c++/v1/atomic:1107:13: error: expected ')'
/usr/include/c++/v1/atomic:1107:1: note: to match this '('
atomic_init(volatile atomic<_Tp>* __o, _Tp __d) _NOEXCEPT
^
./../dist/../dbinc/atomic.h:73:30: note: expanded from macro 'atomic_init'
#define atomic_init(p, val)     ((p)->value = (val))
                                 ^

This is because dbinc/atomic.h redefines atomic_init, a function from C++'s <atomic> header, as a macro.  Similar to the databases/db5 port, add a post-patch REINPLACE_CMD line to rename those instances to db_atomic_init.

[1] http://package18.nyi.freebsd.org/data/headamd64PR208158-default/2016-03-22_18h30m05s/logs/errors/db48-4.8.30.0_2.log
Comment 1 commit-hook freebsd_committer 2016-04-03 22:15:39 UTC
A commit references this bug:

Author: mandree
Date: Sun Apr  3 22:15:36 UTC 2016
New revision: 412492
URL: https://svnweb.freebsd.org/changeset/ports/412492

Log:
  Mark unsupported on FreeBSD 11-CURRENT after clang 3.8 import.
  Bump expiration date.

  Submitted by: dim@
  PR:           208488

Changes:
  head/databases/db48/Makefile
Comment 2 Matthias Andree freebsd_committer 2016-04-03 22:15:52 UTC
Hi Dimitry,

we should not patch up db48, this is in order to discourage people from using it for new projects or scenarios.  I'll mark db48 unsupported on newer FreeBSD 11 OSVERSIONS.

People should instead upgrade to db5.
Comment 3 Tijl Coosemans freebsd_committer 2016-04-07 18:51:50 UTC
I think you should fix it properly.  All bitcoin related ports are skipped because of this.
Comment 4 Matthias Andree freebsd_committer 2016-04-07 19:09:52 UTC
We've been dicussing *coin ports and their dependency on the obsolete and obviously decrepit db48 for ages, more than a year.  

They rely on irrelevant implementation details or artifacts of db48, which is used as the fallacious argument why we must maintain db48 and cannot remove it.

The essence of this particular problem report is that the *coin ports will not run on 11-RELEASE machines later on.  But it is about time that the *coin upstreams got their act together and saw to developing and deploying solutions that get the reliance on artifacts such as page lock count limits in a particular instance of a database out of their system.  They've been discussing leveldb many months ago. 

If however they are trying to sit this design flaw out they'll hurt and ache only more the longer they wait.  Fix the real issue, not some side show.
Comment 5 Tijl Coosemans freebsd_committer 2016-04-07 19:34:12 UTC
As a bitcoin user I don't care about any of your points.  I just want bitcoin working.  If there's some problem maintaining db48 discuss that with bitcoin upstream.  Be very frank about it if necessary, but don't hold users hostage for it.
Comment 6 Matthias Andree freebsd_committer 2016-04-07 20:22:39 UTC
Tijl, db48 has been dead for six years now (that's when db5.0 was released) -- if you need bitcoin to work in the future, then invest your energy into bitcoin proper, rather than trying to keep an unsupported database around that prevents bitcoin from scaling better.

Bitcoin does not "just work", it merely happens to still be working in spite of its design flaws.

Rather than relying on implicit limits of db48 for the wallet, the bitcoin authors can easily recreate the artificial limits of db48 that have been used as fallacious argument that they "cannot" use db 5.x, and they may need to lay out minimum client revisions for certain deadline dates to keep the system kicking and avoid chain splits.

BTW they meant to move away from BerkeleyDB with bitcoin 0.8 but apparently failed to.

Again, talk to the maintainer of your preferred bitcoin port and talk to the upstream maintainers.

FreeBSD 10.3 is going to be supported until end of April 2018, and I shall pull the plug on db48 the day when FreeBSD 10 goes out of support - that is more than eight years (!) after its upstream EOL.  Bitcoin has released newer versions since, 

By then we've prolonged its useless life for three and a half years from my starting the databases/db* cleanup, and that's three and a half wasted years on getting bitcoin forward.

I'll have no more of this discussion, and no more of the being told down for not supporting design flaws in other immature software.

See to it that bitcoin can use a newer db, or a different database, by then, and please do file corresponding PRs against your favourite - or all - bitcoin ports.
Comment 7 Tijl Coosemans freebsd_committer 2016-04-08 07:29:37 UTC
1) We want A and A depends on B.
2) B is broken
3) You happen to be the maintainer of B

Conclusion: either you fix B or you release maintainership.  Telling users they somehow need to find a way to let A not depend on B is completely unacceptable.
Comment 8 Matthias Andree freebsd_committer 2016-04-08 07:55:59 UTC
Accept the fact that upstream package B got EOL'd six years ago, and deal with it.  B has a newer sequel B_new, so A can use B_new.

There have been many releases of A in the past years, that made more radical and backwards-incompatible changes, than just moving onto B_new.  

Come on, who needs a *particular* database version for storing a handful of secret keys?  It's for the wallet only, nothing spectacular.  You could use SQLite, Kyotocabinet, GDBM, leveldb (which was even discussed for use in bitcoin 0.8).

I shall not be path of least resistance, because it's also the wrong path.
No matter how hard you're trying to poke your head through this brick wall, I will not respond to any more discussions that reiterate bogus expectations, arguments, whatever.  

The only middle ground I'd accept for the time being is leaving 11 support without the C++ parts, if that helps.  Someone else tell me.

You have 752 days left until db48 will be gone along with the 10.3-RELEASE support.  Use them, and talk to the right guys to get their act together.
Comment 9 Tijl Coosemans freebsd_committer 2016-04-08 08:10:52 UTC
Bitcoin needs libdb_cxx-4.8.so.0 so leaving C++ out doesn't help.

All your arguments are a variation on "I don't like that A depends on B".  They are completely irrelevant.  You have two options.  Fix B or release your maintainer lock over it.  Make a choice.  There's no third option.
Comment 10 Baptiste Daroussin freebsd_committer 2016-04-09 13:10:22 UTC
As much as I do like removing EOL softwares, bitcoin software are still rather importants,

In that case I strongly support tijl we have a fix we should commit it.

And yes people should "pressure" bitcoins upstream to make work with a modern bdb or anything else, looking at the issues open upstream (bitcoin) it is not trivial.

Please either drop maintainership on bdb48 or commit the patch
Comment 11 Matthias Andree freebsd_committer 2016-04-10 16:38:17 UTC
No. Move bitcoin on db5 and fix the fallout.
Comment 12 Baptiste Daroussin freebsd_committer 2016-04-10 17:33:10 UTC
Just look at the issues on the bitcoin bug tracker, it is not just moving do bdb5 is has more inpacts and is not as simple as it looks like.

Both old and new version are not conflicting, so one can just remove the db 4.8 entry from bsd.databases.mk and make the bitcoin ports directly rely on db4.8 so it is out of your scope.

There is nothing very problematic as keeping bdb 4.8. Why aren't you so picky at removing glib 1.2 in this case?
Comment 13 commit-hook freebsd_committer 2016-04-11 19:57:11 UTC
A commit references this bug:

Author: bapt
Date: Mon Apr 11 19:57:03 UTC 2016
New revision: 413084
URL: https://svnweb.freebsd.org/changeset/ports/413084

Log:
  Fix build with libc++ 3.8

  PR:		208488
  Submitted by:	dim
  With hat:	portmgr

Changes:
  head/databases/db48/Makefile
Comment 14 Jan Beich freebsd_committer 2016-04-12 06:12:59 UTC
Reopening per backout in ports r413096 and resetting assignee per ports r413097.
Comment 15 Peter Wemm freebsd_committer freebsd_triage 2016-04-14 02:02:08 UTC
When is this going to be removed?  Fixing it isn't a fix unless the retarded lock-out is removed.


.if ${OSVERSION} >= 1100101
IGNORE=         db48 is not supported on FreeBSD 11+ with clang 3.8 - upgrade to db5
.endif


Since the maintainer has expressed extreme hostility to this port, could we please either:
1) take it away from them by force, or
2) create db48-fixed and have the dependencies use that instead?

The current situation is not acceptable.
Comment 16 commit-hook freebsd_committer 2016-04-17 20:52:03 UTC
A commit references this bug:

Author: bapt
Date: Sun Apr 17 20:51:22 UTC 2016
New revision: 413541
URL: https://svnweb.freebsd.org/changeset/ports/413541

Log:
  Fix build with libc++ 3.8

  PR:		208488
  Submitted by:	dim

Changes:
  head/databases/db48/Makefile