32- and 64-bit builds on same machine
Hi, What is the most convenient way to build Boost if I need both 32- and 64-bit builds on the same Windows machine? I could of course install two separate copies of the entire Boost source tree, and build one from the 32-bit Visual studio command prompt, and the other from the 64-bit Visual Studio command prompt. But that seems a bit wasteful. I tried building from the same source tree twice, once using the 32-bit command prompt and once using the 64-bit command prompt, but that did not work. (Nothing happened during the second build.) Thank you, Johan Råde
Did you set : address-model=64 On Fri, Aug 13, 2010 at 1:52 PM, Johan Råde <rade@maths.lth.se> wrote:
Hi,
What is the most convenient way to build Boost if I need both 32- and 64-bit builds on the same Windows machine?
I could of course install two separate copies of the entire Boost source tree, and build one from the 32-bit Visual studio command prompt, and the other from the 64-bit Visual Studio command prompt. But that seems a bit wasteful.
I tried building from the same source tree twice, once using the 32-bit command prompt and once using the 64-bit command prompt, but that did not work. (Nothing happened during the second build.)
Thank you, Johan Råde
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Friday, August 13, 2010 9:53 AM, Johan Råde wrote:
What is the most convenient way to build Boost if I need both 32- and 64-bit builds on the same Windows machine?
I used the following batch file (Apologies if Outlook lie wraps it. It should have 6 lines): ------Begin Batch file------ Rem Visual Studio 2010 .\bjam --build-dir=C:\boost_intermediate --prefix=C:\boost64 toolset=msvc-10.0 address-model=64 link=static runtime-link=static,shared threading=multi variant=debug,release embed-manifest=on --without-python --without-mpi -sBZIP2_SOURCE="C:\bzip2-1.0.4" -sZLIB_SOURCE="C:\zlib123" install .\bjam --build-dir=C:\boost_intermediate --prefix=C:\boost toolset=msvc-10.0 address-model=32 link=static runtime-link=static,shared threading=multi variant=debug,release embed-manifest=on --without-python --without-mpi -sBZIP2_SOURCE="C:\bzip2-1.0.4" -sZLIB_SOURCE="C:\zlib123" install Rem Visual Studio 2008 .\bjam --build-dir=C:\boost_intermediate --prefix=C:\boost64 toolset=msvc-9.0 address-model=64 link=static runtime-link=static,shared threading=multi variant=debug,release embed-manifest=on --without-python --without-mpi -sBZIP2_SOURCE="C:\bzip2-1.0.4" -sZLIB_SOURCE="C:\zlib123" install .\bjam --build-dir=C:\boost_intermediate --prefix=C:\boost toolset=msvc-9.0 address-model=32 link=static runtime-link=static,shared threading=multi variant=debug,release embed-manifest=on --without-python --without-mpi -sBZIP2_SOURCE="C:\bzip2-1.0.4" -sZLIB_SOURCE="C:\zlib123" install ------End Batch file------ This will create two target folders: C:\boost, which contains the 32-bit libraries and header files, and c:\boost64, which contains the 64-bit libraries and headers. Obviously, you may need to tweak it for your needs. Begin by adding or removing toolsets to match your environment. Each toolset needs a pair of bjam lines. I have set the following options in each line: --build-dir: The directory with the intermediate files. Not necessary, but I like to keep them out of the source directory. If you use this, don't point it to the boost source directory. I can't remember if you need to create this directory manually, or if boost build will do it for you. --prefix: The directory into which boost will be installed. The 32-bit and 64-bit variants MUST have different prefixes. If you install multiple versions of boost or target multiple toolsets, they can all go into the same pair of prefixes without conflict. toolset: the version of Visual Studio, mingw, or other compiler to target. address-model: should be self-explanatory link: Whether to build static or dynamic boost libraries. By default, Windows programs use the static libraries. Only change this if you really want the shared libraries. runtime-link: Produce boost libraries that link against both the static and shared runtime libraries. You can change this if you know you will always use the same runtime library. threading: Visual Studio hasn't shipped with a single-threaded runtime library in years. Don't change this. variant: I strongly recommend you leave this alone. embed-manifest: I can't remember what this one does. --without-python: I don't use python, and got tired of seeing the warnings. --without-mpi: Same for MPI. -sBZIP2_SOURCE: I do use the bzip2 filters with iostreams. Delete this option if you don't. If you do use bzip2, there is no need to build it; just unzip the source and point this option to it. -sZLIB_SOURCE: Same for zlib. install: I want to install boost to the prefix directory. After you get boost installed, you can delete the directory specified by --build-dir. I kept the source directory around so I have documentation, but you really only need to keep c:\boost and c:\boost64.
I could of course install two separate copies of the entire Boost source tree, and build one from the 32-bit Visual studio command prompt, and the other from the 64-bit Visual Studio command prompt. But that seems a bit wasteful.
There is no need to use the "Visual Studio" command prompts. Boost Build will find them itself.
Thank you for a detailed answer. Your script contains several nice features that I will incorporate in my own script. I have always been using "stage" in my script. You use "install". What is the difference? On 8/13/2010 4:32 PM, Andrew Holden wrote:
On Friday, August 13, 2010 9:53 AM, Johan Råde wrote:
What is the most convenient way to build Boost if I need both 32- and 64-bit builds on the same Windows machine?
I used the following batch file (Apologies if Outlook lie wraps it. It should have 6 lines):
------Begin Batch file------
Rem Visual Studio 2010
..\bjam --build-dir=C:\boost_intermediate --prefix=C:\boost64 toolset=msvc-10.0 address-model=64 link=static runtime-link=static,shared threading=multi variant=debug,release embed-manifest=on --without-python --without-mpi -sBZIP2_SOURCE="C:\bzip2-1.0.4" -sZLIB_SOURCE="C:\zlib123" install
..\bjam --build-dir=C:\boost_intermediate --prefix=C:\boost toolset=msvc-10.0 address-model=32 link=static runtime-link=static,shared threading=multi variant=debug,release embed-manifest=on --without-python --without-mpi -sBZIP2_SOURCE="C:\bzip2-1.0.4" -sZLIB_SOURCE="C:\zlib123" install
Rem Visual Studio 2008
..\bjam --build-dir=C:\boost_intermediate --prefix=C:\boost64 toolset=msvc-9.0 address-model=64 link=static runtime-link=static,shared threading=multi variant=debug,release embed-manifest=on --without-python --without-mpi -sBZIP2_SOURCE="C:\bzip2-1.0.4" -sZLIB_SOURCE="C:\zlib123" install
..\bjam --build-dir=C:\boost_intermediate --prefix=C:\boost toolset=msvc-9.0 address-model=32 link=static runtime-link=static,shared threading=multi variant=debug,release embed-manifest=on --without-python --without-mpi -sBZIP2_SOURCE="C:\bzip2-1.0.4" -sZLIB_SOURCE="C:\zlib123" install
------End Batch file------
This will create two target folders: C:\boost, which contains the 32-bit libraries and header files, and c:\boost64, which contains the 64-bit libraries and headers.
Obviously, you may need to tweak it for your needs. Begin by adding or removing toolsets to match your environment. Each toolset needs a pair of bjam lines. I have set the following options in each line:
--build-dir: The directory with the intermediate files. Not necessary, but I like to keep them out of the source directory. If you use this, don't point it to the boost source directory. I can't remember if you need to create this directory manually, or if boost build will do it for you.
--prefix: The directory into which boost will be installed. The 32-bit and 64-bit variants MUST have different prefixes. If you install multiple versions of boost or target multiple toolsets, they can all go into the same pair of prefixes without conflict.
toolset: the version of Visual Studio, mingw, or other compiler to target.
address-model: should be self-explanatory
link: Whether to build static or dynamic boost libraries. By default, Windows programs use the static libraries. Only change this if you really want the shared libraries.
runtime-link: Produce boost libraries that link against both the static and shared runtime libraries. You can change this if you know you will always use the same runtime library.
threading: Visual Studio hasn't shipped with a single-threaded runtime library in years. Don't change this.
variant: I strongly recommend you leave this alone.
embed-manifest: I can't remember what this one does.
--without-python: I don't use python, and got tired of seeing the warnings.
--without-mpi: Same for MPI.
-sBZIP2_SOURCE: I do use the bzip2 filters with iostreams. Delete this option if you don't. If you do use bzip2, there is no need to build it; just unzip the source and point this option to it.
-sZLIB_SOURCE: Same for zlib.
install: I want to install boost to the prefix directory.
After you get boost installed, you can delete the directory specified by --build-dir. I kept the source directory around so I have documentation, but you really only need to keep c:\boost and c:\boost64.
I could of course install two separate copies of the entire Boost source tree, and build one from the 32-bit Visual studio command prompt, and the other from the 64-bit Visual Studio command prompt. But that seems a bit wasteful.
There is no need to use the "Visual Studio" command prompts. Boost Build will find them itself.
On Friday, August 13, 2010 11:10 AM, Johan Råde wrote:
Thank you for a detailed answer. Your script contains several nice features that I will incorporate in my own script.
I have always been using "stage" in my script. You use "install". What is the difference?
I've never really used stage, so I might get this wrong. As I understand it, stage is designed to place the build results in the source tree. I think under a "stage" directory just under the top level. "install" is designed to place the build results in a location that generally makes sense for the operating system. In Unix, I believe it puts libraries and header files in /usr/local. In Windows it defaults to C:\boost. In either operating system, you can use "--prefix" to change this. The structure of these directories is as follows: C:\ + boost + lib + include + boost-1_43 + boost + all headers and subdirectories here I must admit I don't know if "install" make any attempts to customize the include folder, or if it just copies every header file it can find. Although I just found mpi and python folders when I know I told it no mpi or python, which suggests it just copies all header files. I don't know if "stage" goes to the trouble of creating an include directory under its output directory. If you still prefer stage, I believe it has an equivalent option to "--prefix". The same rules should apply (32 and 64-bit variants need separate stage directories, different boost versions and toolsets can share the same stage directory).
I would like to do something like bjam toolset=msvc-9.0 ... stage bjam toolset=msvc-9.0 address-model=64 ... stage to build both the 32-bit and 64-bit libraries in the same source tree. However, this script will not work, because the 32- and 64-bit libraries will have the same names and be placed in the same folder, stage/lib. How do I fix that? How do I for instance get the 64-bit libraries in stage/lib(x64) instead? --Johan
On Friday, August 13, 2010 4:11 PM, Johan Råde wrote:
I would like to do something like
bjam toolset=msvc-9.0 ... stage bjam toolset=msvc-9.0 address-model=64 ... stage
to build both the 32-bit and 64-bit libraries in the same source tree. However, this script will not work, because the 32- and 64-bit libraries will have the same names and be placed in the same folder, stage/lib.
How do I fix that? How do I for instance get the 64-bit libraries in stage/lib(x64) instead?
The first thought that comes to mind is: bjam toolset=msvc-9.0 address-model=64 ... stage rename stage stage64 bjam toolset=msvc-9.0 address-model=32 ... stage or maybe bjam toolset=msvc-9.0 address-model=64 ... stage cd stage rename lib lib(x64) cd .. bjam toolset=msvc-9.0 address-model=32 ... stage
However, this script will not work, because the 32- and 64-bit libraries will have the same names and be placed in the same folder, stage/lib.
How do I fix that? How do I for instance get the 64-bit libraries in stage/lib(x64) instead?
The first thought that comes to mind is:
bjam toolset=msvc-9.0 address-model=64 ... stage rename stage stage64 bjam toolset=msvc-9.0 address-model=32 ... stage
I compile and test both 32 and 64-bit builds of a program. Unlike some final "install" environments where the directories are hidden and transparently forwarded depending on which kind of process is asking, when building and testing it's only sane to have normal files with normal names, and have all files visible to my command shells and other tools. So, name the files differently! Have 32- and 64-bit builds produce different names for the DLLs. Likewise with your programs' exe files (at least for unit tests and tools). It's also important to match the build options with that of your application. Several are incompatible. And for DLLs, you don't want the same named DLL in different places to be different things. But I've not seen a comprehensive naming convention for Boost for these specific flags (e.g. link against latest CRT or specific version of CRT; iterator debugging; secure library) --John TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
Johan Råde wrote:
I would like to do something like
bjam toolset=msvc-9.0 ... stage bjam toolset=msvc-9.0 address-model=64 ... stage
to build both the 32-bit and 64-bit libraries in the same source tree. However, this script will not work, because the 32- and 64-bit libraries will have the same names and be placed in the same folder, stage/lib.
How do I fix that? How do I for instance get the 64-bit libraries in stage/lib(x64) instead?
Use the --stagedir option: bjam ... --stagedir=stage32 stage bjam ... address-model=64 --stagedir=stage64 stage -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell@blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560
On 8/13/2010 10:40 PM, Richard Hadsell wrote:
Johan Råde wrote:
I would like to do something like
bjam toolset=msvc-9.0 ... stage bjam toolset=msvc-9.0 address-model=64 ... stage
to build both the 32-bit and 64-bit libraries in the same source tree. However, this script will not work, because the 32- and 64-bit libraries will have the same names and be placed in the same folder, stage/lib.
How do I fix that? How do I for instance get the 64-bit libraries in stage/lib(x64) instead?
Use the --stagedir option:
bjam ... --stagedir=stage32 stage bjam ... address-model=64 --stagedir=stage64 stage
Where is the stagedir option documented? I can not find it in the Boost 1.43 docs.
Johan Råde wrote:
On 8/13/2010 10:40 PM, Richard Hadsell wrote:
Johan Råde wrote:
I would like to do something like
bjam toolset=msvc-9.0 ... stage bjam toolset=msvc-9.0 address-model=64 ... stage
to build both the 32-bit and 64-bit libraries in the same source tree. However, this script will not work, because the 32- and 64-bit libraries will have the same names and be placed in the same folder, stage/lib.
How do I fix that? How do I for instance get the 64-bit libraries in stage/lib(x64) instead?
Use the --stagedir option:
bjam ... --stagedir=stage32 stage bjam ... address-model=64 --stagedir=stage64 stage
Where is the stagedir option documented?
In "bjam --help" output. - Volodya
On Fri, Aug 13, 2010 at 1:10 PM, Johan Råde <rade@maths.lth.se> wrote:
I would like to do something like
bjam toolset=msvc-9.0 ... stage bjam toolset=msvc-9.0 address-model=64 ... stage
to build both the 32-bit and 64-bit libraries in the same source tree. However, this script will not work, because the 32- and 64-bit libraries will have the same names and be placed in the same folder, stage/lib.
How do I fix that? How do I for instance get the 64-bit libraries in stage/lib(x64) instead?
--Johan
It looks like "--layout" switch doesn't encode address-model at the moment. Maybe it can be extended with this information to let both 32bit and 64bit versions coexist?
On 8/13/2010 3:52 PM, Johan Råde wrote:
What is the most convenient way to build Boost if I need both 32- and 64-bit builds on the same Windows machine?
Thank you everyone for the help. Below is the build script (Windows batch file) that I eventually came up with. (There should be four lines, the mail client may have inserted extra line breaks.) ------ BEGIN SCRIPT ----- call bootstrap bjam toolset=msvc-9.0 address-model=32 runtime-link=shared threading=multi link=shared,static debug/define=_HAS_ITERATOR_DEBUGGING=0 release/define=_SECURE_SCL=0 --without-python --without-mpi -sZLIB_SOURCE=C:\Libraries\ZLib stage bjam toolset=msvc-9.0 address-model=64 runtime-link=shared threading=multi link=shared,static debug/define=_HAS_ITERATOR_DEBUGGING=0 release/define=_SECURE_SCL=0 --without-python --without-mpi -sZLIB_SOURCE=C:\Libraries\ZLib --stagedir=stage(x64) stage rmdir /s /q bin.v2 ----- END SCRIPT -----
participants (2)
-
Andrew Holden -
Bo Jensen -
Deng Xiyue -
Johan Råde -
John Dlugosz -
Richard Hadsell -
Vladimir Prus