[boost, config, context, log, 1.58] address-model and architecture detection
Hi, for some time on develop, top-level Jamroot used to deduce address-model and architecture from compiler. The only issue was that both properties would be added to targets paths when not necessary. Fix for that has been just committed, for develop: https://github.com/boostorg/boost/commit/945e3c0bbdd31ce8c297e0aff5340f0adb1... and I performed these operations on master: - Merged all of Boost.Build changes: https://github.com/boostorg/build/commit/2e764707e03d25b6928501c25a717e195c0... - Cherry-picked one Boost.Context change: https://github.com/boostorg/context/commit/9b392c68b59021aa4801dcb245bc64ad5... - Cherry-picked one Boost.Log change: https://github.com/boostorg/log/commit/27a822a6b82f8bf34cbc681ac6583412bdf27... - Cherry-picked two root project changes and updated pointers to Context and Log: https://github.com/boostorg/boost/commit/e3bc35f7891e72ad74e57dc216db899d162... https://github.com/boostorg/boost/commit/beb53b6b9574f95309384bfc5afffb40d46... https://github.com/boostorg/boost/commit/b69a072401695c9978085158af4c1ea84ce... With that, "./b2 -n" in up-to-date checkout of superproject works fine on Linux. Also, "./b2 -n --with-context --with-system" works fine, no address-model elements in path. Putting explicit address-model=64 does not change path. Putting explicit address-model=32 does add this element to path, as expected. Note that: - I did not merge any other Boost.Context or Boost.Log changes. - Nothing was required for Boost.Config, since it was merged earlier. I'd appreciate if people test current state of master branch, and report any concerns. Thanks, -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com
On Saturday 04 April 2015 20:57:45 Vladimir Prus wrote:
I'd appreciate if people test current state of master branch, and report any concerns.
Thanks Vladimir. Boost.Log tests passed locally.
On 4 Apr 2015 at 20:57, Vladimir Prus wrote:
for some time on develop, top-level Jamroot used to deduce address-model and architecture from compiler. The only issue was that both properties would be added to targets paths when not necessary. Fix for that has been just committed, for develop:
Does this mean that on Windows, if building Boost with b2 stage ... on a x64 machine, we finally default produce 64 bit binaries not 32 bit ones? If so, I take my hat off to whoever is responsible. Long overdue that fix. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
AMDG On 04/04/2015 02:00 PM, Niall Douglas wrote:
On 4 Apr 2015 at 20:57, Vladimir Prus wrote:
for some time on develop, top-level Jamroot used to deduce address-model and architecture from compiler. The only issue was that both properties would be added to targets paths when not necessary. Fix for that has been just committed, for develop:
Does this mean that on Windows, if building Boost with
b2 stage
... on a x64 machine, we finally default produce 64 bit binaries not 32 bit ones?
If so, I take my hat off to whoever is responsible. Long overdue that fix.
No, it doesn't. It will still do whatever the compiler does by default, which is the right thing to do anyway. The change was to make these properties available for libraries that need to select different implementations based on these properties. i.e. choosing x86_64 asm vs i686 asm in Boost.Context. In Christ, Steven Watanabe
On 5/04/2015 08:00, Niall Douglas wrote:
On 4 Apr 2015 at 20:57, Vladimir Prus wrote:
for some time on develop, top-level Jamroot used to deduce address-model and architecture from compiler. The only issue was that both properties would be added to targets paths when not necessary. Fix for that has been just committed, for develop:
Does this mean that on Windows, if building Boost with
b2 stage
... on a x64 machine, we finally default produce 64 bit binaries not 32 bit ones?
If so, I take my hat off to whoever is responsible. Long overdue that fix.
Building 64-bit on Windows is not the preferred option for the vast majority of applications, for compatibility reasons. Typically only those that actually need gobs of memory (read: >1.5GB per app) get compiled for 64-bit. While these certainly exist, they're relatively rare (except in certain domains, perhaps). So if Boost defaults to building 32-bit on Windows (even 64-bit Windows), that will make most end users happy and is not a bug. Although I'll add my +1 to being *able* to build both 32-bit and 64-bit in the same path, which as noted elsewhere in this thread is not currently supported.
On Tue, Apr 7, 2015 at 8:58 AM, Gavin Lambert <gavinl@compacsort.com> wrote:
On 5/04/2015 08:00, Niall Douglas wrote:
On 4 Apr 2015 at 20:57, Vladimir Prus wrote:
for some time on develop, top-level Jamroot used to deduce address-model and architecture from compiler. The only issue was that both properties would be added to targets paths when not necessary. Fix for that has been just committed, for develop:
Does this mean that on Windows, if building Boost with
b2 stage
... on a x64 machine, we finally default produce 64 bit binaries not 32 bit ones?
If so, I take my hat off to whoever is responsible. Long overdue that fix.
Building 64-bit on Windows is not the preferred option for the vast majority of applications, for compatibility reasons.
Typically only those that actually need gobs of memory (read: >1.5GB per app) get compiled for 64-bit. While these certainly exist, they're relatively rare (except in certain domains, perhaps).
Larger address space is not the only benefit of 64-bit x86. More registers (GPRs are also widened to 64 bits), mandatory SSE2, new addressing mode - all these features are very much useful even if you don't need large amounts of memory. In fact, there is no point in building 32-bit binaries nowdays, unless you desperately need compatibility with 32-bit only systems (read - more than a decade old). BTW, I think 32-bit Windows spread is overestimated. Here are some stats from Steam, for example (click "OS Version" in the table): http://store.steampowered.com/hwsurvey/ Regarding MSVC defaults - I think there is a little misunderstanding here. There is no "default" from the compiler standpoint, it's just a matter of environment setup, which defines the compiler executable (cl.exe) that gets picked. The "default" (i.e. clean) environment is not suitable for running any cl.exe, b2 has to pick one anyway and run the corresponding environment setup scripts. It is totally our decision which one we pick. So my vote is for building 64-bit binaries on a 64-bit system by default. This is also consistent with other systems.
On Tue, Apr 7, 2015 at 8:38 AM, Andrey Semashev <andrey.semashev@gmail.com> wrote:
So my vote is for building 64-bit binaries on a 64-bit system by default. This is also consistent with other systems.
Even with that, having no way for tools (like CMake) to identify one version from the other is problematic when you actually need to support both. Both building the OS native binaries and having a convention to identify both 32 and 64bit versions would help.
Klaim - Joël Lamotte wrote:
Both building the OS native binaries and having a convention to identify both 32 and 64bit versions would help.
If you teach b2 to generate cmake config packages you can tell CMake what it needs to know. http://www.cmake.org/cmake/help/v3.2/manual/cmake-packages.7.html For reference, Qt5 qmake and the llvm automake buildsystem generate cmake config packages. Thanks, Steve.
Klaim - Joël Lamotte wrote
On Tue, Apr 7, 2015 at 8:38 AM, Andrey Semashev <
andrey.semashev@
> wrote:
So my vote is for building 64-bit binaries on a 64-bit system by default. This is also consistent with other systems.
Even with that, having no way for tools (like CMake) to identify one version from the other is problematic when you actually need to support both. Both building the OS native binaries and having a convention to identify both 32 and 64bit versions would help.
I second that too. As a user of CMake+Boost tandem, I find the issue a PITA indeed. ----- -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org -- View this message in context: http://boost.2283326.n4.nabble.com/boost-config-context-log-1-58-address-mod... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 04/23/2015 10:02 PM, mloskot wrote:
Klaim - Joël Lamotte wrote
On Tue, Apr 7, 2015 at 8:38 AM, Andrey Semashev <
andrey.semashev@
> wrote:
So my vote is for building 64-bit binaries on a 64-bit system by default. This is also consistent with other systems.
Even with that, having no way for tools (like CMake) to identify one version from the other is problematic when you actually need to support both. Both building the OS native binaries and having a convention to identify both 32 and 64bit versions would help.
I second that too. As a user of CMake+Boost tandem, I find the issue a PITA indeed.
Is this problem unique to Boost? Does any other library encode 32 vs 64 bit variant in library name? I might not know lot about Windows development, but often library names does not encode anything really, and there are separate "Program Options" for 32-bit and 64-bit. And on Linux, 32-bit and 64-bit is also in different places, with library names being the same. So why is Boost special? -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com
On 23 April 2015 at 22:28, Vladimir Prus <vladimir@codesourcery.com> wrote:
On 04/23/2015 10:02 PM, mloskot wrote:
Klaim - Joël Lamotte wrote
On Tue, Apr 7, 2015 at 8:38 AM, Andrey Semashev wrote:
So my vote is for building 64-bit binaries on a 64-bit system by default. This is also consistent with other systems.
Even with that, having no way for tools (like CMake) to identify one version from the other is problematic when you actually need to support both. Both building the OS native binaries and having a convention to identify both 32 and 64bit versions would help.
I second that too. As a user of CMake+Boost tandem, I find the issue a PITA indeed.
Is this problem unique to Boost?
I don't know.
Does any other library encode 32 vs 64 bit variant in library name?
I don't know.
I might not know lot about Windows development, but often library names does not encode anything really, and there are separate "Program Options" for 32-bit and 64-bit. And on Linux, 32-bit and 64-bit is also in different places, with library names being the same.
I guess, your observation is valid.
So why is Boost special?
My complain is more about CMake module FindBoost.cmake. I'm surprised it doesn't handle not uncommon scenario of building Boost-based programon 64-bit Unix host but targetting 32-bit architecture. I posted about it to CMake ml: http://public.kitware.com/pipermail/cmake/2015-April/060429.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Mateusz Loskot wrote:
My complain is more about CMake module FindBoost.cmake.
For users of Boost+CMake, FindBoost.cmake will always be inferior to a BoostConfig.cmake generated by b2 and provided by Boost itself. Such a file would encode any and all information about the build of boost, and you would report errors at cmake time instead of link time. http://www.cmake.org/cmake/help/v3.0/manual/cmake-packages.7.html As they are just text, b2 can generate them. Qt qmake and the llvm Makefile systems generate them respectively. Thanks, Steve.
On Thursday 23 April 2015 23:28:54 Vladimir Prus wrote:
On 04/23/2015 10:02 PM, mloskot wrote:
Klaim - Joël Lamotte wrote
On Tue, Apr 7, 2015 at 8:38 AM, Andrey Semashev <
andrey.semashev@
>
wrote:
So my vote is for building 64-bit binaries on a 64-bit system by default. This is also consistent with other systems.
Even with that, having no way for tools (like CMake) to identify one version from the other is problematic when you actually need to support both. Both building the OS native binaries and having a convention to identify both 32 and 64bit versions would help.
I second that too. As a user of CMake+Boost tandem, I find the issue a PITA indeed.
Is this problem unique to Boost? Does any other library encode 32 vs 64 bit variant in library name?
I might not know lot about Windows development, but often library names does not encode anything really, and there are separate "Program Options" for 32-bit and 64-bit. And on Linux, 32-bit and 64-bit is also in different places, with library names being the same.
So why is Boost special?
Boost is not special. Basically, every project deals with it in its own way on Windows (or just doesn't). The problem is that in Windows infrastructure there is no canonical library layout for different architectures, and Boost doesn't offer its own layout. This means CMake devs can't put anything sensible in Boost library lookup routines so that it at least sometimes work. I think most projects simply put the built binaries in different directories, and that's probably what Boost should do. I'd say the name of the directory should describe the target platform, something similar to what 'dpkg- architecture -qDEB_BUILD_GNU_TYPE' provides.
On 23.04.2015 22:28, Vladimir Prus wrote:
Is this problem unique to Boost? Does any other library encode 32 vs 64 bit variant in library name?
FWIW: The OSS project I'm involved with depends directly on Boost, Python, Qt, OpenEXR, FFTW and Embree. On Windows we don't use any 32/64 bit variations of the filenames of any of our libraries. Instead we keep two separate directory trees for 32bit and 64bit dependencies, everything from source to lib/dll files. Wastes a bit of disk space but is very easy to manage, especially if you need to apply some tweak when building 64bit but not 32bit or similar. Of course, we might be weird :) - Asbjørn
On 24 April 2015 at 00:07, Asbjørn <lordcrc@gmail.com> wrote:
On 23.04.2015 22:28, Vladimir Prus wrote:
Is this problem unique to Boost? Does any other library encode 32 vs 64 bit variant in library name?
FWIW:
The OSS project I'm involved with depends directly on Boost, Python, Qt, OpenEXR, FFTW and Embree. On Windows we don't use any 32/64 bit variations of the filenames of any of our libraries.
Instead we keep two separate directory trees for 32bit and 64bit dependencies, everything from source to lib/dll files.
FYI, separate folders is what, AFAIK, CoApp+NuGet native packages use and what, hopefully, is becoming a de-facto standard on Windows. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On 24/04/2015 19:42, Mateusz Loskot wrote:
On 24 April 2015 at 00:07, Asbjørn <lordcrc@gmail.com> wrote:
Instead we keep two separate directory trees for 32bit and 64bit dependencies, everything from source to lib/dll files.
FYI, separate folders is what, AFAIK, CoApp+NuGet native packages use and what, hopefully, is becoming a de-facto standard on Windows.
Separate folders is what every Windows project I've seen has done for decades. It's also how Visual Studio builds files for multiple platforms by default. I'm fairly certain it's already "standard".
On Fri, Apr 24, 2015 at 10:56 AM, Gavin Lambert <gavinl@compacsort.com> wrote:
On 24/04/2015 19:42, Mateusz Loskot wrote:
On 24 April 2015 at 00:07, Asbjørn <lordcrc@gmail.com> wrote:
Instead we keep two separate directory trees for 32bit and 64bit dependencies, everything from source to lib/dll files.
FYI, separate folders is what, AFAIK, CoApp+NuGet native packages use and what, hopefully, is becoming a de-facto standard on Windows.
Separate folders is what every Windows project I've seen has done for decades. It's also how Visual Studio builds files for multiple platforms by default. I'm fairly certain it's already "standard".
Yes, that's what almost all my dependencies do indeed.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Fri, Apr 24, 2015 at 10:59 AM, Klaim - Joël Lamotte <mjklaim@gmail.com> wrote:
On Fri, Apr 24, 2015 at 10:56 AM, Gavin Lambert <gavinl@compacsort.com> wrote:
On 24/04/2015 19:42, Mateusz Loskot wrote:
On 24 April 2015 at 00:07, Asbjørn <lordcrc@gmail.com> wrote:
Instead we keep two separate directory trees for 32bit and 64bit dependencies, everything from source to lib/dll files.
FYI, separate folders is what, AFAIK, CoApp+NuGet native packages use and what, hopefully, is becoming a de-facto standard on Windows.
Separate folders is what every Windows project I've seen has done for decades. It's also how Visual Studio builds files for multiple platforms by default. I'm fairly certain it's already "standard".
Yes, that's what almost all my dependencies do indeed.
Now that I think about it, I also use this convention when building boost binaries myself: pushd .\boost call bootstrap.bat call b2 --prefix=. -j8 --buid-type=complete toolset=msvc-12.0 architecture=x86 install call b2 --prefix=. -j8 --buid-type=complete --libdir=./lib/x64 toolset=msvc-12.0 architecture=x86 address-model=64 install popd Then, as pointed in the ticket, I use a cmake script which will ask the user to provide Boost_LIBRARYDIR explicitely so that I chose the right directory for binaries (even if boost was found already by cmake).
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 24 April 2015 at 10:56, Gavin Lambert <gavinl@compacsort.com> wrote:
On 24/04/2015 19:42, Mateusz Loskot wrote:
On 24 April 2015 at 00:07, Asbjørn <lordcrc@gmail.com> wrote:
Instead we keep two separate directory trees for 32bit and 64bit dependencies, everything from source to lib/dll files.
FYI, separate folders is what, AFAIK, CoApp+NuGet native packages use and what, hopefully, is becoming a de-facto standard on Windows.
Separate folders is what every Windows project I've seen has done for decades. It's also how Visual Studio builds files for multiple platforms by default. I'm fairly certain it's already "standard".
Certainly. should have added, I meant an extended version of that... packaging libraries for Windows with full utilisation of available technologies. Like, SxS and the concept of Pivots developed by CoApp and used by NuGet too for native packages: http://coapp.org/tutorials/building-a-package.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Mateusz Loskot Sent: 24 April 2015 08:43 To: boost@lists.boost.org Subject: Re: [boost] [boost, config, context, log, 1.58] address-model and architecture detection
On 24 April 2015 at 00:07, Asbjørn <lordcrc@gmail.com> wrote:
On 23.04.2015 22:28, Vladimir Prus wrote:
Is this problem unique to Boost? Does any other library encode 32 vs 64 bit variant in library name?
The OSS project I'm involved with depends directly on Boost, Python, Qt, OpenEXR, FFTW and Embree. On Windows we don't use any 32/64 bit variations of the filenames of any of our libraries.
Instead we keep two separate directory trees for 32bit and 64bit dependencies, everything from source to lib/dll files.
FYI, separate folders is what, AFAIK, CoApp+NuGet native packages use and what, hopefully, is becoming a de-facto standard on Windows.
As a solution, this sounds acceptable, but IMO Boost build needs to deal with it and the instructions need to tell users how to do it. Can any experienced users provide some notes on this, perhaps using Trac which is freely editable? However, all solutions seem liable to cause users more than a little grief. Paul PS I also agree that the default build on 64-bit systems should be 64 bit, but this might be a 'breaking change' for many, so there should be some clear warning that this will happen. --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On Thu, Apr 23, 2015 at 10:28 PM, Vladimir Prus <vladimir@codesourcery.com> wrote:
On 04/23/2015 10:02 PM, mloskot wrote:
Klaim - Joël Lamotte wrote
On Tue, Apr 7, 2015 at 8:38 AM, Andrey Semashev <
andrey.semashev@
>
wrote:
So my vote is for building 64-bit binaries on a 64-bit system by
default. This is also consistent with other systems.
Even with that, having no way for tools (like CMake) to identify one version from the other is problematic when you actually need to support both. Both building the OS native binaries and having a convention to identify both 32 and 64bit versions would help.
I second that too. As a user of CMake+Boost tandem, I find the issue a PITA indeed.
Is this problem unique to Boost? Does any other library encode 32 vs 64 bit variant in library name?
In my current projects dependencies yes, but it's the same problem for any library that use the same path and filename for the output of compilation whatever the target architecture. As pointed by Andrey, most other libraries (including all the dependencies I use in all my projects except boost) will just use a different filename or directory path for the compilation output depending on the architecture (and build mode). They also distribute binaries with the same path organisation as the initial output (without moving files around) so that tools that easily identify right the binaries using their location.
I might not know lot about Windows development, but often library names does not encode anything really, and there are separate "Program Options" for 32-bit and 64-bit. And on Linux, 32-bit and 64-bit is also in different places, with library names being the same.
First, Program Files is supposed to be for installed programs or libraries. Most development work do not end there because these directories have special meaning and access rights protections (starting with Vista). If like me you prefer to compile boost yourself to be able to quickfix when necessary (or other dev-related reasons) you do not put anything dev-related into Program Files. (note that most devs on windows will have a directory for development which is never in Program Files, most of the time in either user directory or close to the root directory of the disk to avoid too long path issues that can happen on windows when generating files in deep directory hierarchies) Most other libraries providing binaries as said before will provide different paths for different modes/arch in the same binary package so that the user have one location with both binaries and sources/headers, like a freshly compiled version. Having only one location to look for both binaries also helps tools. At the moment, CMake FindBoost.cmake module will use the (unique) BOOST_DIR environment variable to guess the boost directory location, or ask the user if there is none provided. Once found, CMake cannot guess if it's 64 or 32 bits because nothing from boost conventions says so, so the user either have to specify which binaries to use separately using Boost_LIBRARYDIR or get link-time errors (very too late) when the CMake module finds a 64bit boost but the user is compiling a 32bit project (CMake, again, have no way to know that boost binaries were 64bit). Also, on linux, if you build your own boost (because fixes or something else), don't you NOT install it into the linux library dirs? I thought you would do it only for distributed versions of libraries.
So why is Boost special?
Boost don't have a way to identify if the binaries are 64 or 32bits. That's really the core root of the problem and would easily be fixed with any convention. Location don't help if the build system of the library don't enforce that location convention, so that tool knows where is what. As soon as it is provided, it will be easy to fix the CMake module or any tool that try to identify from a boost install. I also gave other details on the issue in the trac ticket https://svn.boost.org/trac/boost/ticket/10141
-- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 04/24/2015 11:58 AM, Klaim - Joël Lamotte wrote:
So why is Boost special?
Boost don't have a way to identify if the binaries are 64 or 32bits. That's really the core root of the problem and would easily be fixed with any convention. Location don't help if the build system of the library don't enforce that location convention, so that tool knows where is what. As soon as it is provided, it will be easy to fix the CMake module or any tool that try to identify from a boost install.
I also gave other details on the issue in the trac ticket https://svn.boost.org/trac/boost/ticket/10141
Right, Boost does not have a way to identify whether binaries are 32-bit or 64-bit, but most other C++ libraries don't have either, so it should present the same problems for users, and build tools. The only difference for Boost is that it tries to solve this problem for some other variations, so you can reasonably claim that it's easier for Boost to handle bitness that it would be for random other project? -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com
Vladimir Prus wrote:
Right, Boost does not have a way to identify whether binaries are 32-bit or 64-bit, but most other C++ libraries don't have either, so it should present the same problems for users, and build tools.
The minimum acceptable standard would be for b2 address-model=32,64 stage to work under Windows. Whether this is done via separate directories or separate names is up to us; so far people seem to prefer separate directories, but either way is good enough. Typically, separate directories are more convenient because one only needs to change the library path to switch between 32/64; separate names however are more convenient when autolinking, in which case nothing needs to change, and we already encode build settings into the name on Windows.
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Peter Dimov Sent: 24 April 2015 17:40 To: boost@lists.boost.org Subject: Re: [boost] [boost, config, context, log, 1.58] address-model and architecture detection
Vladimir Prus wrote:
Right, Boost does not have a way to identify whether binaries are 32-bit or 64-bit, but most other C++ libraries don't have either, so it should present the same problems for users, and build tools.
The minimum acceptable standard would be for
b2 address-model=32,64 stage
to work under Windows. Whether this is done via separate directories or separate names is up to us; so far people seem to prefer separate directories, but either way is good enough. Typically, separate directories are more convenient because one only needs to change the library path to switch between 32/64; separate names however are more convenient when autolinking, in which case nothing needs to change, and we already encode build settings into the name on Windows.
Autolinking is *very* convenient and would be badly missed. If and how does autolinking work with separate directories ? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On 25/04/2015 21:18, Paul A. Bristow wrote:
The minimum acceptable standard would be for
b2 address-model=32,64 stage
to work under Windows. Whether this is done via separate directories or separate names is up to us; so far people seem to prefer separate directories, but either way is good enough. Typically, separate directories are more convenient because one only needs to change the library path to switch between 32/64; separate names however are more convenient when autolinking, in which case nothing needs to change, and we already encode build settings into the name on Windows.
Autolinking is *very* convenient and would be badly missed.
If and how does autolinking work with separate directories ?
Autolinking should work fine either way. Either: 1. Boost library names are not changed, but 32-bit and 64-bit binaries are built to separate dirs (either the current dir for 32-bit and an x64 subdir for 64-bit, or separate subdirs for each -- that's an ease-of-migration question that'll get bikeshedded). In this case it is the library user's responsibility to point at the correct library dir depending whether their project is 32-bit or 64-bit; the auto-linking code in Boost does not change at all and as long as only the "right" dir is in the library paths (and installed with the application, if a DLL) then it will find the right binary. (This option is probably the easiest on applications that specifically choose to target one or the other; but it might be annoying where the build system or something else decides the platform or the same project files are used for both platforms.) 2. Boost library names are changed to include 32/64-bit and the binaries are built to the same dir. In this case the autolinking code needs to be updated to match the new library names, but otherwise everything Just Works. The user doesn't have to update their project files at all, but they might have to update their application install scripts for the new library names. (This is probably the easiest on people who use auto-linking on Windows, but might annoy Linux packagers if the same naming conventions are brought there too, since they don't like having the architecture in the package name.) 3. Boost library names are changed to include 32/64-bit *and* the binaries are built to different dirs. This combines both caveats of the above without any additional benefit, AFAIK.
On Fri, Apr 24, 2015 at 6:14 PM, Vladimir Prus <vladimir@codesourcery.com> wrote:
On 04/24/2015 11:58 AM, Klaim - Joël Lamotte wrote:
So why is Boost special?
Boost don't have a way to identify if the binaries are 64 or 32bits. That's really the core root of the problem and would easily be fixed with any convention. Location don't help if the build system of the library don't enforce that location convention, so that tool knows where is what. As soon as it is provided, it will be easy to fix the CMake module or any tool that try to identify from a boost install.
I also gave other details on the issue in the trac ticket https://svn.boost.org/trac/boost/ticket/10141
Right, Boost does not have a way to identify whether binaries are 32-bit or 64-bit, but most other C++ libraries don't have either, so it should present the same problems for users, and build tools.
To clarify: I and several others pointed to the fact that most other libraries actually do provide a way to identify these binaries (at least on windows), often by using a relative output path relative to the root directory of the library, therefore most libraries do provide both 32 and 64 bit versions, in particular open-source ones which when you build will put the binaries in the different paths, while Boost does not do anything like that at the moment.
The only difference for Boost is that it tries to solve this problem for some other variations, so you can reasonably claim that it's easier for Boost to handle bitness that it would be for random other project?
I didn't understand this question but I will revisit it once I get some sleep.
-- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On April 7, 2015 2:38:59 AM EDT, Andrey Semashev <andrey.semashev@gmail.com> wrote:
On Tue, Apr 7, 2015 at 8:58 AM, Gavin Lambert <gavinl@compacsort.com> wrote:
Building 64-bit on Windows is not the preferred option for the vast
of applications, for compatibility reasons.
Typically only those that actually need gobs of memory (read: >1.5GB
majority per
app) get compiled for 64-bit. While these certainly exist, they're relatively rare (except in certain domains, perhaps).
Larger address space is not the only benefit of 64-bit x86. More registers (GPRs are also widened to 64 bits), mandatory SSE2, new addressing mode - all these features are very much useful even if you don't need large amounts of memory.
Right
In fact, there is no point in building 32-bit binaries nowdays, unless you desperately need compatibility with 32-bit only systems (read - more than a decade old).
BTW, I think 32-bit Windows spread is overestimated. Here are some stats from Steam, for example (click "OS Version" in the table):
http://store.steampowered.com/hwsurvey/
Regarding MSVC defaults - I think there is a little misunderstanding here. There is no "default" from the compiler standpoint, it's just a matter of environment setup, which defines the compiler executable (cl.exe) that gets picked. The "default" (i.e. clean) environment is not suitable for running any cl.exe, b2 has to pick one anyway and run the corresponding environment setup scripts. It is totally our decision which one we pick.
So my vote is for building 64-bit binaries on a 64-bit system by default. This is also consistent with other systems.
We always build Boost 64b. ___ Rob (Sent from my portable computation engine)
On 7 Apr 2015 at 9:38, Andrey Semashev wrote:
Does this mean that on Windows, if building Boost with
b2 stage
... on a x64 machine, we finally default produce 64 bit binaries not 32 bit ones?
If so, I take my hat off to whoever is responsible. Long overdue that fix.
Building 64-bit on Windows is not the preferred option for the vast majority of applications, for compatibility reasons.
I have no idea what this means. If it was ever true, it might have been a decade ago back when I was running a 64 bit version of Windows XP and even then it had surprisingly good driver support. So I'll claim even then it wasn't an issue for most a full ten years ago.
Typically only those that actually need gobs of memory (read: >1.5GB per app) get compiled for 64-bit. While these certainly exist, they're relatively rare (except in certain domains, perhaps).
Larger address space is not the only benefit of 64-bit x86. More registers (GPRs are also widened to 64 bits), mandatory SSE2, new addressing mode - all these features are very much useful even if you don't need large amounts of memory. In fact, there is no point in building 32-bit binaries nowdays, unless you desperately need compatibility with 32-bit only systems (read - more than a decade old).
Also, the Windows 7/8 memory allocator performs *far* better in x64. Indeed it increases its performance the more memory you allocate up to some fairly scary amounts, thanks to those gobs of address space. You also avoid WOW32 if you build native binaries. Plus you get extra security measures like address randomisation and better anti stack smashing. And even silly things like C++ member functions don't need parameter inverse repacking when transitioning between cdecl and thiscall, something which is stupidly inefficient in x86 MSVC for small functions with a lot of parameters.
Regarding MSVC defaults - I think there is a little misunderstanding here. There is no "default" from the compiler standpoint, it's just a matter of environment setup, which defines the compiler executable (cl.exe) that gets picked. The "default" (i.e. clean) environment is not suitable for running any cl.exe, b2 has to pick one anyway and run the corresponding environment setup scripts. It is totally our decision which one we pick.
+100 I wasn't going to make that point myself, but this is exactly my point. There is no such thing as a default build for MSVC. You call whichever MSVC binary outputs ARM, PPC, Itanium, x86 ot x64. So what therefore most resembles GCC and clang on other platforms? Whatever is the architecture the OS is running on, so if Linux is running on ARM, you would expect GCC to output ARM binaries suitable for the host OS. Same should go on Windows. If I call b2.exe on Windows x64, I should get x64 MSVC just as if should I call b2.exe on Windows ARM, I should get ARM MSVC not x86 MSVC.
So my vote is for building 64-bit binaries on a 64-bit system by default. This is also consistent with other systems.
I absolutely agree. I would mention it prominantly in the release notes though or with a warning from b2 on Windows as the error message you get when trying to link incompatible binaries on Windows isn't too obvious about the cause. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
On 7/04/2015 18:38, Andrey Semashev wrote:
Building 64-bit on Windows is not the preferred option for the vast majority of applications, for compatibility reasons.
Typically only those that actually need gobs of memory (read: >1.5GB per app) get compiled for 64-bit. While these certainly exist, they're relatively rare (except in certain domains, perhaps).
Larger address space is not the only benefit of 64-bit x86. More registers (GPRs are also widened to 64 bits), mandatory SSE2, new addressing mode - all these features are very much useful even if you don't need large amounts of memory. In fact, there is no point in building 32-bit binaries nowdays, unless you desperately need compatibility with 32-bit only systems (read - more than a decade old).
That's not the only reason. There are plenty of 32-bit only components in the wild, which force your own code to 32-bit if you use them. And large legacy codebases still exist and must be maintained, and may have been written in such a way that porting them to 64-bit is tricky. (Not impossible, of course, but tricky and error-prone, and hard to justify to people when the 32-bit version still works.)
Regarding MSVC defaults - I think there is a little misunderstanding here. There is no "default" from the compiler standpoint, it's just a matter of environment setup, which defines the compiler executable (cl.exe) that gets picked. The "default" (i.e. clean) environment is not suitable for running any cl.exe, b2 has to pick one anyway and run the corresponding environment setup scripts. It is totally our decision which one we pick.
At the compiler level, sure -- but that wasn't what I was trying to say. Even in VS2013, if you create a new C++ project, you're not even asked if you want it to be 32-bit or 64-bit -- VS will create that project for 32-bit compilation only. Granted, it's not hard to change this setting, but I would be surprised if most end-users bother to do so. These are the *users* of Boost -- who will be very surprised if the default build of Boost does not link with their applications, merely because they happen to be compiling on a 64-bit Windows system. Again, I'm all for being able to build Boost both ways (which makes it essential to either put the architecture in the filenames or to adopt a directory convention (eg. 32-bits in "x86" and 64-bits in "x64" subdirs). I just don't agree that *on Windows* the system architecture has any bearing on the default build architecture.
On Wed, Apr 8, 2015 at 9:11 AM, Gavin Lambert <gavinl@compacsort.com> wrote:
On 7/04/2015 18:38, Andrey Semashev wrote:
Larger address space is not the only benefit of 64-bit x86. More registers (GPRs are also widened to 64 bits), mandatory SSE2, new addressing mode - all these features are very much useful even if you don't need large amounts of memory. In fact, there is no point in building 32-bit binaries nowdays, unless you desperately need compatibility with 32-bit only systems (read - more than a decade old).
That's not the only reason. There are plenty of 32-bit only components in the wild, which force your own code to 32-bit if you use them.
And large legacy codebases still exist and must be maintained, and may have been written in such a way that porting them to 64-bit is tricky. (Not impossible, of course, but tricky and error-prone, and hard to justify to people when the 32-bit version still works.)
Well, IMO the code that didn't manage to get ported to 64 bits for the last 10 years is dead and I would eagerly avoid using it in new projects and even make effort to get rid of it in the currently maintained ones. Of course, there are cases where you simply don't have a choice (mostly when the code is third party and closed source). For those cases explicitly specifying target architecture for Boost is the suitable solution. Adding explicit target architecture for Boost compilation would be part of the upgrade process.
Regarding MSVC defaults - I think there is a little misunderstanding here. There is no "default" from the compiler standpoint, it's just a matter of environment setup, which defines the compiler executable (cl.exe) that gets picked. The "default" (i.e. clean) environment is not suitable for running any cl.exe, b2 has to pick one anyway and run the corresponding environment setup scripts. It is totally our decision which one we pick.
At the compiler level, sure -- but that wasn't what I was trying to say.
Even in VS2013, if you create a new C++ project, you're not even asked if you want it to be 32-bit or 64-bit -- VS will create that project for 32-bit compilation only. Granted, it's not hard to change this setting, but I would be surprised if most end-users bother to do so.
That's something MS will have to fix then. I don't think that cross-compiling is the right default choice. Even then, if your project is more than a simple "hello world", I would expect you to set up its parameters carefully.
Again, I'm all for being able to build Boost both ways (which makes it essential to either put the architecture in the filenames or to adopt a directory convention (eg. 32-bits in "x86" and 64-bits in "x64" subdirs).
I agree that directory name convention for the target architecture would be useful. It probably should not be limited just to x86 bitness - it essentially means support for cross-compiled binaries.
On 8/04/2015 19:37, Andrey Semashev wrote:
Well, IMO the code that didn't manage to get ported to 64 bits for the last 10 years is dead and I would eagerly avoid using it in new projects and even make effort to get rid of it in the currently maintained ones.
In the Windows environment, this is not a valid assumption. It is still probably the case that more than 80% of non-driver-based applications are 32-bit only. (Though like any made-up statistic, take that with a grain of salt.) For another perspective, look at the major applications: Firefox is 32-bit only (barring unofficial builds). Office has 32-bit and 64-bit versions, but the 32-bit version is the recommended one for general users (who don't need to edit large documents). Visual Studio itself is 32-bit only. Go to any typical Windows box (that has had some real usage, not just a freshly installed one) and count the number of applications in Program Files vs. those in Program Files (x86). Also, since I forgot to respond to this point earlier:
BTW, I think 32-bit Windows spread is overestimated. Here are some stats from Steam, for example (click "OS Version" in the table):
While Steam is somewhat ubiquitous, it's still a gaming platform. And gamers will almost always have 64-bit systems because they want the RAM -- it's rare to find a modern game that isn't RAM-hungry, and even games of a decade ago often wanted 2GB, which meant your system would run better if you could have the magic 4GB of RAM or more. And again, 64-bit Windows platform does not imply that applications themselves are 64-bit. The majority case is still the opposite.
Even in VS2013, if you create a new C++ project, you're not even asked if you want it to be 32-bit or 64-bit -- VS will create that project for 32-bit compilation only. Granted, it's not hard to change this setting, but I would be surprised if most end-users bother to do so.
That's something MS will have to fix then. I don't think that cross-compiling is the right default choice. Even then, if your project is more than a simple "hello world", I would expect you to set up its parameters carefully.
I'm not sure this counts as cross-compiling, since the CPU can execute both 32-bit and 64-bit code natively (in fact 32-bit code can be faster than 64-bit code, although the extra registers in x64 definitely help a lot in this regard). There is some redirection and emulation at the API layers but not for the code itself.
On Wed, Apr 8, 2015 at 11:34 AM, Gavin Lambert <gavinl@compacsort.com> wrote:
On 8/04/2015 19:37, Andrey Semashev wrote:
Well, IMO the code that didn't manage to get ported to 64 bits for the last 10 years is dead and I would eagerly avoid using it in new projects and even make effort to get rid of it in the currently maintained ones.
In the Windows environment, this is not a valid assumption. It is still probably the case that more than 80% of non-driver-based applications are 32-bit only. (Though like any made-up statistic, take that with a grain of salt.)
For another perspective, look at the major applications: Firefox is 32-bit only (barring unofficial builds). Office has 32-bit and 64-bit versions, but the 32-bit version is the recommended one for general users (who don't need to edit large documents). Visual Studio itself is 32-bit only. Go to any typical Windows box (that has had some real usage, not just a freshly installed one) and count the number of applications in Program Files vs. those in Program Files (x86).
Ok, I see what you mean. However, that doesn't look like a technical reason to build Boost for 32-bit Windows by default.
Also, since I forgot to respond to this point earlier:
BTW, I think 32-bit Windows spread is overestimated. Here are some stats from Steam, for example (click "OS Version" in the table):
While Steam is somewhat ubiquitous, it's still a gaming platform. And gamers will almost always have 64-bit systems because they want the RAM -- it's rare to find a modern game that isn't RAM-hungry, and even games of a decade ago often wanted 2GB, which meant your system would run better if you could have the magic 4GB of RAM or more.
And again, 64-bit Windows platform does not imply that applications themselves are 64-bit. The majority case is still the opposite.
My point was that 32-bit Windows, the operating system, is rare. Even typical non-gamer systems now have 4+ GiB of RAM and it is fair to expect a 64-bit OS on it. Provided that 64-bit Windows is largely dominant, why would we target 32-bit by default? Ok, Windows applications are mainly 32-bit, and some probably have valid reasons for that. But the OS and hardware are 64-bit native and we should make use of that by default. If a developer wants to target his application for 32-bit he should explicitly opt out.
On Sat, Apr 4, 2015 at 1:57 PM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Hi,
...
I'd appreciate if people test current state of master branch, and report any concerns.
Without docs or examples as to what should happen, it is hard to know whether everything is working correctly. On 64-bit Windows 7, with toolset=gcc, I get: Performing configuration checks - 32-bit : no - 64-bit : yes - arm : no - mips1 : no - power : no - sparc : no - x86 : yes But with toolset=msvc-12.0, I get: Performing configuration checks - 32-bit : yes - arm : no - mips1 : no - power : no - sparc : no - x86 : yes That seems a bit odd to me. Other questions: * Should I be able to build both the 32-bit and 64-bit address models in the same b2 run? * If so, what does the command line look like? * Should auto-linking work? * If so, how do the names for the library files differ? * How do we tell a test to run against both 32 and 64-bit builds? Thanks for working on this! --Beman
AMDG On 04/04/2015 03:53 PM, Beman Dawes wrote:
On Sat, Apr 4, 2015 at 1:57 PM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Without docs or examples as to what should happen, it is hard to know whether everything is working correctly.
On 64-bit Windows 7, with toolset=gcc, I get:
Performing configuration checks
- 32-bit : no - 64-bit : yes - arm : no - mips1 : no - power : no - sparc : no - x86 : yes
But with toolset=msvc-12.0, I get:
Performing configuration checks
- 32-bit : yes - arm : no - mips1 : no - power : no - sparc : no - x86 : yes
That seems a bit odd to me.
The configuration output is a bit misleading. This only indicates that the /default/ architecture and address-model, now.
Other questions:
* Should I be able to build both the 32-bit and 64-bit address models in the same b2 run?
This has never been possible, and is beyond the scope of Vladimir's changes. (Note that this only applies to the top level installation. Tests have always been able to run with both 32 and 64 bit.)
* If so, what does the command line look like?
* Should auto-linking work?
* If so, how do the names for the library files differ?
They don't, which is the only reason it fails.
* How do we tell a test to run against both 32 and 64-bit builds?
b2 address-model=32,64. In Christ, Steven Watanabe
AMDG On 04/04/2015 03:53 PM, Beman Dawes wrote:
On Sat, Apr 4, 2015 at 1:57 PM, Vladimir Prus <vladimir@codesourcery.com> wrote:
I'd appreciate if people test current state of master branch, and report any concerns.
Without docs or examples as to what should happen, it is hard to know whether everything is working correctly.
Everything that worked before this update should continue to work with unchanged behavior. In addition, all of the following should work: b2 [options] b2 [options] architecture=X b2 [options] address-model=Y b2 [options] architecture=X address-model=Y If either architecture or address-model is unspecified, then the behavior will be the same as if it were set to the compiler default. (For msvc, this is specified as x86/32). "Works" means that the libraries are built for the correct architecture, although there's no easy way to verify this automatically. The best way I can think of is to write a trivial program to link against the newly generated libraries. file might also work. If architecture and address-model are not specified, they should not appear in any build paths. In Christ, Steven Watanabe
On 04/05/2015 01:33 AM, Steven Watanabe wrote:
"Works" means that the libraries are built for the correct architecture, although there's no easy way to verify this automatically. The best way I can think of is to write a trivial program to link against the newly generated libraries. file might also work.
With gcc, I just use "-n" to observe command-lines, which contain either -m32 or -m64. -- Vladimir Prus CodeSourcery / Mentor Embedded http://vladimirprus.com
Steven Watanabe-4 wrote
If architecture and address-model are not specified, they should not appear in any build paths.
This is very confusing. This means that I often have multiple sets of results which are actually exactly the same. so if I specify b2 ... and b2 addressmodel=64,32 I end up with three sets of results - two of which are identical. Now I can't tell which the "blank" one is supposed to match. Please think about this. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/boost-config-context-log-1-58-address-mod... Sent from the Boost - Dev mailing list archive at Nabble.com.
AMDG On 04/05/2015 11:41 AM, Robert Ramey wrote:
Steven Watanabe-4 wrote
If architecture and address-model are not specified, they should not appear in any build paths.
This is very confusing. This means that I often have multiple sets of results which are actually exactly the same. so if I specify
b2 ...
and
b2 addressmodel=64,32
I end up with three sets of results - two of which are identical. Now I can't tell which the "blank" one is supposed to match. Please think about this.
No, you end up with two sets of results. Steven Watanabe wrote:
If either architecture or address-model is unspecified, then the behavior will be the same as if it were set to the compiler default.
This includes the build directories. In Christ, Steven Watanabe
Steven Watanabe-4 wrote
No, you end up with two sets of results.
Hmmmm - That's not what I'm seeing. I'm seeing a directory with a set of results. Within that directory I'm seeing a subdirectory named address-model-64 and another one with name address-model-32. Each of these latter two have their own set of results. One of these is the same as those in the parent directory. In fairness, I'm speaking from memory as I'm now building/testing all combinations. I'll double check this again when I'm done. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/boost-config-context-log-1-58-address-mod... Sent from the Boost - Dev mailing list archive at Nabble.com.
AMDG On 04/05/2015 01:11 PM, Robert Ramey wrote:
Steven Watanabe-4 wrote
No, you end up with two sets of results.
Hmmmm - That's not what I'm seeing.
If so, it's a bug.
I'm seeing a directory with a set of results. Within that directory I'm seeing a subdirectory named address-model-64 and another one with name address-model-32. Each of these latter two have their own set of results. One of these is the same as those in the parent directory.
In fairness, I'm speaking from memory as I'm now building/testing all combinations. I'll double check this again when I'm done.
Did you clean the old directories? The code used to generate both address-model-32 and address-model-64. The whole point of Vladimir's changes was to suppress this directory when it matches the default compiler settings. In Christ, Steven Watanabe
OK - I haven't recently updated and rebuilt b2. i hadn't realized that recent changes altered this behavior. Robert Ramey -- View this message in context: http://boost.2283326.n4.nabble.com/boost-config-context-log-1-58-address-mod... Sent from the Boost - Dev mailing list archive at Nabble.com.
AMDG On 04/05/2015 02:39 PM, Robert Ramey wrote:
OK - I haven't recently updated and rebuilt b2. i hadn't realized that recent changes altered this behavior.
There are no changes to the b2 executable, so you don't need to rebuild it, but you do need to update the build repository and the the superproject. In Christ, Steven Watanabe
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: 04 April 2015 22:54 To: Boost Developers List Subject: Re: [boost] [boost, config, context, log, 1.58] address-model and architecture detection
On Sat, Apr 4, 2015 at 1:57 PM, Vladimir Prus <vladimir@codesourcery.com> wrote:
Hi,
I'd appreciate if people test current state of master branch, and report any concerns.
Other questions:
* Should I be able to build both the 32-bit and 64-bit address models in the same b2 run?
* If so, what does the command line look like?
* Should auto-linking work?
* If so, how do the names for the library files differ?
* How do we tell a test to run against both 32 and 64-bit builds?
Thanks for working on this!
+1 Would it be easy to also echo the actual command line into the log file? This would help refreshing ones memory of what one did last time. Thanks Paul PS Is it time to allow 32 and 64 linker file names to be different? Or else can you suggest how to manage testing in 32 and 64 builds.
On 4/4/2015 1:57 PM, Vladimir Prus wrote:
Hi,
for some time on develop, top-level Jamroot used to deduce address-model and architecture from compiler.
Could we get some indication in the Boost Build docs what 'architecture' values are possible ? The only thing I see there is: "architecture The architecture features specifies the general processor familty to generate code for." Did I miss something ?
The only issue was that both properties would be added to targets paths when not necessary. Fix for that has been just committed, for develop:
https://github.com/boostorg/boost/commit/945e3c0bbdd31ce8c297e0aff5340f0adb1...
and I performed these operations on master:
- Merged all of Boost.Build changes:
https://github.com/boostorg/build/commit/2e764707e03d25b6928501c25a717e195c0...
- Cherry-picked one Boost.Context change:
https://github.com/boostorg/context/commit/9b392c68b59021aa4801dcb245bc64ad5...
- Cherry-picked one Boost.Log change:
https://github.com/boostorg/log/commit/27a822a6b82f8bf34cbc681ac6583412bdf27...
- Cherry-picked two root project changes and updated pointers to Context and Log:
https://github.com/boostorg/boost/commit/e3bc35f7891e72ad74e57dc216db899d162...
https://github.com/boostorg/boost/commit/beb53b6b9574f95309384bfc5afffb40d46...
https://github.com/boostorg/boost/commit/b69a072401695c9978085158af4c1ea84ce...
With that, "./b2 -n" in up-to-date checkout of superproject works fine on Linux. Also, "./b2 -n --with-context --with-system" works fine, no address-model elements in path. Putting explicit address-model=64 does not change path. Putting explicit address-model=32 does add this element to path, as expected.
Note that:
- I did not merge any other Boost.Context or Boost.Log changes. - Nothing was required for Boost.Config, since it was merged earlier.
I'd appreciate if people test current state of master branch, and report any concerns.
AMDG On 04/04/2015 04:50 PM, Edward Diener wrote:
Could we get some indication in the Boost Build docs what 'architecture' values are possible ? The only thing I see there is:
"architecture
The architecture features specifies the general processor familty to generate code for."
Did I miss something ?
Fixed in develop. In Christ, Steven Watanabe
participants (16)
-
Andrey Semashev -
Asbjørn -
Beman Dawes -
Edward Diener -
Gavin Lambert -
Klaim - Joël Lamotte -
Mateusz Loskot -
mloskot
-
Niall Douglas -
Paul A. Bristow -
Peter Dimov -
Rob Stewart -
Robert Ramey -
Stephen Kelly -
Steven Watanabe -
Vladimir Prus