Re: [Boost-users] Problems compiling those libraries that are not header only on 64 bit Windows 7

Subject: Re: [Boost-users] Problems compiling those libraries that are not header only on 64 bit Windows 7
From: Ted Byers (r.ted.byers_at_[hidden])
Date: 2011-01-29 15:41:42

Thanks Jim

>-----Original Message-----
>From: boost-users-bounces_at_[hidden]
[mailto:boost-users-bounces_at_[hidden]] On Behalf Of Jim Bell
>Sent: January-29-11 1:31 PM
>To: boost-users_at_[hidden]
>Subject: Re: [Boost-users] Problems compiling those libraries that are not
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).
>
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?

>Also, see https://svn.boost.org/trac/boost/ticket/4839 for a batch of
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