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: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.

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 23 April 2015 at 22:28, 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 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

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 24 April 2015 at 00:07, Asbjørn 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 Fri, Apr 24, 2015 at 10:56 AM, Gavin Lambert wrote:

On 24/04/2015 19:42, Mateusz Loskot wrote:

...

On 24 April 2015 at 00:07, Asbjørn 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 24 April 2015 at 10:56, Gavin Lambert wrote:

On 24/04/2015 19:42, Mateusz Loskot wrote:

...

On 24 April 2015 at 00:07, Asbjørn 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

On Thu, Apr 23, 2015 at 10:28 PM, 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?

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

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.

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 April 7, 2015 2:38:59 AM EDT, Andrey Semashev wrote:

On Tue, Apr 7, 2015 at 8:58 AM, Gavin Lambert 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/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 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):

http://store.steampowered.com/hwsurvey/

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.

AMDG On 04/04/2015 03:53 PM, Beman Dawes wrote:

On Sat, Apr 4, 2015 at 1:57 PM, Vladimir Prus 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

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.

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.

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.

-----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 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.

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