[release] Boost 1.69.0 Beta 1 Release Candidate 1
The release candidates for the first 1.69.0 beta release are now available at: https://dl.bintray.com/boostorg/beta/1.69.0.beta.1.rc1/source/ The release notes are not yet available. The updated documentation is not yet available. [ They will be available in a day or two. ] The SHA256 checksums are as follows: db6b346389714647490d6503db881e4178dd8cd498f850999bebf72cacd4c4ed boost_1_69_0_b1_rc1.7z d128c82351becbd37a02b9b4818994d3f66ff8bdbc0a18838206f4c070db97af boost_1_69_0_b1_rc1.tar.bz2 4df6262db53cfd0d0f934cb126f7e48e94872fe4441cbac6bf72a43bfb136a45 boost_1_69_0_b1_rc1.tar.gz e2908e33cc15f92cda06ddde6a3da43b18967a83105355571fc3cf6e75820c7f boost_1_69_0_b1_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Managers
On Mon, Nov 12, 2018 at 7:36 AM Marshall Clow
The release candidates for the first 1.69.0 beta release are now available at:
https://dl.bintray.com/boostorg/beta/1.69.0.beta.1.rc1/source/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
I have built the RC on Mac OS X 10.11 using Apple LLVM version 8.0.0 (clang-800.0.42.1) successfully while specifiying c++03/11/14/1z -- Marshall
On Mon, Nov 12, 2018 at 7:36 AM Marshall Clow
The release candidates for the first 1.69.0 beta release are now available at:
https://dl.bintray.com/boostorg/beta/1.69.0.beta.1.rc1/source/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
I have built the RC on Mac OS X 10.13 using Apple LLVM version 10.0.0 (clang-1000.10.44.4) successfully while specifying c++03/11/14, but failed when specifying c++17/2a, because the Python 2.7 headers shipped with Mac OS 10.13 use the "register" keyword: In file included from /System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/Python.h:85: /System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/unicodeobject.h:534:5: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister] register PyObject *obj, /* Object */ ^~~~~~~~~ -- Marshall
On Mon, Nov 12, 2018 at 7:36 AM Marshall Clow
The release candidates for the first 1.69.0 beta release are now available at:
https://dl.bintray.com/boostorg/beta/1.69.0.beta.1.rc1/source/
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
I have built the RC on Mac OS X 10.13 using a recent trunk build of clang (version 8.0.0 (trunk 346609)) successfully while specifying c++03/11/14, but failed when specifying c++17/2a, because the Python 2.7 headers shipped with Mac OS 10.13 use the "register" keyword: In file included from /System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/Python.h:85: /System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7/unicodeobject.h:534:5: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister] register PyObject *obj, /* Object */ ^~~~~~~~~ (same results as with Apple's clang) -- Marshall
Marshall Clow wrote:
The release candidates for the first 1.69.0 beta release are now available at:
https://dl.bintray.com/boostorg/beta/1.69.0.beta.1.rc1/source/
A change in Boost.Function, https://github.com/boostorg/function/pull/25, has caused an unfortunate regression downstream (in FreeBSD) as reported in https://github.com/boostorg/program_options/issues/65. I think that it would be best to revert the Boost.Function change before releasing the beta. Unrelated, I have a change in SmartPtr, https://github.com/boostorg/smart_ptr/commit/f6c3508aeed7d6f3838015713c48009..., that fixes https://github.com/boostorg/smart_ptr/issues/54, and I'd like to include it in the release. Please let me know if it's OK if I merge this to master before another beta RC is built.
Marshall Clow wrote:
The release candidates for the first 1.69.0 beta release are now available at:
https://dl.bintray.com/boostorg/beta/1.69.0.beta.1.rc1/source/
A change in Boost.Function, https://github.com/boostorg/function/pull/25, has caused an unfortunate regression downstream (in FreeBSD) as reported in https://github.com/boostorg/program_options/issues/65.
I think that it would be best to revert the Boost.Function change before releasing the beta.
I reverted this change on the develop branch and I'd like to merge that to master before the beta.
On 11/13/18 17:42, Peter Dimov via Boost wrote:
Marshall Clow wrote:
The release candidates for the first 1.69.0 beta release are now > available at:
https://dl.bintray.com/boostorg/beta/1.69.0.beta.1.rc1/source/
A change in Boost.Function, https://github.com/boostorg/function/pull/25, has caused an unfortunate regression downstream (in FreeBSD) as reported in https://github.com/boostorg/program_options/issues/65.
I think that it would be best to revert the Boost.Function change before releasing the beta.
I reverted this change on the develop branch and I'd like to merge that to master before the beta.
Looks good to me. Please merge. -- Michael Caisse Ciere Consulting ciere.com
On Mon, Nov 12, 2018 at 6:37 PM Marshall Clow via Boost
The release candidates for the first 1.69.0 beta release are now available at:
...
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
I'd like to ask for permission to merge this commit to master: https://github.com/boostorg/filesystem/commit/7dc1712f2df87f28bfd02ab26d3af2... It fixes Boost.Filesystem compilation on QNX.
On 11/13/18 15:16, Andrey Semashev via Boost wrote:
On Mon, Nov 12, 2018 at 6:37 PM Marshall Clow via Boost
wrote: The release candidates for the first 1.69.0 beta release are now available at:
...
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
I'd like to ask for permission to merge this commit to master:
https://github.com/boostorg/filesystem/commit/7dc1712f2df87f28bfd02ab26d3af2...
It fixes Boost.Filesystem compilation on QNX.
We don't have any QNX testers running. Which targets/environments have you compiled for? -- Michael Caisse Ciere Consulting ciere.com
On 11/14/18 5:01 AM, Michael Caisse via Boost wrote:
On 11/13/18 15:16, Andrey Semashev via Boost wrote:
On Mon, Nov 12, 2018 at 6:37 PM Marshall Clow via Boost
wrote: The release candidates for the first 1.69.0 beta release are now available at:
...
As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
I'd like to ask for permission to merge this commit to master:
https://github.com/boostorg/filesystem/commit/7dc1712f2df87f28bfd02ab26d3af2...
It fixes Boost.Filesystem compilation on QNX.
We don't have any QNX testers running. Which targets/environments have you compiled for?
I have not. The fix comes from a user who has tested that it works. https://github.com/boostorg/filesystem/issues/89 It doesn't affect any other platforms, so I consider it rather safe.
On Wed, Nov 14, 2018 at 12:10 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 11/14/18 5:01 AM, Michael Caisse via Boost wrote:
On 11/13/18 15:16, Andrey Semashev via Boost wrote:
On Mon, Nov 12, 2018 at 6:37 PM Marshall Clow via Boost
wrote: The release candidates for the first 1.69.0 beta release are now
available
at: ... As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
I'd like to ask for permission to merge this commit to master:
https://github.com/boostorg/filesystem/commit/7dc1712f2df87f28bfd02ab26d3af2...
It fixes Boost.Filesystem compilation on QNX.
We don't have any QNX testers running. Which targets/environments have you compiled for?
I have not. The fix comes from a user who has tested that it works.
https://github.com/boostorg/filesystem/issues/89
It doesn't affect any other platforms, so I consider it rather safe.
I think that this can wait until after the beta. -- Marshall
On 11/14/18 7:07 PM, Marshall Clow via Boost wrote:
On Wed, Nov 14, 2018 at 12:10 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 11/14/18 5:01 AM, Michael Caisse via Boost wrote:
On 11/13/18 15:16, Andrey Semashev via Boost wrote:
I'd like to ask for permission to merge this commit to master:
https://github.com/boostorg/filesystem/commit/7dc1712f2df87f28bfd02ab26d3af2...
It fixes Boost.Filesystem compilation on QNX.
We don't have any QNX testers running. Which targets/environments have you compiled for?
I have not. The fix comes from a user who has tested that it works.
https://github.com/boostorg/filesystem/issues/89
It doesn't affect any other platforms, so I consider it rather safe.
I think that this can wait until after the beta.
Can I merge this change now?
On Sun, Nov 18, 2018 at 11:46 PM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 11/14/18 7:07 PM, Marshall Clow via Boost wrote:
On Wed, Nov 14, 2018 at 12:10 AM Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 11/14/18 5:01 AM, Michael Caisse via Boost wrote:
On 11/13/18 15:16, Andrey Semashev via Boost wrote:
I'd like to ask for permission to merge this commit to master:
https://github.com/boostorg/filesystem/commit/7dc1712f2df87f28bfd02ab26d3af2...
It fixes Boost.Filesystem compilation on QNX.
We don't have any QNX testers running. Which targets/environments have you compiled for?
I have not. The fix comes from a user who has tested that it works.
https://github.com/boostorg/filesystem/issues/89
It doesn't affect any other platforms, so I consider it rather safe.
I think that this can wait until after the beta.
Can I merge this change now?
Yes. -- Marshall
Marshall Clow via Boost-users
The release candidates for the first 1.69.0 beta release are now available As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.
On FreeBSD a number of Boost consumers don't build due to these: https://github.com/boostorg/locale/pull/15 (not in master) https://github.com/boostorg/program_options/issues/65 (ignore, already reverted) https://github.com/boostorg/regex/issues/72 Otherwise, I've patched all consumers downstream: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=232525 (after testing on FreeBSD 11.2 amd64 with Clang/libc++ 6.0)
On 14/11/2018 15:38, Jan Beich via Boost wrote:
Marshall Clow via Boost-users
writes: The release candidates for the first 1.69.0 beta release are now available As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. On FreeBSD a number of Boost consumers don't build due to these: https://github.com/boostorg/regex/issues/72
That issue relates to something that we have never supported: building a library with one compiler and then using with another. At the very least it is not a new issue. John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
John Maddock wrote:
That issue relates to something that we have never supported: building a library with one compiler and then using with another.
It's more like we've always supported it, but didn't know that we did until it broke. :-)
On 14/11/2018 18:20, Peter Dimov via Boost wrote:
John Maddock wrote:
That issue relates to something that we have never supported: building a library with one compiler and then using with another.
It's more like we've always supported it, but didn't know that we did until it broke. :-)
Really? There have been no code changes, it's always been this, and I've always assumed that this would not work. John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
John Maddock wrote:
On 14/11/2018 18:20, Peter Dimov via Boost wrote:
John Maddock wrote:
That issue relates to something that we have never supported: building a library with one compiler and then using with another.
It's more like we've always supported it, but didn't know that we did until it broke. :-)
Really?
In general, building with g++ and using from clang++ is commonplace on Linux. And apparently so is building with one -std and using with another. I admit however that I didn't know that the opposite (building with the system clang++ and using from g++) was a practice on FreeBSD.
There have been no code changes, it's always been this, and I've always assumed that this would not work.
It was probably the switch to hidden visibility that broke it.
participants (6)
-
Andrey Semashev
-
Jan Beich
-
John Maddock
-
Marshall Clow
-
Michael Caisse
-
Peter Dimov