[release] Boost 1.70.0 Beta 1 is now available
[ resending with a non-empty subject line ] Boost release 1.70.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.70.0.beta1/source/> The SHA256 checksums are as follows: dbf89645e509acb2e53eac3c633834f1dec80bd8622e6e652a9741dcf0807f17 ./boost_1_70_0_b1.7z 957b984b58656a3ec00661ecad7ef82e3a094bad36e37b9e6624843237854679 ./boost_1_70_0_b1.tar.bz2 76d149c1fb9e8a5ceb3bc1e5587edc40fa79a43e8b990d877c2210f0382b9421 ./boost_1_70_0_b1.tar.gz 71e990b2c26880521fd98459b184ee172ce1c46dcf554b6eaab7776b8b6369a6 ./boost_1_70_0_b1.zip For details of what's in the release, see < https://www.boost.org/users/history/version_1_70_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team
On 13.03.19 15:49, Marshall Clow via Boost wrote:
For details of what's in the release, see < https://www.boost.org/users/history/version_1_70_0.html>.
Please download the beta, give it a try, and report any problems you encounter.
I want to report a problem. Boost.Test is broken when cross-compiling for Windows on Linux using a case-sensitive file system because it #includes <Windows.h> instead of <windows.h> on line 32 of boost/test/utils/timer.hpp. -- Rainer Deyke (rainerd@eldwood.com)
On Tue, 19 Mar 2019 at 11:44, Rainer Deyke via Boost <boost@lists.boost.org> wrote:
Boost.Test is broken when cross-compiling for Windows on Linux using a case-sensitive file system because it #includes <Windows.h> instead of <windows.h>
The correct header should be/is 'Windows.h', it's capitalized, MinGW has a similar problem, IIRC. degski -- *"Big boys don't cry" - **Eric Stewart, Graham Gouldman*
On 19.03.19 12:40, degski via Boost wrote:
On Tue, 19 Mar 2019 at 11:44, Rainer Deyke via Boost <boost@lists.boost.org> wrote:
Boost.Test is broken when cross-compiling for Windows on Linux using a case-sensitive file system because it #includes <Windows.h> instead of <windows.h>
The correct header should be/is 'Windows.h', it's capitalized, MinGW has a similar problem, IIRC.
It's not capitalized in the 30 instances of '#include <windows.h>' in Boost header files, including 3 from Boost.Test, and it's not capitalized on my file system. It's also not capitalized on the Wikipedia page, it's not /consistently/ capitalized by Microsoft themselves, and even Microsoft are switching to lower case where portability matters: see https://github.com/Microsoft/WinObjC/commit/9e55e2a7cb67fe9a4b3fffb491f7eb62.... -- Rainer Deyke (rainerd@eldwood.com)
On 19.03.19 16:08, Rainer Deyke via Boost wrote:
On 19.03.19 12:40, degski via Boost wrote:
On Tue, 19 Mar 2019 at 11:44, Rainer Deyke via Boost <boost@lists.boost.org> wrote:
Boost.Test is broken when cross-compiling for Windows on Linux using a case-sensitive file system because it #includes <Windows.h> instead of <windows.h>
The correct header should be/is 'Windows.h', it's capitalized, MinGW has a similar problem, IIRC.
It's not capitalized in the 30 instances of '#include <windows.h>' in Boost header files, including 3 from Boost.Test, and it's not capitalized on my file system. It's also not capitalized on the Wikipedia page, it's not /consistently/ capitalized by Microsoft themselves, and even Microsoft are switching to lower case where portability matters: see https://github.com/Microsoft/WinObjC/commit/9e55e2a7cb67fe9a4b3fffb491f7eb62....
I just took the way it appears in the documentation: https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-cr... Windows file system does not care whether it is capitalized or not, and MinGW should not be sensitive to that. I've seen only this header with an upper case W so far, this is typically a Linux issue. Raffi
On Fri, 22 Mar 2019 at 02:13, Raffi Enficiaud via Boost < boost@lists.boost.org> wrote:
On 19.03.19 16:08, Rainer Deyke via Boost wrote:
On 19.03.19 12:40, degski via Boost wrote:
On Tue, 19 Mar 2019 at 11:44, Rainer Deyke via Boost <boost@lists.boost.org> wrote:
Boost.Test is broken when cross-compiling for Windows on Linux using a case-sensitive file system because it #includes <Windows.h> instead of <windows.h>
The correct header should be/is 'Windows.h', it's capitalized, MinGW has a similar problem, IIRC.
It's not capitalized in the 30 instances of '#include <windows.h>' in Boost header files, including 3 from Boost.Test, and it's not capitalized on my file system. It's also not capitalized on the Wikipedia page, it's not /consistently/ capitalized by Microsoft themselves, and even Microsoft are switching to lower case where portability matters: see
https://github.com/Microsoft/WinObjC/commit/9e55e2a7cb67fe9a4b3fffb491f7eb62... .
I just took the way it appears in the documentation:
https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-cr...
I don't know why you refer to that page, but when you get to the business-end of that page, the "what to do bit", you find: *Minimum supported client* Windows XP [desktop apps | UWP apps] *Minimum supported server* Windows Server 2003 [desktop apps | UWP apps] *Target Platform* Windows *Header* synchapi.h (include Windows.h) *Library* Kernel32.lib *DLL* Kernel32.dll Where you can see that Windows.h is clearly capitalized (while other headers, clearly (and correctly) are not). Windows file system does not care whether it is capitalized or not, and
MinGW should not be sensitive to that.
It does actually, ntfs is case-sensitive. For backward compatibility (I presume), explorer, cmd.exe etc, add a case-insensitive layer on top of the native file-system. Clang-cl warns about mis-matches in casing. degski -- *"Big boys don't cry" - **Eric Stewart, Graham Gouldman*
On 22.03.19 06:32, degski via Boost wrote:
On Fri, 22 Mar 2019 at 02:13, Raffi Enficiaud via Boost < boost@lists.boost.org> wrote:
On 19.03.19 16:08, Rainer Deyke via Boost wrote:
On 19.03.19 12:40, degski via Boost wrote:
On Tue, 19 Mar 2019 at 11:44, Rainer Deyke via Boost <boost@lists.boost.org> wrote:
Boost.Test is broken when cross-compiling for Windows on Linux using a case-sensitive file system because it #includes <Windows.h> instead of <windows.h>
The correct header should be/is 'Windows.h', it's capitalized, MinGW has a similar problem, IIRC.
It's not capitalized in the 30 instances of '#include <windows.h>' in Boost header files, including 3 from Boost.Test, and it's not capitalized on my file system. It's also not capitalized on the Wikipedia page, it's not /consistently/ capitalized by Microsoft themselves, and even Microsoft are switching to lower case where portability matters: see
https://github.com/Microsoft/WinObjC/commit/9e55e2a7cb67fe9a4b3fffb491f7eb62... .
I just took the way it appears in the documentation:
https://docs.microsoft.com/en-us/windows/desktop/api/synchapi/nf-synchapi-cr...
I don't know why you refer to that page, but when you get to the business-end of that page, the "what to do bit", you find:
This is the function that was pulling Windows.h and that was causing this issue.
*Minimum supported client* Windows XP [desktop apps | UWP apps] *Minimum supported server* Windows Server 2003 [desktop apps | UWP apps] *Target Platform* Windows *Header* synchapi.h (include Windows.h) *Library* Kernel32.lib *DLL* Kernel32.dll
Exactly, and every reference to Windows.h is with W. AFAIR, it was always like this.
On Fri, 22 Mar 2019 at 08:33, Raffi Enficiaud via Boost < boost@lists.boost.org> wrote:
Exactly, and every reference to Windows.h is with W. AFAIR, it was always like this.
I misunderstood the intent of what you we're saying. Whatever commits do, whatever MinGW does, fact is that Windows.h is capitalized (and always has been). Being sloppy about it goes un-punished on Windows due to the legacy of FAT(32) still en-grained in the OS, but bites elsewhere. I might be wrong but I'm quite sure I have run into this problem with MinGW in the past. degski -- *"Big boys don't cry" - **Eric Stewart, Graham Gouldman*
degski wrote:
On Fri, 22 Mar 2019 at 08:33, Raffi Enficiaud via Boost <boost@lists.boost.org> wrote:
Exactly, and every reference to Windows.h is with W. AFAIR, it was always like this.
I misunderstood the intent of what you we're saying. Whatever commits do, whatever MinGW does, fact is that Windows.h is capitalized (and always has been).
Your "always" doesn't go far back enough. It's capitalized in VS2005, and I have no earlier versions here to check, but my memory tells me that there was a time it wasn't. Borland 5.5.1 doesn't capitalize it, and windowsx.h is not capitalized in the Platform SDK. Plus, all Windows programming examples and books I remember used #include <windows.h>, without capitalization.
On Fri, 22 Mar 2019 at 14:37, Peter Dimov via Boost <boost@lists.boost.org> wrote:
Plus, all Windows programming examples and books I remember used #include <windows.h>, without capitalization.
Casual verification confirms this. Aesthetically [and if not just for simplicity], I would like them to be all minors, all of them, but they are not :-(. degski -- *"Big boys don't cry" - **Eric Stewart, Graham Gouldman*
On 22.03.19 13:36, Peter Dimov via Boost wrote:
degski wrote:
On Fri, 22 Mar 2019 at 08:33, Raffi Enficiaud via Boost <boost@lists.boost.org> wrote:
Exactly, and every reference to Windows.h is with W. AFAIR, it was > always like this.
I misunderstood the intent of what you we're saying. Whatever commits do, whatever MinGW does, fact is that Windows.h is capitalized (and always has been).
Your "always" doesn't go far back enough. It's capitalized in VS2005, and I have no earlier versions here to check, but my memory tells me that there was a time it wasn't. Borland 5.5.1 doesn't capitalize it, and windowsx.h is not capitalized in the Platform SDK. Plus, all Windows programming examples and books I remember used #include <windows.h>, without capitalization.
Yes, as far as I remember (AFAIR), which is the context of "always". My English has "always" been a bit broken. All in all, this is a non-issue on Windows, and I failed to catch the problem before it reached master with my CI. It is good that this has been caught before the release. Does anyone cross-compile for Windows on Travis? Raffi
On Tue, Mar 19, 2019 at 2:43 AM Rainer Deyke via Boost < boost@lists.boost.org> wrote:
On 13.03.19 15:49, Marshall Clow via Boost wrote:
For details of what's in the release, see < https://www.boost.org/users/history/version_1_70_0.html>.
Please download the beta, give it a try, and report any problems you encounter.
I want to report a problem.
Boost.Test is broken when cross-compiling for Windows on Linux using a case-sensitive file system because it #includes <Windows.h> instead of <windows.h> on line 32 of boost/test/utils/timer.hpp.
I did a quick grep through the boost sources, and found: * About 250 #includes of "windows.h" (all lower case) * Zero #includes of "Windows.h" (upper-case 'W') (and a reference to changing one instance in Boost.Test from "Windows.h" to "windows.h" for 1.67.0) We may or may not be correct, but we're quite consistent. -- Marshall
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> On Behalf Of Marshall Clow via Boost Sent: Tuesday, March 19, 2019 4:11 PM To: boost@lists.boost.org List <boost@lists.boost.org> Cc: Marshall Clow <mclow.lists@gmail.com>; Rainer Deyke <rainerd@eldwood.com>; Boost users list <boost-users@lists.boost.org> Subject: Re: [boost] [release] Boost 1.70.0 Beta 1 is now available
On Tue, Mar 19, 2019 at 2:43 AM Rainer Deyke via Boost < boost@lists.boost.org> wrote:
On 13.03.19 15:49, Marshall Clow via Boost wrote:
For details of what's in the release, see < https://www.boost.org/users/history/version_1_70_0.html>.
Please download the beta, give it a try, and report any problems you encounter.
I want to report a problem.
Boost.Test is broken when cross-compiling for Windows on Linux using a case-sensitive file system because it #includes <Windows.h> instead of <windows.h> on line 32 of boost/test/utils/timer.hpp.
I did a quick grep through the boost sources, and found: * About 250 #includes of "windows.h" (all lower case) * Zero #includes of "Windows.h" (upper-case 'W') (and a reference to changing one instance in Boost.Test from "Windows.h" to "windows.h" for 1.67.0)
We may or may not be correct, but we're quite consistent.
FYI: On my windows 10 machine, the file(s) inside the windows sdks are called "Windows.h". All "windows.h" files on my machine come from mingw or boost itself (which sounds like a bad idea TBH).
-- Marshall
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 19.03.19 10:43, Rainer Deyke via Boost wrote:
On 13.03.19 15:49, Marshall Clow via Boost wrote:
For details of what's in the release, see < https://www.boost.org/users/history/version_1_70_0.html>.
Please download the beta, give it a try, and report any problems you encounter.
I want to report a problem.
Boost.Test is broken when cross-compiling for Windows on Linux using a case-sensitive file system because it #includes <Windows.h> instead of <windows.h> on line 32 of boost/test/utils/timer.hpp.
Fixed in master, thanks to Marshall for letting me merge this. I have not seen the message earlier. Raffi
On 13.03.19 15:49, Marshall Clow via Boost wrote:
Please download the beta, give it a try, and report any problems you encounter.
I would like to report another error, triggered when cross-compiling for MacOS on a Linux host. The following minimal test program fails to compile: #include "boost/container/flat_map.hpp" int main() { boost::container::flat_map<int, int> m1, m2; m1.insert(m2.begin(), m2.end()); } Although the problem is triggered by Boost.Container, the actual error appears to be in Boost.Move. On line 958 of boost/move/algo/detail/merge.hpp, the function merge_adaptive_ONlogN_recursive is called with length arguments of mixed types if size_type != size_t, thereby preventing the compiler from instantiating the merge_adaptive_ONlogN_recursive function template. -- Rainer Deyke (rainerd@eldwood.com)
participants (6)
-
degski -
Marshall Clow -
mike.dev＠gmx.de -
Peter Dimov -
Raffi Enficiaud -
Rainer Deyke