Re: [VOTE] release stdcxx 4.2.0 (candidate 7)

Martin Sebor wrote: > Andrew Black wrote: >> I reviewed the README again, and I'm seeing a few nits, but I don't >> think they're worth holding the release up for (someone else may >> disagree). >> >> I feel the first paragraph of section 4.4 has a poorly worded or >> inaccurate description of wher

error in 26.valarray.transcend.stdcxx-315.cpp (was: Re: [VOTE] release stdcxx 4.2.0 (candidate 7))

Mark Brown wrote: Other than some warnings gcc 4.1.2 on Linux worked fine this time. I tried Intel 10.0 and found another test that gave a compiler error. I didn't investigate it in great detail but it looks like a problem in the test rather than a compiler bug. In any event, I don't see it as a

Re: [VOTE] release stdcxx 4.2.0 (candidate 7)

Andrew Black wrote: I reviewed the README again, and I'm seeing a few nits, but I don't think they're worth holding the release up for (someone else may disagree). I feel the first paragraph of section 4.4 has a poorly worded or inaccurate description of where the rwtest library lives. I'm not

Re: [VOTE] release stdcxx 4.2.0 (candidate 7)

I reviewed the README again, and I'm seeing a few nits, but I don't think they're worth holding the release up for (someone else may disagree). I feel the first paragraph of section 4.4 has a poorly worded or inaccurate description of where the rwtest library lives. I also wonder if the test harn

Re: [VOTE] release stdcxx 4.2.0 (candidate 7)

Other than some warnings gcc 4.1.2 on Linux worked fine this time. I tried Intel 10.0 and found another test that gave a compiler error. I didn't investigate it in great detail but it looks like a problem in the test rather than a compiler bug. In any event, I don't see it as a blocker for the rel

Re: [VOTE] release stdcxx 4.2.0 (candidate 7)

Tested with gcc 4.1.1 on Fedora Core 6 (no BUILDTYPE or BUILDMODE just for kicks). Except for a few warnings during compilation there were no (unexpected) problems or surprises. +1. As reminder, the vote closes at 5PM today (http://tinyurl.com/2h5f73). It would be nice to get a few more votes in

RE: [VOTE] release stdcxx 4.2.0 (candidate 7)

> -Original Message- > From: Martin Sebor [mailto:[EMAIL PROTECTED] > Sent: Sunday, October 21, 2007 1:55 AM > To: stdcxx-dev@incubator.apache.org > Subject: [VOTE] release stdcxx 4.2.0 (candidate 7) > > I just created the next stdcxx 4.2.0 release candidate tag, > stdcxx-4.2.0-rc-7, tha

Re: [VOTE] release stdcxx 4.2.0 (candidate 7)

Liviu Nicoara wrote: Martin Sebor wrote: Liviu Nicoara wrote: +1. Thanks! Just for the record, what particular platform (compiler/OS) and configuration did you test the tarball on? Slack 10.1, gcc 4.2.0, 11s. I've got: PROGRAM SUMMARY: Programs:187 Non-zero exit status

Re: [VOTE] release stdcxx 4.2.0 (candidate 7)

Martin Sebor wrote: Liviu Nicoara wrote: +1. Thanks! Just for the record, what particular platform (compiler/OS) and configuration did you test the tarball on? Slack 10.1, gcc 4.2.0, 11s. I've got: PROGRAM SUMMARY: Programs:187 Non-zero exit status: 0 Signalled:

Re: [VOTE] release stdcxx 4.2.0 (candidate 7)

Liviu Nicoara wrote: +1. Thanks! Just for the record, what particular platform (compiler/OS) and configuration did you test the tarball on? Martin Martin Sebor wrote: I just created the next stdcxx 4.2.0 release candidate tag, stdcxx-4.2.0-rc-7, that incorporates changes addressing issues

Re: [VOTE] release stdcxx 4.2.0 (candidate 7)

+1. Martin Sebor wrote: I just created the next stdcxx 4.2.0 release candidate tag, stdcxx-4.2.0-rc-7, that incorporates changes addressing issues pointed out in the original vote thread. http://svn.apache.org/repos/asf/incubator/stdcxx/tags/4.2.0-rc-7/ The tarball containing the release candid