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
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
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.
I think you should fix it properly. All bitcoin related ports are skipped because of this.
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.
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.
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.
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.
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.
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.
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
No. Move bitcoin on db5 and fix the fallout.
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?
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
Reopening per backout in ports 413096 and resetting assignee per ports r413097.
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.
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