Boost C++ Libraries: Ticket #1720: Need for 32- and 64-bit libraries on Windows with suitable naming convention.

anonymous — Wed, 26 Mar 2008 21:28:48 GMT

This was my first ticket in this system and I missed the "type" field; it should probably be a feature request rather than a bug.

type changed

Marshall Clow — Wed, 26 Mar 2008 21:32:14 GMT

type Bugs → Feature Requests

Vladimir Prus — Thu, 27 Mar 2008 06:44:29 GMT

The building of 32/64 bit libraries is documented in Boost.Build documentation. Can you please list exact changes that this ticket calls for, as I cannot really make that out?

Steve Nuchia — Thu, 27 Mar 2008 14:27:19 GMT

Starting from the index.html in the 1.35.0 RC2 snapshot contained in boost-windows-2008-03-24.zip, I can't find the documentation you're referring to. Following the instructions in more\getting_started\windows.html I find no mention of cross-compilation considerations in general nor this very common special case.

So, it seems to me that there should be a more visible / discoverable link to the documentation that does exist; I still don't know where it is. The "Boost.Build" documentation I've been able to discover is generic and gives no direct help with building boost itself. If you would give me a more specific pointer I will draft some new language for the Windows getting started guide.

The suggested change, beyond documentation, is to provide both sets of compiled libraries, in the build automation and in the pre-compiled installers for Windows, in separate folders named in such a way that they can be selected by the Visual Studio defalt platform selection macro: e.g. lib-Win32 and lib-x64.

It doesn't help that the instructions given don't actually work; when I run bjam (from boost-jam-3.1.16-1-ntx86.zip) from the root of the boost tree I get the error cascade shown below. There has been some traffic on the list about bjam compatibility issues and I hope that's all this is. The RC2 build-from-source automation is, as it stands and as it is documented in the getting started guide, badly broken on Windows. I need some help getting past this before I can make good changes to the guide.

C:\code\Version9\boost> C:\code\Version9\boost>bjam --toolset=msvc stage notice: could not find main target stage notice: assuming it's a name of file to create. C:/code/Version9/boost/tools/build/v2/build\project.jam:699: in attribute warning: rulename $($(project).attributes).get expands to empty string C:/code/Version9/boost/tools/build/v2/build\project.jam:710: in project.target C:/code/Version9/boost/tools/build/v2\build-system.jam:641: in load C:\code\Version9\boost\tools\build\v2/kernel\modules.jam:267: in import C:\code\Version9\boost\tools\build\v2/kernel/bootstrap.jam:132: in boost-build C:\code\Version9\boost\boost-build.jam:11: in module scope C:/code/Version9/boost/tools/build/v2/build\project.jam:699: in project.attribut e warning: rulename $($(project).attributes).get expands to empty string C:/code/Version9/boost/tools/build/v2/build\targets.jam:202: in object(project-t arget)@36.init C:/code/Version9/boost/tools/build/v2/kernel\class.jam:93: in new C:/code/Version9/boost/tools/build/v2/build\project.jam:710: in project.target C:/code/Version9/boost/tools/build/v2\build-system.jam:641: in load C:\code\Version9\boost\tools\build\v2/kernel\modules.jam:267: in import C:\code\Version9\boost\tools\build\v2/kernel/bootstrap.jam:132: in boost-build C:\code\Version9\boost\boost-build.jam:11: in module scope C:/code/Version9/boost/tools/build/v2/build\project.jam:699: in project.attribut e warning: rulename $($(project).attributes).get expands to empty string C:/code/Version9/boost/tools/build/v2/build\targets.jam:221: in get C:/code/Version9/boost/tools/build/v2/build\targets.jam:283: in targets-to-build

C:/code/Version9/boost/tools/build/v2/build\targets.jam:252: in object(project-t arget)@36.generate C:/code/Version9/boost/tools/build/v2\build-system.jam:658: in load C:\code\Version9\boost\tools\build\v2/kernel\modules.jam:267: in import C:\code\Version9\boost\tools\build\v2/kernel/bootstrap.jam:132: in boost-build C:\code\Version9\boost\boost-build.jam:11: in module scope C:/code/Version9/boost/tools/build/v2/build\project.jam:699: in project.attribut e warning: rulename $($(project).attributes).get expands to empty string C:/code/Version9/boost/tools/build/v2/build\targets.jam:221: in get C:/code/Version9/boost/tools/build/v2/build\targets.jam:284: in targets-to-build

C:\code\Version9\boost>

Vladimir Prus — Thu, 27 Mar 2008 14:44:43 GMT

http://boost.org/boost-build2/doc/html/ix01.html has links to 64-bit building instructions for msvc.

Your other point is about building both sets of compiled libraries. As far as pre-compiled installer goes, I think this is outside the scope of this issue. Those installers are provided by BoostConsulting, so you can report the problem directly to them. As for building both sets of libraries, I'm not sure either. I believe 1.35.* will build a single variant by default. You can request extra variants on the command line.

So, that leaves one issue, is that you suggest that 32-bit and 64-bit binaries be placed to different 'stage' directories. Is that right?

As for your last issue -- do you have file C:\code\Version9\boost\Jamroot? It seems like something is seriously wrong with your source tree.

snuchia@… — Thu, 27 Mar 2008 22:15:13 GMT

the three files with extension-free names in the root directory are missing from the .zip snapshots at http://boost.cowic.de/rc/ ; this would seem to be a flaw in the snapshot packaging process. Perhaps a *.* effect?

With Jamroot in place I'm having much better luck.

The documentation suggested is tantalizing but hardly a step-by-step instruction. It gives some syntax but no clue where I'd put it. It does not look anything like the command line syntax for bjam.

I've been working with open-source software for over twenty years and I've seen some pretty mystifing install instructions. Boost isn't actually bad by the standards of, say, TeX in the late 80's, but the ramp could be smoother. In the previous release I used the makefiles and VS solution files to build Regex and Test manually; we didn't need anything else. Today was my first time to run bjam successfully.

Anyway, thanks for the help. I'll work out in detail what (if anything) I think should be changed and add another note when I'm done.

snuchia@… — Fri, 28 Mar 2008 15:22:44 GMT

The built-in Zip handler in Windows Server 2003, x64 edition fails to extract files with no dots in their names. There is no problem with the archives; the documentation recommends against using Microsoft's zip handler on performance grounds anyway but I have been trying to minimize the number of non-standard programs on this machine so I was trying to use it.

More to come. -steve

status changed; resolution set

Vladimir Prus — Sun, 31 May 2009 19:08:52 GMT

status new → closed
resolution → fixed

I have checked in a change to make the 'Invocation' section of Boost.Build explicitly list the address-model feature. Now that getting started guide directly links to the invocation section, I think the discovery process is sufficiently streamlined.

As for building both 32-bit and 64-bit libraries by default, this does not seem to be a good idea to me -- we're trying to move away from 'build 8 variants and eat 4GB of disk space' approach take earlier. Therefore, I am not planning to do this. If you disagree, it would be best to discuss this on the mailing list, where real Windows experts and users may be able to comments on approaches.