-
Notifications
You must be signed in to change notification settings - Fork 35.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build: compile univalue as c++11 #12467
Conversation
Grr, there's a bug in the macro's handling of subdirs. I'll have to fix this up next week. |
Concept ACK.
There are certainly some rough edge cases, but in theory (no compiler bugs) this should be ok, right? Is there any official guideline about this? Doesn't building against system libraries have the same risks? You can never be sure what c++ standard they were compiled with, certainly not with compilers changing the default all the time. |
68b0fbc
to
812e171
Compare
@laanwj I think we're probably ok here, but I have no idea what happens when differing abi's get linked in together. This could certainly be a problem if univalue was built as a shared lib though, as we could miss thrown exceptions due to differing type signatures. IIRC we actually had that issue at some point catching boost exceptions. |
This needs a rebase. |
812e171
to
b8fa047
Compare
Also don't set the value if it's already set. This allows the value to be updated then passed to a subconfigure, which would otherwise be reinitialized by the config.site
AX_SUBDIRS_CONFIGURE allows us to cleanly add/remove/filter what gets passed to subconfigures. This should be a no op.
Once we're certain that our CXX is compiling as c++11, pass it to univalue for use there as well. This avoids having a binary trying to conform to 2 abi's simultaneously.
b8fa047
to
8816f3d
Compare
Travis fails with
|
@theuni ping |
@theuni Do you want to get this into 0.17.0? |
This hit an annoying snag and didn't end up working. Closing. |
This addresses issues like the one in bitcoin#12467, where some of our compiler flags end up being dropped during the subconfigure of Univalue. Specifically, we're still using the compiler-default c++ version rather than forcing c++11. We can drop the need subconfigure completely in favor of a tighter build integration, where the sources are listed separately from the build recipes, so that they may be included directly by upstream projects. This is similar to the way leveldb build integration works in Core. Upstream benefits of this approach include: Better caching (for ex. ccache and autoconf) No need for a slow subconfigure No more missing compile flags Compile only the objects needed There are no benefits to Univalue itself that I can think of. These changes should be a no-op there, and to downstreams as well until they take advantage of the new sources.mk. Once merged, This Core branch is ready-ish for PR, and takes advantage of the features added here. This also removes the option to use an external univalue to avoid similar ABI issues with mystery binaries.
Requires bitcoin-core/univalue-subtree#19 . This addresses issues like the one in bitcoin#12467, where some of our compiler flags end up being dropped during the subconfigure of Univalue. Specifically, we're still using the compiler-default c++ version rather than forcing c++11. We can drop the need subconfigure completely in favor of a tighter build integration, where the sources are listed separately from the build recipes, so that they may be included directly by upstream projects. This is similar to the way leveldb build integration works in Core. Upstream benefits of this approach include: Better caching (for ex. ccache and autoconf) No need for a slow subconfigure No more missing compile flags Compile only the objects needed There are no benefits to Univalue itself that I can think of. These changes should be a no-op there, and to downstreams as well until they take advantage of the new sources.mk. Once merged, This Core branch is ready-ish for PR, and takes advantage of the features added here. This also removes the option to use an external univalue to avoid similar ABI issues with mystery binaries.
Requires bitcoin-core/univalue-subtree#19 . This addresses issues like the one in bitcoin#12467, where some of our compiler flags end up being dropped during the subconfigure of Univalue. Specifically, we're still using the compiler-default c++ version rather than forcing c++17. We can drop the need subconfigure completely in favor of a tighter build integration, where the sources are listed separately from the build recipes, so that they may be included directly by upstream projects. This is similar to the way leveldb build integration works in Core. Core benefits of this approach include: - Better caching (for ex. ccache and autoconf) - No need for a slow subconfigure - Faster autoconf - No more missing compile flags - Compile only the objects needed There are no benefits to Univalue itself that I can think of. These changes should be a no-op there, and to downstreams as well until they take advantage of the new sources.mk. This also removes the option to use an external univalue to avoid similar ABI issues with mystery binaries.
Requires bitcoin-core/univalue-subtree#19 . This addresses issues like the one in bitcoin#12467, where some of our compiler flags end up being dropped during the subconfigure of Univalue. Specifically, we're still using the compiler-default c++ version rather than forcing c++17. We can drop the need subconfigure completely in favor of a tighter build integration, where the sources are listed separately from the build recipes, so that they may be included directly by upstream projects. This is similar to the way leveldb build integration works in Core. Core benefits of this approach include: - Better caching (for ex. ccache and autoconf) - No need for a slow subconfigure - Faster autoconf - No more missing compile flags - Compile only the objects needed There are no benefits to Univalue itself that I can think of. These changes should be a no-op there, and to downstreams as well until they take advantage of the new sources.mk. This also removes the option to use an external univalue to avoid similar ABI issues with mystery binaries.
Reported by irc user (and maybe github user?) @esotericnonsense.
Building bitcoin as c++11 and univalue as c++03/c++14 (depending on compiler version) is pretty scary. It's surprising that this hasn't caused any issues yet.
I'm afraid the fix is a big pile of autotools nonsense, but the changes are pretty straightforward:
The good news is that this makes it much easier to tweak subconfigure args in the future.