On Thu, Jan 27, 2011 at 12:18:17PM +0300, Vladimir Prus wrote:

Ted Byers wrote:

...

I have two versions of MS VS: MS VS 2005 and MS VS 2010. I guess my first question is, "Will library files produced by MS VS 2005 work with MS VS 2010?" I know that library files compiled by compilers from different sources (gcc vs MSVC) won't work with each other (unless the library was written in C or FORTRAN), but does the same apply to different versions fo the same compiler?

In general, the library format between VS versions is not forward or backward compatible. This is primarily due to using different runtime versions, but also due to that the MSIL (not the .NET IL) of .lib files is not guaranteed to be compatible between versions. Such IL is generated if you have options like Link-Time Code Generation and other fancy settings. As for properly portable libraries, that tends to involve a rather restricted language subset for the interface and building against a common runtime, like the one that the DDK compilers targets.

...

I used a prebuilt distribution of bjam for all my attempts to build the boost libraries using msvc++. I did not compile it myself.

Please use the bootstrap.bat script to build bjam from the 1.45 release, and then use it.

...

bjam --build-dir=C:\boost_1_45_0\lib\msvc2010\x32 --build-type=complete

bjam --build-dir=C:\boost_1_45_0\lib\msvc2010\x64 --build-type=complete

I am somewhat confused -- those two commands differ only in --build-dir option, therefore they will build boost using the same version of the same compiler. If you with to use different versions, specify toolset=msvc-10.0 and toolset=msvc-9.0 during those invocations. Also, use address-model=64 if you wish to build 64-bit libraries. See:

I assume you mean msvc-8.0, as he says he's on 2005. Note that the build system will completely ignore whether you're in a "Visual Studio 2010 Command Prompt" or in a "Visual Studio 2005 Command Prompt", and will also ignore the bitness of said command prompt environment. You need to specify toolset=msvc-x.y and address-model=zz if you want to target a specific toolset version and bitness.

You should also use --stagedir=XXX to put the final build products into different directories. --build-dir is only for specifying intermediate directory.

Or --prefix=XXX if you're doing an 'install' instead of a 'stage' (stage is default). -- Lars Viklund | zao@acc.umu.se

Thanks Vladimir -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Vladimir Prus Sent: January-27-11 4:18 AM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Problems compiling those libraries that are not header only on 64 bit Windows 7 Ted Byers wrote:

...

I used a prebuilt distribution of bjam for all my attempts to build the boost libraries using msvc++. I did not compile it myself.

Please use the bootstrap.bat script to build bjam from the 1.45 release, and then use it.

...

...

From the C:\boost_1_45_0 directory, I tried the following to keep the builds for the two versions separate (planning on changing the library directories based on the build environment), but when both finished, both C:\boost_1_45_0\lib\msvc2010\x64 and bjam --build-dir=C:\boost_1_45_0\lib\msvc2010\x32 were empty and C:\boost_1_45_0\stage\lib had 606 items.

bjam --build-dir=C:\boost_1_45_0\lib\msvc2010\x32 --build-type=complete

bjam --build-dir=C:\boost_1_45_0\lib\msvc2010\x64 --build-type=complete

I am somewhat confused -- those two commands differ only in --build-dir

OK, I'll try that today. option, therefore they will build boost using the same version of the same compiler.

If you with to use different versions, specify toolset=msvc-10.0 and toolset=msvc-9.0 during those invocations. Also, use address-model=64 if you wish to build 64-bit libraries. See:

I guess I should have also said I did these in different shells, one with the environment for msvc2005, msvc 2010, and the cygwin bash shell. I thought bjam would pick the right compiler/version from the environment because I had read that it autodetects the right version from the environment.

http://www.boost.org/boost-build2/doc/html/bbv2/reference/tools.html#bbv2.r eference.tools.compiler.msvc

You should also use --stagedir=XXX to put the final build products into different directories. --build-dir is only for specifying intermediate directory.

OK, I see. I didn't find what stage was for, so I didn't use it. Now I will.

...

And if I execute bjam in status, I get a result that says something like 30 out of 30K tests failed. (Is that normal?)

I think so. Thanks.

...

Here are the results from my latest attempt using cygwin.

$ ../boost-jam-3.1.18/bin.cygwinx86/bjam --layout=versioned --build-type=complete

warning: No toolsets are configured.

warning: Configuring default toolset "gcc".

warning: If the default is wrong, your build may not work correctly.

warning: Use the "toolset=xxxxx" option to override our guess.

warning: For more configuration options, please consult

warning: http://boost.org/boost-build2/doc/html/bbv2/advanced/configuration.htm l

Building the Boost C++ Libraries.

/home/Ted/boost_1_45_0/tools/build/v2/build/configure.jam:145: in builds-raw

*** argument error

* rule UPDATE_NOW ( targets * : log ? : ignore-minus-n ? )

You need to build bundled bjam using bootstrap.sh

OK, I'll try that today too. Thanks again Ted

Many thanks to all who responded, both on and off list. This is on 64 bit WIndows 7 Pro. I have finally mastered much of this (I think). I don't know if the following script would be helpful to anyone, but I post it in case it will be helpful to someone. bootstrap ..\bjam.exe -j%NUMBER_OF_PROCESSORS% toolset=msvc-8.0 toolset=msvc-10.0 --build-type=complete --libdir=C:\Boost\lib\i386 install ..\bjam.exe -j%NUMBER_OF_PROCESSORS% toolset=msvc-8.0 toolset=msvc-10.0 --build-type=complete --libdir=C:\Boost\lib\x64 architecture=x86 address-model=64 install cd status ..\bjam.exe -j%NUMBER_OF_PROCESSORS% toolset=msvc-8.0 toolset=msvc-10.0 --build-type=complete --libdir=C:\Boost\lib\i386 ..\bjam.exe -j%NUMBER_OF_PROCESSORS% toolset=msvc-8.0 toolset=msvc-10.0 --build-type=complete --libdir=C:\Boost\lib\x64 architecture=x86 address-model=64 Note, this builds everything for both versions of MSVC that I have, and places the 32 bit libraries in C:\Boost\lib\i386 and the 64 bit versions in C:\Boost\lib\x64. ...failed testing.capture-output ..\bin.v2\libs\filesystem\test\v3_operations_test.test\msvc-10.0\debug\addre ss-model-64\architecture-x86\asynch-exceptions-on\threading-multi\v3_operati ons_test.run... ...failed updating 121 targets... ...skipped 258 targets... ...updated 54807 targets... Is this result expected or normal? If this is expected, then my next step is to use this to build and test QuantLib 1.0.1 ... Would the output from the tests be helpful to anyone? How would I modify the ast two lines above so that the full output of the testing is stored in a file, and to whom would I email it if it would be helpful to anyone? Or should I just pipe it by adding "> output.file.dat" One final note about the above 'scriptlet': The bootstrap script finished in seconds, and the next two lines used no more than 30% of the CPU resources. Only did the last two statements use 100% of the CPU resources consistently. (This is a fast intel Core i7) This is the only time I have placed enough of a computing burden on this machine to use more than 25% of the CPU resources. Now, the results for building all in cygwin are not so good. Within the cygwin bash shell, I ran the following: ./bootstrap.sh ./bjam cd status ../bjam Now, that seemed to work, but I am not entirely convinced. Here is the last bit of output: C:\cygwin\home\Ted\boost_1_45_0\libs\filesystem\v3\src\unique_path.cpp:34: warning: ignoring #pragma comment gcc.compile.c++ ../bin.v2/libs/filesystem/build/gcc-4.3.4/release/link-static/v3/src/windows _file_codecvt.o gcc.archive ../bin.v2/libs/filesystem/build/gcc-4.3.4/release/link-static/libboost_files ystem.a gcc.compile.c++ ../bin.v2/libs/system/build/gcc-4.3.4/release/link-static/error_code.o gcc.archive ../bin.v2/libs/system/build/gcc-4.3.4/release/link-static/libboost_system.a gcc.link ../bin.v2/tools/bcp/test/bcp-test.test/gcc-4.3.4/release/link-static/bcp-tes t.exe testing.capture-output ../bin.v2/tools/bcp/test/bcp-test.test/gcc-4.3.4/release/link-static/bcp-tes t.run ====== BEGIN OUTPUT ====== **** exception(205): std::runtime_error: The Boost path appears to have been incorrectly set: could not find boost/version.hpp in /home/Ted/boost_1_45_0 ******** errors detected; see standard output for details ******** EXIT STATUS: 200 ====== END OUTPUT ====== PATH="/usr/bin:/usr/lib:/usr/lib32:/usr/lib64:$PATH" export PATH "../bin.v2/tools/bcp/test/bcp-test.test/gcc-4.3.4/release/link-static/bcp-te st.exe" --boost=/home/Ted/boost_1_45_0 --list boost > "../bin.v2/tools/bcp/test/bcp-test.test/gcc-4.3.4/release/link-static/bcp-te st.output" 2>&1 status=$? echo >> "../bin.v2/tools/bcp/test/bcp-test.test/gcc-4.3.4/release/link-static/bcp-te st.output" echo EXIT STATUS: $status >> "../bin.v2/tools/bcp/test/bcp-test.test/gcc-4.3.4/release/link-static/bcp-te st.output" if test $status -eq 0 ; then cp "../bin.v2/tools/bcp/test/bcp-test.test/gcc-4.3.4/release/link-static/bcp-te st.output" "../bin.v2/tools/bcp/test/bcp-test.test/gcc-4.3.4/release/link-static/bcp-te st.run" fi verbose=0 if test $status -ne 0 ; then verbose=1 fi if test $verbose -eq 1 ; then echo ====== BEGIN OUTPUT ====== cat "../bin.v2/tools/bcp/test/bcp-test.test/gcc-4.3.4/release/link-static/bcp-te st.output" echo ====== END OUTPUT ====== fi exit $status ...failed testing.capture-output ../bin.v2/tools/bcp/test/bcp-test.test/gcc-4.3.4/release/link-static/bcp-tes t.run... ...failed updating 172 targets... ...skipped 381 targets... ...updated 24948 targets... Take note of the line: **** exception(205): std::runtime_error: The Boost path appears to have been incorrectly set: could not find boost/version.hpp in /home/Ted/boost_1_45_0 That output is flat out wrong. I looked int hat directory and the header it complains about is in fact there. Should I be concerned about this, or be content that less than 1% of the targets failed on cygwin? Again, would the full output of these tests be helpful to anyone, and if so, how do I modify my last command so that the output goes to a file. Or should I just pipe it by adding "> output.file.dat." And to whom would I send it. Thanks again, Ted

-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Jim Bell Sent: January-29-11 1:31 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] Problems compiling those libraries that are not

Thanks Jim header only on 64 bit Windows 7 See my question below:

On 1:59 PM, Ted Byers wrote:

...

Many thanks to all who responded, both on and off list. This is on 64 bit WIndows 7 Pro.

[...]...failed testing.capture-output ..\bin.v2\libs\filesystem\test\v3_operations_test.test\msvc-10.0\debug \addre ss-model-64\architecture-x86\asynch-exceptions-on\threading-multi\v3_o perati ons_test.run... ...failed updating 121 targets... ...skipped 258 targets... ...updated 54807 targets...

Is this result expected or normal? If this is expected, then my next step is to use this to build and test QuantLib 1.0.1 ...

Now, the results for building all in cygwin are not so good. Within the cygwin bash shell, I ran the following:

./bootstrap.sh ./bjam cd status ../bjam

[...]...failed testing.capture-output ../bin.v2/tools/bcp/test/bcp-test.test/gcc-4.3.4/release/link-static/b cp-tes t.run... ...failed updating 172 targets... ...skipped 381 targets... ...updated 24948 targets...

[...]

As a point of reference, I have a boost trunk regression test for Win7-x64 (gcc 4.6 x64). See http://www.boost.org/development/tests/trunk/developer/summary.html. Though it's trunk (not release) it should be pretty similar, and give you an idea of what works (or can be made to work with my patches, below).

Also, see https://svn.boost.org/trac/boost/ticket/4839 for a batch of

Thanks. Is there a flag I can pass to bjam to produce output in a similar form, or do I have to resort to a manual parsing of that output it produces when executed in status? patches to get boost::thread to build. (A lot of other things are built on it.) I haven't had time to push to get these patches incorporated. Is this bug a regression in 1.46.0 from 1.45.0? I ask because when I check the stage and install directories, I find boost_thread has been built (both 32 bit and 64 bit in the case of MSVC). I did not see any errors related to it in the test output as it scrolled by, though most of the output was overwritten in the commandline window buffer by newer output. And in your table on the other page, it seems to work on both 32 bit and 64 bit MSVC-10 (I didn't find results for gcc4.3.4 in cygwin). Thanks again, Ted