Hello, I've just noted that building Boost from master stopped working: [00:16:51] b2.exe -j4 toolset=gcc --layout=system variant=release architecture=x86 link=static --with-program_options --with-filesystem --with-system --with-test --with-atomic --with-thread --with-timer --with-date_time --with-chrono --with-regex --with-random --with-context stage [00:16:52] Performing configuration checks [00:16:52] [00:16:52] - default address-model : 32-bit [00:16:53] - default architecture : x86 [00:16:53] - symlinks supported : yes (cached) [00:16:54] - C++11 mutex : yes [00:16:55] - has_icu builds : no [00:16:55] - BOOST_COMP_GNUC >= 4.3.0 : yes [00:16:55] - C++11 mutex : no [00:16:56] - has_icu builds : no [00:16:56] - BOOST_COMP_GNUC >= 4.3.0 : no [00:16:56] error: Name clash for '<pstage\lib>libboost_atomic.a' [00:16:56] error: [00:16:56] error: Tried to build the target twice, with property sets having [00:16:56] error: these incompatible properties: [00:16:56] error: [00:16:56] error: - <address-model>64 [00:16:56] error: - <address-model>32 [00:16:56] error: [00:16:56] error: Please make sure to have consistent requirements for these [00:16:56] error: properties everywhere in your project, especially for install [00:16:56] error: targets. [00:16:56] [00:16:56] Command exited with code 1 Previously this build command worked fine. Full log available at https://ci.appveyor.com/project/apolukhin/boost-cookbook/branch/second_editi... Is this an intended breaking change?
AMDG On 03/28/2018 02:42 PM, Antony Polukhin via Boost wrote:
I've just noted that building Boost from master stopped working:
[00:16:51] b2.exe -j4 toolset=gcc --layout=system variant=release architecture=x86 link=static --with-program_options --with-filesystem --with-system --with-test --with-atomic --with-thread --with-timer --with-date_time --with-chrono --with-regex --with-random --with-context stage
The change was to build both 32-bit and 64-bit libraries by default on windows. Building multiple variants conflicts with --layout=system. You can work around this by explicitly adding address-model=64. Perhaps we need to adjust the default variant(s) based on the value of --layout.
[00:16:52] Performing configuration checks [00:16:52] [00:16:52] - default address-model : 32-bit [00:16:53] - default architecture : x86 [00:16:53] - symlinks supported : yes (cached) [00:16:54] - C++11 mutex : yes [00:16:55] - has_icu builds : no [00:16:55] - BOOST_COMP_GNUC >= 4.3.0 : yes [00:16:55] - C++11 mutex : no [00:16:56] - has_icu builds : no [00:16:56] - BOOST_COMP_GNUC >= 4.3.0 : no [00:16:56] error: Name clash for '<pstage\lib>libboost_atomic.a' [00:16:56] error: [00:16:56] error: Tried to build the target twice, with property sets having [00:16:56] error: these incompatible properties: [00:16:56] error: [00:16:56] error: - <address-model>64 [00:16:56] error: - <address-model>32 [00:16:56] error: [00:16:56] error: Please make sure to have consistent requirements for these [00:16:56] error: properties everywhere in your project, especially for install [00:16:56] error: targets. [00:16:56] [00:16:56] Command exited with code 1
Previously this build command worked fine. Full log available at https://ci.appveyor.com/project/apolukhin/boost-cookbook/branch/second_editi...
Is this an intended breaking change?
In Christ, Steven Watanabe
On 03/29/18 00:07, Steven Watanabe via Boost wrote:
AMDG
On 03/28/2018 02:42 PM, Antony Polukhin via Boost wrote:
I've just noted that building Boost from master stopped working:
[00:16:51] b2.exe -j4 toolset=gcc --layout=system variant=release architecture=x86 link=static --with-program_options --with-filesystem --with-system --with-test --with-atomic --with-thread --with-timer --with-date_time --with-chrono --with-regex --with-random --with-context stage
The change was to build both 32-bit and 64-bit libraries by default on windows. Building multiple variants conflicts with --layout=system. You can work around this by explicitly adding address-model=64. Perhaps we need to adjust the default variant(s) based on the value of --layout.
Maybe we should just change the default to address-model=64. Really, 32-bit x86 is long long outdated.
On 29/03/2018 10:47, Andrey Semashev wrote:
Maybe we should just change the default to address-model=64. Really, 32-bit x86 is long long outdated.
While 64-bit OSes are the norm (and on Linux this also applies to applications that are built from source, which is most of them), on Windows and outside of spaces that require large amounts of memory (such as games and graphics) it is still more common to have 32-bit apps than 64-bit ones.
On 03/29/18 02:52, Gavin Lambert via Boost wrote:
On 29/03/2018 10:47, Andrey Semashev wrote:
Maybe we should just change the default to address-model=64. Really, 32-bit x86 is long long outdated.
While 64-bit OSes are the norm (and on Linux this also applies to applications that are built from source, which is most of them), on Windows and outside of spaces that require large amounts of memory (such as games and graphics) it is still more common to have 32-bit apps than 64-bit ones.
Most of applications have 32 and 64-bit variants, unless they stuck in the 90's. Defaulting nowdays to 32 bits is simply unreasonable. If someone wants to target an outdated architecture (and 32-bit x86 really is a separate architecture, including hardware features and software ABI) then let them do that with a little more effort. The rest of the world have moved to 64 bits long ago, and that is what we should target by default, IMO.
On 29/03/2018 13:49, Andrey Semashev wrote:
Most of applications have 32 and 64-bit variants, unless they stuck in the 90's. Defaulting nowdays to 32 bits is simply unreasonable.
Boost doesn't default to 32 bits. It defaults to both 32 and 64, which is the most reasonable choice on Windows, just as defaulting to the host architecture is the most reasonable choice on Linux. Visual Studio always defaults to 32-bits, thus most Windows applications do as well. Even pure .NET projects, which are compiled to IL and can run equally well as 32-bit or 64-bit, have the "prefer 32-bit" flag set by default which means that they will run as 32-bit if given the option (ie. not loaded as a DLL into a process that is already 64-bit). Take any random Windows machine and run a lot of applications on it. Now look at Task Manager and see how many of those applications have (32 bit) next to them. If you exclude OS-in-box components, games, CAD packages, and the like, you will almost certainly find that your number is higher than 90%. (Heck, until very recently most web browsers were also 32-bit-only, and they do fall into the category of apps that benefit from 64-bit.) Perhaps this is not your ideal world. And I agree that x86-32 is indeed a different (and inferior) architecture from amd64. But being different is in and of itself one reason why apps don't change architectures unless they actually need to (since the rules are subtly different, and it's another thing to test), and the vast majority of apps don't actually need to.
On Wed, Mar 28, 2018 at 5:49 PM, Andrey Semashev via Boost <boost@lists.boost.org> wrote:
If someone wants to target an outdated architecture (and 32-bit x86 really is a separate architecture, including hardware features and software ABI) then let them do that with a little more effort. The rest of the world have moved to 64 bits long ago, and that is what we should target by default, IMO.
No they have not all "moved on to 64 bits." Most programs work perfectly fine as 32-bit applications and have no need for the ability to access a full 64-bit address space. In fact many programs perform objectively worse as 64-bit application since pointers and data structures become larger without a corresponding benefit. This is especially true for mobile applications. Rumors of 32-bit apps' demise are greatly exaggerated.
On 03/29/18 05:51, Vinnie Falco via Boost wrote:
On Wed, Mar 28, 2018 at 5:49 PM, Andrey Semashev via Boost <boost@lists.boost.org> wrote:
If someone wants to target an outdated architecture (and 32-bit x86 really is a separate architecture, including hardware features and software ABI) then let them do that with a little more effort. The rest of the world have moved to 64 bits long ago, and that is what we should target by default, IMO.
No they have not all "moved on to 64 bits." Most programs work perfectly fine as 32-bit applications and have no need for the ability to access a full 64-bit address space. In fact many programs perform objectively worse as 64-bit application since pointers and data structures become larger without a corresponding benefit. This is especially true for mobile applications.
Memory is cheap and the increase from the pointer size is not significant[1]. Although x86 is not really relevant in that area, even mainstream smartphones now have 3+ GiB of RAM. Laptops come with more than 4. The x32[2] initiative didn't really take off[3] because the benefits from reducing pointers to 32 bits are not significant enough. I really don't understand why people cling to the old x86 while the bits of silicon and associated performance lie wasted in their CPUs. [1]: https://youtu.be/nLOXwRhOhWY?t=410 - before that time there are performance comparisons [2]: https://en.wikipedia.org/wiki/X32_ABI [3]: https://www.phoronix.com/scan.php?page=news_item&px=MTU1MjE
On Wed, Mar 28, 2018, 10:51 PM Vinnie Falco via Boost <boost@lists.boost.org> wrote:
If someone wants to target an outdated architecture (and 32-bit x86 really is a separate architecture, including hardware features and software ABI)
On Wed, Mar 28, 2018 at 5:49 PM, Andrey Semashev via Boost <boost@lists.boost.org> wrote: then
let them do that with a little more effort. The rest of the world have moved to 64 bits long ago, and that is what we should target by default, IMO.
No they have not all "moved on to 64 bits." Most programs work perfectly fine as 32-bit applications and have no need for the ability to access a full 64-bit address space. In fact many programs perform objectively worse as 64-bit application since pointers and data structures become larger without a corresponding benefit. This is especially true for mobile applications.
Rumors of 32-bit apps' demise are greatly exaggerated.
The corresponding benefit is access to twice as many CPU registers (on amd64, anyway) which provides a notable performance benefit to many applications (given a compiler outputting code that leverages it). I don't know if the same can be said for other 64-bit architectures. amd64 was released in 2000. The debian project reported that in 2012, downloads of the x86_64 architecture surpassed the x86 architecture. The addition of the NX bit is a security improvement in amd64 that x86 cannot leverage, and given what we've seen recently, CPU enforced security (and correctness) is pretty important. We're not saying that we won't support 32-bit, however if someone just says "b2" on an x86 based platform it should default to an address-model of 64 unless otherwise overridden. - Jim
James E. King, III wrote:
The debian project reported that in 2012, downloads of the x86_64 architecture surpassed the x86 architecture.
This (a) doesn't have anything to do with Windows and (b) relates to the architecture of the OS rather than the code running on it. Most Windows installations are 64 bit. Most code running on Windows is still 32 bit, although this is changing.
The addition of the NX bit is a security improvement in amd64 that x86 cannot leverage,
I think that 32 bit code under Windows 64 does leverage the NX bit, but I'm too lazy to check. Either way, this thread was not originally about the default address-model. It was about what was built by default for `b2 --build-type=minimal` (which is the default). Under Linux, this builds the default address-model, which is 64 bit on a 64 bit OS. Under Windows, it used to build 32 bit, and I changed it to build both 32 and 64 bit. The reason it built 32 bit was that build-type=minimal on Windows built whatever were the default project settings in a new Visual Studio project, to make it easier for people trying out Boost to have the project autolink correctly.
On Thu, Mar 29, 2018, 16:51 Peter Dimov via Boost <boost@lists.boost.org> wrote:
Either way, this thread was not originally about the default address-model. It was about what was built by default for `b2 --build-type=minimal` (which is the default). Under Linux, this builds the default address-model, which is 64 bit on a 64 bit OS. Under Windows, it used to build 32 bit, and I changed it to build both 32 and 64 bit.
Some MinGW do not support 64 bit builds at all (here's an example https://ci.appveyor.com/project/apolukhin/boost-cookbook/build/1.65.130-seco... ) IMO a good solution for this issue would be to test for an ability of the compiler to do 64bit builds. If it does not support 64 bit builds - just disable them and build i 32 bit mode. About 32 or 64 bits by default... I'd prefer 64 bits as a more modern solution. Users always can switch back to 32 if they have a need.
On 29 March 2018 at 19:00, Antony Polukhin via Boost <boost@lists.boost.org> wrote:
IMO a good solution for this issue would be to test for an ability of the compiler to do 64bit builds. If it does not support 64 bit builds - just disable them and build i 32 bit mode.
About 32 or 64 bits by default... I'd prefer 64 bits as a more modern solution. Users always can switch back to 32 if they have a need.
My small data point, as a boost user and cross platform dev. In all of my applications I need: - both 32bit and 64bit versions of boost on windows and linux (embedded 32bit) - to generate both 32bit and 64bit versions of my apps because - experience shows (because of different possible reasons, including cache miss profile changes) that guessing which one will be the most efficient is not possible, so depending on the app, I/we decide to use one or the other. - for some programs I need to use some closed libraries (unfortunately I can't easily change that now) which only provide 32bit binaries, but I still need a different 64bit version available too (without these libs but without the related features too); - "memory is cheap" is actually wrong when your main performance bottleneck is cache-misses that trigger more in 64bit because your structs containing pointers just double sizes; - also note that the size of binaries (that 64bit often impacts) is a major issue with some online systems when updating as it can lead to significant downloads, even with a binary patching system; My point: it's not obvious at all which of 32bit or 64bit is superior in practice (at least on windows but not clear if it's an OS thing or not) depending on the application and how it's coded, although it would make my life easier if 64bit was not surprisingly expensive sometime, so that I don't have to bother about that (and sometime I just ignore the hit and use it anyway, depends). All that is not very important actually if I was just building boost with the right flags to compile all I need - which is basically what I do anyway. The core issue that lead to that change, if my memory is correct, is that the boost binaries distribution, which is equivalent to the default build configuration, have to be set so that tools (in particular CMake) have a change to guess which version is built (which is now in the file name) and select the version depending on what the user want (instead of having to point to different boost install directories manually). Next CMake version will handle boost binaries detection automatically (the patch have been merged several weeks ago, I dont know why it was not in the last release but they plan it for the next). Though it forces me to adapt my boost build scripts to build all variants, I'm not against the default build config to only building one of the platforms (but please keep the tests running for both! both are used!). It also seem ok if it's only 64bit by default. However, please keep the new naming layout as it is to make sure tools identify the architecture of the binaries easily and the binary distribution matches at least partially a default build of boost. As long as you keep that, it should be fine IMO (although keep in mind that 32bit dev will not go away on Windows soon, it really is unfortunately necessary to be able to use it depending on the program). A. Joël Lamotte
My personal Preference as a Boost user on Windows: - The binary distribution should definitely contain 32 and 64 bit builds - most serious projects need both anyway. - The default build should only compile one version (my preference would be x64) to reduce compilation times. - There needs to be good, prominent documentation that shows, how to select the versions that are going to be built (maybe as part of https://www.boost.org/doc/libs/1_62_0/more/getting_started/windows.html) For any serious deployment it is very likely that people will either use the binary distribution, which should work for as many scenarios as possible, or - when they build themselves - will configure boost according to their specific needs anyway. However, for experimentation / initial testing of patches aso., short build-times are more important and one address model is usually enough. This is also the scenario, where defaults are imho most important. Personally I'm using x64 for anything where I don't have an explicit requirement to support 32 bit which is the reason for my x64 default preference (and I think/hope it will become the default on windows sooner or later anyway), but isn't so important to me. Best Mike
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> On Behalf Of Klaim - Joël Lamotte via Boost Sent: Thursday, March 29, 2018 11:17 PM To: Boost Developers List <boost@lists.boost.org> Cc: Klaim - Joël Lamotte <mjklaim@gmail.com>; Peter Dimov <lists@pdimov.com> Subject: Re: [boost] Build breaking changes
On 29 March 2018 at 19:00, Antony Polukhin via Boost <boost@lists.boost.org> wrote:
IMO a good solution for this issue would be to test for an ability of the compiler to do 64bit builds. If it does not support 64 bit builds - just disable them and build i 32 bit mode.
About 32 or 64 bits by default... I'd prefer 64 bits as a more modern solution. Users always can switch back to 32 if they have a need.
My small data point, as a boost user and cross platform dev. In all of my applications I need: - both 32bit and 64bit versions of boost on windows and linux (embedded 32bit) - to generate both 32bit and 64bit versions of my apps because - experience shows (because of different possible reasons, including cache miss profile changes) that guessing which one will be the most efficient is not possible, so depending on the app, I/we decide to use one or the other. - for some programs I need to use some closed libraries (unfortunately I can't easily change that now) which only provide 32bit binaries, but I still need a different 64bit version available too (without these libs but without the related features too); - "memory is cheap" is actually wrong when your main performance bottleneck is cache-misses that trigger more in 64bit because your structs containing pointers just double sizes; - also note that the size of binaries (that 64bit often impacts) is a major issue with some online systems when updating as it can lead to significant downloads, even with a binary patching system;
My point: it's not obvious at all which of 32bit or 64bit is superior in practice (at least on windows but not clear if it's an OS thing or not) depending on the application and how it's coded, although it would make my life easier if 64bit was not surprisingly expensive sometime, so that I don't have to bother about that (and sometime I just ignore the hit and use it anyway, depends).
All that is not very important actually if I was just building boost with the right flags to compile all I need - which is basically what I do anyway.
The core issue that lead to that change, if my memory is correct, is that the boost binaries distribution, which is equivalent to the default build configuration, have to be set so that tools (in particular CMake) have a change to guess which version is built (which is now in the file name) and select the version depending on what the user want (instead of having to point to different boost install directories manually). Next CMake version will handle boost binaries detection automatically (the patch have been merged several weeks ago, I dont know why it was not in the last release but they plan it for the next).
Though it forces me to adapt my boost build scripts to build all variants, I'm not against the default build config to only building one of the platforms (but please keep the tests running for both! both are used!). It also seem ok if it's only 64bit by default.
However, please keep the new naming layout as it is to make sure tools identify the architecture of the binaries easily and the binary distribution matches at least partially a default build of boost. As long as you keep that, it should be fine IMO (although keep in mind that 32bit dev will not go away on Windows soon, it really is unfortunately necessary to be able to use it depending on the program).
A. Joël Lamotte
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 3/28/2018 9:51 PM, Vinnie Falco via Boost wrote:
On Wed, Mar 28, 2018 at 5:49 PM, Andrey Semashev via Boost <boost@lists.boost.org> wrote:
If someone wants to target an outdated architecture (and 32-bit x86 really is a separate architecture, including hardware features and software ABI) then let them do that with a little more effort. The rest of the world have moved to 64 bits long ago, and that is what we should target by default, IMO.
No they have not all "moved on to 64 bits." Most programs work perfectly fine as 32-bit applications and have no need for the ability to access a full 64-bit address space. In fact many programs perform objectively worse as 64-bit application since pointers and data structures become larger without a corresponding benefit. This is especially true for mobile applications.
Note that the Visual Studio 2017 default for all new projects/solutions is 32-bit, x86 (aka Win32). In older Visual Studio releases, extra mouse clicks are required to configure a project to compile as x64. If there are a family of projects within an existing solution, then all projects individual project files will likely have to be manually edited to support x64. Ask me how I know. Also note that until proven otherwise, the Boost Unit Test Adapter fork by Microsoft only integrates with Visual Studio 2017 correctly when set to x86 | Release. No other configuration setting will run within the IDE, let alone integrate correctly with the Visual Studio 2017 environment. When this is finally fixed, I have no idea. You will have to ask the Microsoft team managing the Boost Unit Test Adapter fork.
Rumors of 32-bit apps' demise are greatly exaggerated.
Seconded --Robert
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 03/29/18 18:17, Robert via Boost wrote:
Note that the Visual Studio 2017 default for all new projects/solutions is 32-bit, x86 (aka Win32). In older Visual Studio releases, extra mouse clicks are required to configure a project to compile as x64. If there are a family of projects within an existing solution, then all projects individual project files will likely have to be manually edited to support x64. Ask me how I know.
Also note that until proven otherwise, the Boost Unit Test Adapter fork by Microsoft only integrates with Visual Studio 2017 correctly when set to x86 | Release. No other configuration setting will run within the IDE, let alone integrate correctly with the Visual Studio 2017 environment. When this is finally fixed, I have no idea. You will have to ask the Microsoft team managing the Boost Unit Test Adapter fork.
Difficulty with one particular IDE does not count as a valid reason to stick with 32-bit x86 to me.
On 3/29/2018 1:48 PM, Andrey Semashev via Boost wrote:
On 03/29/18 18:17, Robert via Boost wrote:
Note that the Visual Studio 2017 default for all new projects/solutions is 32-bit, x86 (aka Win32). In older Visual Studio releases, extra mouse clicks are required to configure a project to compile as x64. If there are a family of projects within an existing solution, then all projects individual project files will likely have to be manually edited to support x64. Ask me how I know.
Also note that until proven otherwise, the Boost Unit Test Adapter fork by Microsoft only integrates with Visual Studio 2017 correctly when set to x86 | Release. No other configuration setting will run within the IDE, let alone integrate correctly with the Visual Studio 2017 environment. When this is finally fixed, I have no idea. You will have to ask the Microsoft team managing the Boost Unit Test Adapter fork.
Difficulty with one particular IDE does not count as a valid reason to stick with 32-bit x86 to me.
Agreed. My purpose posting the above is so the rest of us know about the environment defaults. Where I work, we are currently supporting both 32-bit and 64-bit product releases. We do so because of our customer base use cases. --Robert
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 30/03/2018 07:48, Andrey Semashev wrote:
Difficulty with one particular IDE does not count as a valid reason to stick with 32-bit x86 to me.
While the above is true, having the most popular compiler and IDE of the platform default to 32-bit does argue very strongly to *not stop* building 32-bit by default _on Windows_. Thus I stand by what I said before -- building both 32 and 64 is the best default choice for VC++ binaries on Windows. For mingw64 and Linux, other default choices may make more sense. If others prefer that the default should only ever to be to compile one address-model (which is not my preference), then the default for Windows should be 32, not 64. Because while it might be older and does have some deficiencies, it is *still* the default for the platform as a whole. (This is independent of the OS architecture itself.) So, at least for Windows, as a default, in my opinion: 32+64 > 32 > 64.
On 2 April 2018 at 20:30, Gavin Lambert via Boost <boost@lists.boost.org> wrote:
On 30/03/2018 07:48, Andrey Semashev wrote:
Difficulty with one particular IDE does not count as a valid reason to stick with 32-bit x86 to me.
While the above is true, having the most popular compiler and IDE of the platform default to 32-bit does argue very strongly to *not stop* building 32-bit by default _on Windows_.
This might not stay this way! It also departs from the assumption that *all* VS users are total numwitz, and do not attempt and succeed to set up and select a 64-bit project. degski
AMDG On 04/03/2018 08:06 AM, degski via Boost wrote:
On 2 April 2018 at 20:30, Gavin Lambert via Boost <boost@lists.boost.org> wrote:
On 30/03/2018 07:48, Andrey Semashev wrote:
Difficulty with one particular IDE does not count as a valid reason to stick with 32-bit x86 to me.
While the above is true, having the most popular compiler and IDE of the platform default to 32-bit does argue very strongly to *not stop* building 32-bit by default _on Windows_.
This might not stay this way!
Of course, but we can always change our default if/when Microsoft changes theirs. In the end, building for 32-bit or 64-bit is not our call to make. Our default settings should be designed to work for most users.
It also departs from the assumption that *all* VS users are total numwitz, and do not attempt and succeed to set up and select a 64-bit project.
In Christ, Steven Watanabe
On 4/3/2018 9:37 AM, Steven Watanabe via Boost wrote:
AMDG
On 04/03/2018 08:06 AM, degski via Boost wrote:
On 2 April 2018 at 20:30, Gavin Lambert via Boost <boost@lists.boost.org> wrote:
On 30/03/2018 07:48, Andrey Semashev wrote:
Difficulty with one particular IDE does not count as a valid reason to stick with 32-bit x86 to me.
While the above is true, having the most popular compiler and IDE of the platform default to 32-bit does argue very strongly to *not stop* building 32-bit by default _on Windows_.
This might not stay this way!
Of course, but we can always change our default if/when Microsoft changes theirs. In the end, building for 32-bit or 64-bit is not our call to make. Our default settings should be designed to work for most users.
IMHO, 32+64 is going to work well for many, if not all, Visual Studio tool set developers/users. The architecture within the Boost build output file name helps everyone. There is also the Microsoft announcement last Thursday, regarding the break up of the Windows and Devices team. Terry Myerson will soon depart. Various Windows development teams are going to either A) Azure or B) Office (soon to become, "Experiences and Devices"). It is a challenge predicting what else will occur in the next few months.
It also departs from the assumption that *all* VS users are total numwitz, and do not attempt and succeed to set up and select a 64-bit project.
In Christ, Steven Watanabe
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Wed, Mar 28, 2018 at 11:47 PM, Andrey Semashev via Boost <boost@lists.boost.org> wrote:
On 03/29/18 00:07, Steven Watanabe via Boost wrote:
AMDG
On 03/28/2018 02:42 PM, Antony Polukhin via Boost wrote:
I've just noted that building Boost from master stopped working:
[00:16:51] b2.exe -j4 toolset=gcc --layout=system variant=release architecture=x86 link=static --with-program_options --with-filesystem --with-system --with-test --with-atomic --with-thread --with-timer --with-date_time --with-chrono --with-regex --with-random --with-context stage
The change was to build both 32-bit and 64-bit libraries by default on windows. Building multiple variants conflicts with --layout=system. You can work around this by explicitly adding address-model=64. Perhaps we need to adjust the default variant(s) based on the value of --layout.
Maybe we should just change the default to address-model=64. Really, 32-bit x86 is long long outdated.
Repeating the same thing over and over doesn't make it true. -- Olaf
On 03/29/18 10:27, Olaf van der Spek wrote:
On Wed, Mar 28, 2018 at 11:47 PM, Andrey Semashev via Boost <boost@lists.boost.org> wrote:
Maybe we should just change the default to address-model=64. Really, 32-bit x86 is long long outdated.
Repeating the same thing over and over doesn't make it true.
Are you trying to say 32-bit x86 is not outdated?
participants (12)
-
Andrey Semashev -
Antony Polukhin -
degski -
Gavin Lambert -
James E. King, III -
Klaim - Joël Lamotte -
mike.dev＠gmx.de -
Olaf van der Spek -
Peter Dimov -
Robert -
Steven Watanabe -
Vinnie Falco