Nabble - stdcxx-dev

(Roguewave) Nightly testing changes

2009-10-20T08:54:23Z

Greetings all.

I have performed another update to the nightly testing schedule for
STDCXX at RogueWave, resulting in the following changes:
* hpux-11.11-pa: Alter host pool used for testing.
* hpux-11.23-pa: Ditto.
* hpux-11.31-pa: Ditto. OS version patched to HPUX 11i v3 Update 5.
Testing with acc-3.63 and acc-3.73 has been removed to save cycles,
testing with acc-3.85 has been added (in addition to acc-3.74).
* hpux-11.31-ia64: OS version patched to HPUX 11i v3 Update 5. Testing
with acc-6.23 has been added (in addition to acc-6.16).
* aix-6.1-ppc: OS version added at Technology Level 3, Service Pack 1,
using vacpp-10.1.

--Andrew Black

Re: bite-size patch for driver.cpp (Solaris)

2009-09-04T05:58:04Z

On Fri, Sep 4, 2009 at 05:48, Farid Zaripov<faridz@...> wrote:

> Looks like the attachment got stripped. Could you insert the patch
> into message as plain text? Another way is create JIRA issue and attach
> patch to the created issue.

Hi Farid,

I created JIRA STDCXX-1042 with patch attachment.

--Stefan

--
Stefan Teleman
KDE e.V.
stefan.teleman@...

RE: bite-size patch for driver.cpp (Solaris)

2009-09-04T02:48:29Z

Hi Stefan.

> This is a bite-size patch for driver.cpp for Solaris -- it
> adds support for the next Solaris version (SunOS 5.11).

Looks like the attachment got stripped. Could you insert the patch
into message as plain text? Another way is create JIRA issue and attach
patch to the created issue.

Farid

bite-size patch for driver.cpp (Solaris)

2009-09-03T09:30:09Z

Hi.

This is a bite-size patch for driver.cpp for Solaris -- it adds
support for the next Solaris version (SunOS 5.11).

--Stefan

--
Stefan Teleman
KDE e.V.
stefan.teleman@...

Re: std::length_error in language support library

2009-09-01T03:54:39Z

> It turns out that there already is an issue to revert this change:
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#805
>
> If Microsoft implemented the resolution of issue 624 they will
> need to revert it.

I've reopened the issue with quoting text from CWG issue 805.

(https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedb
ackID=457862)

> If you can devise a test case that triggers an exception from any
> shared_ptr operation in the Microsoft implementation it would be
> enough to file a bug report with them and might help convince them
> to take std::length_error out of the runtime library.

Unfortunately, it is not possible. It is the same as make test that
triggers an exception from the following code:

void foo(args)
{
if (false)
throw std::length_error();
else
do_something(args);
}

Farid.

Re: std::length_error in language support library

2009-08-31T16:41:23Z

On 08/31/2009 01:26 PM, Martin Sebor wrote:

> On 08/21/2009 10:34 AM, Farid Zaripov wrote:
>> Looking at the latest draft of the C++ standard (n2914.pdf) it appears,
>> that
>> the std::length_error can be defined in language support library.
>>
>> This is the result of resolution of the CWG issue #624:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#624
>
> That's a problem. Let me see if there's any willingness among
> the committee to revert it to bad_alloc.

It turns out that there already is an issue to revert this change:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#805

If Microsoft implemented the resolution of issue 624 they will
need to revert it. Ditto if they throw length_error from standard
functions that aren't allowed to throw it. In particular, if they
throw it (or any other exceptions) from any std::shared_ptr
operation they are in violation of 18.8.5 Exception Propagation
[propagation], p2:

-2- exception_ptr shall be DefaultConstructible, CopyConstructible,
CopyAssignable, and EqualityComparable. exception_ptr’s
operations shall not throw exceptions.

If you can devise a test case that triggers an exception from any
shared_ptr operation in the Microsoft implementation it would be
enough to file a bug report with them and might help convince them
to take std::length_error out of the runtime library.

>
> Martin
>
>>
>> 5.4.3 p7:
>> --------------
>> 7 When the value of the expression in a noptr-new-declarator is zero, the
>> allocation function is called to
>> allocate an array with no elements. If the value of that expression is
>> such
>> that the size of the allocated object
>> would exceed the implementation-defined limit, no storage is obtained and
>> the new-expression terminates
>> by throwing an exception of a type that would match a handler (15.3)
>> of type
>> std::length_error (19.2.4).
>> --------------
>>
>> Farid
>>
>

Re: std::length_error in language support library

2009-08-31T12:26:15Z

On 08/21/2009 10:34 AM, Farid Zaripov wrote:
> Looking at the latest draft of the C++ standard (n2914.pdf) it appears,
> that
> the std::length_error can be defined in language support library.
>
> This is the result of resolution of the CWG issue #624:
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#624

That's a problem. Let me see if there's any willingness among
the committee to revert it to bad_alloc.

Martin

>
> 5.4.3 p7:
> --------------
> 7 When the value of the expression in a noptr-new-declarator is zero, the
> allocation function is called to
> allocate an array with no elements. If the value of that expression is such
> that the size of the allocated object
> would exceed the implementation-defined limit, no storage is obtained and
> the new-expression terminates
> by throwing an exception of a type that would match a handler (15.3) of type
> std::length_error (19.2.4).
> --------------
>
> Farid
>

RE: svn commit: r777603 - in /stdcxx/branches/4.2.x: etc/config/src/ src/

2009-08-27T06:56:29Z

> -----Original Message-----l
> From: Martin Sebor [mailto:msebor@...]
> Sent: Wednesday, August 26, 2009 1:02 AM
> To: dev@...
> Subject: Re: svn commit: r777603 - in /stdcxx/branches/4.2.x:
> etc/config/src/ src/
>
> I'm not sure I understand what they are proposing we do in
> the MSVC bug report. Do you?

As I understand they are telling that if std::length_error dtor is defined
in
application, in this case the application will be linked without errors and
overridden std::length_error dtor will be used.

In our case the std::length_error dtor is defined in library, that's why
linker issues the "multiple symbols defined" error.

To avoid this error we can define std::length_error dtor as inline, to
define it in user's application and override the dtor from libc.

Farid.

Re: svn commit: r777603 - in /stdcxx/branches/4.2.x: etc/config/src/ src/

2009-08-25T15:01:31Z

On 08/18/2009 02:53 AM, Farid Zaripov wrote:

>>> Actually, the MSVC 10.0 beta libc contains dtor's for std::length_error
>>> and std::logic_error only (at least in 15s configuration which I've
> tested).
>>> It is still beta for now, but I believe that these dtors will go to the
>>> release.
>>>
>>> Or should I fill the bug report to Microsoft on that issue?
>>
>> That would be great, thanks! With dtors for arbitrary C++ Standard
>> Library in their libc there's no way to build/use a third party
>> implementation such as stdcxx. Imagine one of the dtors doing
>> something to the class, e.g.:
>>
>> class length_error: runtime_error { // MSVC 10 definition
>> char* data;
>> public:
>> virtual ~length_error () { delete[] data; }
>> // ...
>> }
>
> I've filled the issue to MS, but today they resolved this issue
> with status "by design" :(

That's very bad. In stdcxx, length_error and all other exception
classes described outside of [lib.language.support] derive from
an intermediate base class, __rw::__rw_exception, which takes
care of memory management on their behalf. Failing to define
the destructors of these classes and invoking those defined in
MSVC's runtime library will, in addition to exposing programs
to the risk mentioned above, bypass the memory management
functions in stdcxx and lead to leaks.

I'm not sure I understand what they are proposing we do in the
MSVC bug report. Do you?

Martin

>
> http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedbac
> kID=457862
>
> Best Regards,
> Farid Zaripov
>

Re: Problem building Standard Library

2009-08-23T17:46:35Z

Jeremy Dean-3 wrote:

I have a customer on Suse Linux 10update2 that is trying to build apache
Standard Library stdcxx-4.2.1.1 (Sourcepro edition 10 update 1). They
are getting the error described in
http://issues.apache.org/jira/browse/STDCXX-1029

I recommended that customer reinstall Suse Linux 10.0 as that what was
certified. Here are the steps they took, but are still getting the
error described:

We reinstalled Suse Linux 10.2 without GCC 4.1.2. I then installed GCC
4.1.0 from the given website. Afterwards, I reinstalled the latest
version of SourcePro and built it.
When we tried building our library again, we still get the
_RWSTD_SEEK_SET compile error. So we are using everything as
recommended, but the issue still exists. Can you help?

Thanks,

Jeremy

Jeremy Dean
Rogue Wave Software, Inc.
Technical Support
Phone: 303-545-3205 -- 1-800-404-4767
E-mail: support@roguewave.com
Web: http://www.roguewave.com/support
Knowledge Base entries:
http://www.roguewave.com/kbdocs/search.html
View issues online at:
http://www.roguewave.com/youraccount/login/

Marked! I will come back to check this soon!thanks a lot.:-)
[url=http://creditimmobilierdefrance.org/][color=#FFFFFF][u]simulation taux banque credit immobilier de France[/u][/color][/url][color=#FFFFFF] - Credit immobilier de France, simulation credit immobilier. Résultat mitigé pour le crédit immobilier de France.[/color][url=http://creditimmobilierdefrance.org/][color=#FFFFFF][u]simulation taux banque credit immobilier de France[/u][/color][/url]

std::length_error in language support library

2009-08-21T09:34:20Z

Looking at the latest draft of the C++ standard (n2914.pdf) it appears,
that
the std::length_error can be defined in language support library.

This is the result of resolution of the CWG issue #624:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#624

5.4.3 p7:
--------------
7 When the value of the expression in a noptr-new-declarator is zero, the
allocation function is called to
allocate an array with no elements. If the value of that expression is such
that the size of the allocated object
would exceed the implementation-defined limit, no storage is obtained and
the new-expression terminates
by throwing an exception of a type that would match a handler (15.3) of type
std::length_error (19.2.4).
--------------

Farid

Re: svn commit: r777603 - in /stdcxx/branches/4.2.x: etc/config/src/ src/

2009-08-18T01:53:24Z

>> Actually, the MSVC 10.0 beta libc contains dtor's for std::length_error
>> and std::logic_error only (at least in 15s configuration which I've
tested).

>> It is still beta for now, but I believe that these dtors will go to the
>> release.
>>
>> Or should I fill the bug report to Microsoft on that issue?
>
> That would be great, thanks! With dtors for arbitrary C++ Standard
> Library in their libc there's no way to build/use a third party
> implementation such as stdcxx. Imagine one of the dtors doing
> something to the class, e.g.:
>
> class length_error: runtime_error { // MSVC 10 definition
> char* data;
> public:
> virtual ~length_error () { delete[] data; }
> // ...
> }

I've filled the issue to MS, but today they resolved this issue
with status "by design" :(

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedbac
kID=457862

Best Regards,
Farid Zaripov

Re: Soalris 10 10/2008 SPARC changes

2009-08-17T16:17:08Z

Stefan Teleman wrote:

> On Fri, Aug 14, 2009 at 16:24, Martin Sebor<msebor@...> wrote:
>> Thanks for the heads up and the patches! I'll review apply them
>> if possible/necessary before the release.
>>
>> I took a quick glance at a few of the diff files and I wonder if
>> you could help me better understand some of the changes in case
>> they could be applied unconditionally.
>>
>> For instance, in ctype.cpp.38.diff, it seems as though the second
>> hunk would be a good change to make regardless (when long long is
>> available). Ditto for the third hunk in locale_body.37.diff (minus
>> the pragmas, of course), and similarly in locale_classic.40.diff
>> and messages.cpp.41.diff.
>>
>> The approach I'm thinking of using is the one you applied in
>> use_facet.h, i.e., defining, say, _RWSTD_ALIGN_MAX_T to unsigned
>> long long, and using it in all the aligned buffers, along with
>> unsigned char for the data.
>>
>> Other than these, can you also help me understand the changes in
>> messages.cpp.41.diff (starting with the third hunk on line 92)?
>
> That's my bad mistake -- i created a diff for src/messages.cpp from an
> older version of messages.cpp (hacked while i was trying to figure out
> why it was misbehaving so badly on 32-bit SPARCv8).
>
> I updated the tarball and the messages.cpp.41.diff itself with a valid
> patch now. Sorry for the noise.

No problem. I'll take a look.

>
> About
>
> int ret = catclose (pcat_data->catd);
>
> // ...
>
> cat_closed = ret == 0;
>
> My understanding of 22.2.7.1.2, p5 (catalog must be valid) is that --
> if catclose(3C) fails, it means the catalog was not valid -- therefore
> the C++ library must throw. So, cat_closed is now true if and only if
> catclose(3C) succeeded. Or is this too restrictive ?

You're right that we should check the value returned from catclose().
I think the facet guarantees that the catalog descriptor is valid so
I think we're safe in that regard. The case where I think there is
a problem is when catclose() fails because of a signal (with EINTR).
That would make __rw_catclose() and the facet dtor leak the catd.
Let me see about fixing that. Thanks for pointing it out!

>
> About the other patches -- and whether or not they should be applied
> for other platforms besides Solaris/SPARC: i tried not to disturb any
> other ISA's/compiler combinations. If you'd like i can re-write the
> patches for 4.2.2 using the more generic approach you described.

Understood.

Thanks again!
Martin

>
> --Stefan
>

Re: Soalris 10 10/2008 SPARC changes (was: Re: 4.2.2 release)

2009-08-17T07:27:37Z

On Fri, Aug 14, 2009 at 16:24, Martin Sebor<msebor@...> wrote:

> Thanks for the heads up and the patches! I'll review apply them
> if possible/necessary before the release.
>
> I took a quick glance at a few of the diff files and I wonder if
> you could help me better understand some of the changes in case
> they could be applied unconditionally.
>
> For instance, in ctype.cpp.38.diff, it seems as though the second
> hunk would be a good change to make regardless (when long long is
> available). Ditto for the third hunk in locale_body.37.diff (minus
> the pragmas, of course), and similarly in locale_classic.40.diff
> and messages.cpp.41.diff.
>
> The approach I'm thinking of using is the one you applied in
> use_facet.h, i.e., defining, say, _RWSTD_ALIGN_MAX_T to unsigned
> long long, and using it in all the aligned buffers, along with
> unsigned char for the data.
>
> Other than these, can you also help me understand the changes in
> messages.cpp.41.diff (starting with the third hunk on line 92)?

That's my bad mistake -- i created a diff for src/messages.cpp from an
older version of messages.cpp (hacked while i was trying to figure out
why it was misbehaving so badly on 32-bit SPARCv8).

I updated the tarball and the messages.cpp.41.diff itself with a valid
patch now. Sorry for the noise.

About

int ret = catclose (pcat_data->catd);

// ...

cat_closed = ret == 0;

My understanding of 22.2.7.1.2, p5 (catalog must be valid) is that --
if catclose(3C) fails, it means the catalog was not valid -- therefore
the C++ library must throw. So, cat_closed is now true if and only if
catclose(3C) succeeded. Or is this too restrictive ?

About the other patches -- and whether or not they should be applied
for other platforms besides Solaris/SPARC: i tried not to disturb any
other ISA's/compiler combinations. If you'd like i can re-write the
patches for 4.2.2 using the more generic approach you described.

--Stefan

--
Stefan Teleman
stefan.teleman@...

Soalris 10 10/2008 SPARC changes (was: Re: 4.2.2 release)

2009-08-14T13:24:40Z

Thanks for the heads up and the patches! I'll review apply them
if possible/necessary before the release.

I took a quick glance at a few of the diff files and I wonder if
you could help me better understand some of the changes in case
they could be applied unconditionally.

For instance, in ctype.cpp.38.diff, it seems as though the second
hunk would be a good change to make regardless (when long long is
available). Ditto for the third hunk in locale_body.37.diff (minus
the pragmas, of course), and similarly in locale_classic.40.diff
and messages.cpp.41.diff.

The approach I'm thinking of using is the one you applied in
use_facet.h, i.e., defining, say, _RWSTD_ALIGN_MAX_T to unsigned
long long, and using it in all the aligned buffers, along with
unsigned char for the data.

Other than these, can you also help me understand the changes in
messages.cpp.41.diff (starting with the third hunk on line 92)?

Thanks again,
Martin

Stefan Teleman wrote:

> On Fri, Aug 14, 2009 at 15:18, Martin Sebor<msebor@...> wrote:
>> I think we should think about cutting a 4.2.2 release sometime this
>> month. It's been embarrassingly long since 4.2.1. Farid (or anyone
>> else), do you have anything that you'd like included in it?
>>
>> Martin
>
> Hi.
>
> Solaris 10 10/2008 SPARC has introduced a binary incompatible change
> in the POSIX and Solaris threads implementation:
>
> http://docs.sun.com/app/docs/doc/820-5245/chapter2-1000?a=view
>
> <QUOTE>
>
> Objects of type mutex_t and pthread_mutex_t must start at 8-byte
> aligned addresses. Applications that do not satisfy this requirement
> fail. The following error message is displayed:
>
> *** _THREAD_ERROR_DETECTION: lock usage error detected ***
> ...
> "mutex is misaligned"
> OR:
> "condvar is misaligned"
>
> </QUOTE>
>
> In reality, the run-time performance is much worse than the errata
> above claims: misaligned mutexes or conditional variables cause the
> program to spuriously SEGV in sometimes hard to reproduce ways [
> Heisenbug ].
>
> You can view full details of this bug/change here:
>
> http://bugs.opensolaris.org/view_bug.do?bug_id=6729759
>
> To make a long story short, Solaris Kernel Update 137111-01 introduced
> an ABI incompatible implementation restriction, requiring that mutexes
> and conditional variables must be 8-byte aligned. This restriction has
> never been documented, nor has it ever been enforced, until Solaris 10
> 10/2008 [ Solaris Kernel Update 137111-01 ].
>
> The consequence of this KU is that, the multi-threaded 32-bit SPARC
> version of the Apache Standard C++ Library [ 4.2.1 ] will no longer
> work, and will fail at run-time with seemingly unexplainable crashes [
> the exact same build will work on Solaris versions prior to Kernel
> Update 137111-01 ].
>
> This problem is not specific to the Apache Standard C++ Library: it
> will occur with any 32-bit SPARCV8 binaries which do not align mutexes
> or conditional variables on an 8 byte boundary.
>
> I have created a set of patches for the Apache Standard C++ Library,
> Version 4.2.1, for this problem:
>
> http://s247136804.onlinehome.us/stdcxx-upstream/4.2.1/
>
> You can download the tarball with all the patches from the same URL:
>
> http://s247136804.onlinehome.us/stdcxx-upstream/4.2.1/stdcxx-upstream-patches.tar.bz2
>
> These patches force an 8-byte alignment for all objects which contain
> a mutex or a conditional variable, and that only for SPARC. With these
> patches, all the tests perform as expected.
>
> The patch 22.locale.numpunct.cpp.43.diff is not related to the SPARCV8
> ABI change -- it is simply an avoidance of a SEGV in case the variable
> first_non_c == NULL [ Solaris sprintf(3C) SEGV's on NULL char*
> arguments ].
>
> --Stefan
>

Re: 4.2.2 release

2009-08-14T12:27:56Z

On Fri, Aug 14, 2009 at 15:18, Martin Sebor<msebor@...> wrote:
> I think we should think about cutting a 4.2.2 release sometime this
> month. It's been embarrassingly long since 4.2.1. Farid (or anyone
> else), do you have anything that you'd like included in it?
>
> Martin

Hi.

Solaris 10 10/2008 SPARC has introduced a binary incompatible change
in the POSIX and Solaris threads implementation:

http://docs.sun.com/app/docs/doc/820-5245/chapter2-1000?a=view

<QUOTE>

Objects of type mutex_t and pthread_mutex_t must start at 8-byte
aligned addresses. Applications that do not satisfy this requirement
fail. The following error message is displayed:

*** _THREAD_ERROR_DETECTION: lock usage error detected ***
...
"mutex is misaligned"
OR:
"condvar is misaligned"

</QUOTE>

In reality, the run-time performance is much worse than the errata
above claims: misaligned mutexes or conditional variables cause the
program to spuriously SEGV in sometimes hard to reproduce ways [
Heisenbug ].

You can view full details of this bug/change here:

http://bugs.opensolaris.org/view_bug.do?bug_id=6729759

To make a long story short, Solaris Kernel Update 137111-01 introduced
an ABI incompatible implementation restriction, requiring that mutexes
and conditional variables must be 8-byte aligned. This restriction has
never been documented, nor has it ever been enforced, until Solaris 10
10/2008 [ Solaris Kernel Update 137111-01 ].

The consequence of this KU is that, the multi-threaded 32-bit SPARC
version of the Apache Standard C++ Library [ 4.2.1 ] will no longer
work, and will fail at run-time with seemingly unexplainable crashes [
the exact same build will work on Solaris versions prior to Kernel
Update 137111-01 ].

This problem is not specific to the Apache Standard C++ Library: it
will occur with any 32-bit SPARCV8 binaries which do not align mutexes
or conditional variables on an 8 byte boundary.

I have created a set of patches for the Apache Standard C++ Library,
Version 4.2.1, for this problem:

http://s247136804.onlinehome.us/stdcxx-upstream/4.2.1/

You can download the tarball with all the patches from the same URL:

http://s247136804.onlinehome.us/stdcxx-upstream/4.2.1/stdcxx-upstream-patches.tar.bz2

These patches force an 8-byte alignment for all objects which contain
a mutex or a conditional variable, and that only for SPARC. With these
patches, all the tests perform as expected.

The patch 22.locale.numpunct.cpp.43.diff is not related to the SPARCV8
ABI change -- it is simply an avoidance of a SEGV in case the variable
first_non_c == NULL [ Solaris sprintf(3C) SEGV's on NULL char*
arguments ].

--Stefan

--
Stefan Teleman
stefan.teleman@...

4.2.2 release

2009-08-14T12:18:13Z

I think we should think about cutting a 4.2.2 release sometime this
month. It's been embarrassingly long since 4.2.1. Farid (or anyone
else), do you have anything that you'd like included in it?

Martin

backward/forward binary compatibility checker

2009-07-31T11:09:47Z

Colleagues, I'm software engineer from Institute for System
Programing of Russian Academy of Sciences and we are developing a free
lightweight tool for checking backward/forward binary compatibility of
shared C/C++ libraries in OS Linux. It checks interface signatures and
data type definitions in two library versions (headers and shared
objects) and searches differences that may lead to incompatibility
according to ABI standards. We have released 1.0.0 version of this tool
and we'd like you to consider its usefulness for your project.
The wiki-page with the latest release of binary compatibility checker is
http://ispras.linux-foundation.org/index.php/ABI_compliance_checker

Andrey Ponomarenko <susanin@...>

Re: (Roguewave) Nightly testing changes

2009-06-17T16:03:58Z

Martin Sebor wrote:
[snip]

>
> Like this?
>
> --- genxviews (revision 785832)
> +++ genxviews (working copy)
> @@ -590,14 +590,18 @@
>
> # Windows ##############################################################
>
> -process_results "Windows 2008" "EM64T" "MSVC 9.0" \
> - "win_2008-0-em64t-msvc-9.0-*-*-log.gz.txt" \
> - win_2008_0-em64t-msvc-9.0.html
> +process_results "Windows 2008" "X64" "MSVC 9.0" \
> + "windows-2008-msvc-9.0-*-*-log.gz.txt" \
> + windows-2008-msvc-9.0.html
>
> -process_results "Windows 2008" "EM64T" "Intel C++ 11.0" \
> - "win_2008-0-em64t-icl-11.0-*-*-log.gz.txt" \
> - win_2008_0-em64t-icl-11.0.html
> +process_results "Windows 2008" "X64" "MSVC 8.0" \
> + "windows-2008-msvc-8.0-*-*-log.gz.txt" \
> + windows-2008-msvc-8.0.html
>
> +process_results "Windows 2008" "X64" "Intel C++ 11.0" \
> + "windows-2008-icl-11.0-*-*-log.gz.txt" \
> + windows-2008-icl-11.0.html
> +
> process_results "Windows Vista" "EM64T" "MSVC 9.0" \
> "win_vista-0-em64t-msvc-9.0-*-*-log.gz.txt" \
> win_vista_0-em64t-msvc-9.0.html
>

That looks correct. As I said, I've added the required translation to
fetch_records.pl (one of the scripts run on the RogueWave side of
things), so we may be able to get by with just adding

process_results "Windows 2008" "X64" "MSVC 8.0" \
"win_2008-0-em64t-msvc-8.0-*-*-log.gz.txt" \
win_2008-0-em64t-msvc-8.0.html

to the list of things to process. Given a day or two of bad index pages
won't throw things too much, I'd add the msvc line now, and alter
genxviews to use the roguewave name later if it's needed.

--Andrew Black

Re: (Roguewave) Nightly testing changes

2009-06-17T15:48:37Z

Andrew Black wrote:

> I think I've got a couple corrections on that list.
>
> One is that you may need to use the os name windows-2008 rather than
> win_2008_0-em64t. I've updated fetch_records.pl in perforce, but I'm
> not certain if the changes automatically propagate or not when the fetch
> is performed. If the changes aren't automatically propagated, we'll
> likely need to figure out how to transition the push updates to my user
> account.
>
> The second correction is that the testing coverage on windows-2008
> includes MSVC 8.0.

Like this?

--- genxviews (revision 785832)
+++ genxviews (working copy)
@@ -590,14 +590,18 @@

# Windows ##############################################################

-process_results "Windows 2008" "EM64T" "MSVC 9.0" \
- "win_2008-0-em64t-msvc-9.0-*-*-log.gz.txt" \
- win_2008_0-em64t-msvc-9.0.html
+process_results "Windows 2008" "X64" "MSVC 9.0" \
+ "windows-2008-msvc-9.0-*-*-log.gz.txt" \
+ windows-2008-msvc-9.0.html

-process_results "Windows 2008" "EM64T" "Intel C++ 11.0" \
- "win_2008-0-em64t-icl-11.0-*-*-log.gz.txt" \
- win_2008_0-em64t-icl-11.0.html
+process_results "Windows 2008" "X64" "MSVC 8.0" \
+ "windows-2008-msvc-8.0-*-*-log.gz.txt" \
+ windows-2008-msvc-8.0.html

+process_results "Windows 2008" "X64" "Intel C++ 11.0" \
+ "windows-2008-icl-11.0-*-*-log.gz.txt" \
+ windows-2008-icl-11.0.html
+
process_results "Windows Vista" "EM64T" "MSVC 9.0" \
"win_vista-0-em64t-msvc-9.0-*-*-log.gz.txt" \
win_vista_0-em64t-msvc-9.0.html

>
> --Andrew Black
>
> Martin Sebor wrote:
>> Thanks for the heads up! I updated the genxviews script to reflect
>> your changes on the result pages (see the commit below). Hopefully
>> I got the system abbrevs right. I don't think the Solaris changes
>> need any updates to the script.
>>
>> http://svn.apache.org/viewvc?view=rev&revision=785832
>>
>> Martin
>>
>> Andrew Black wrote:
>>> Greetings all.
>>>
>>> The schedule used for the nightly testing of stdcxx builds on the build
>>> servers at RogueWave has gotten a little out of date, so I ended up
>>> taking some time today to bring it into alignment with the current state
>>> of the build servers. This resulted in the following changes being
>>> made. Note that I'm using the host name vocabulary used internally by
>>> RogueWave for these notes, rather than those names on the
>>> http://stdcxx.apache.org/builds/ pages.
>>>
>>> * windows-2003: Remove all requests (hosts repurposed for windows-2008)
>>> * Windows_2000: Remove all requests (host died).
>>> * windows_xp: remove requests for icl-9.1, icl-10.0, msvc-7.1, add
>>> requests for 32-bit icl-11.0.
>>> * windows-xp-em64t: Remove requests for icl-10.0, add requests for
>>> 64-bit icl-11.0.
>>> * windows-vista-em64t: remove requests for icl-10.0, replace with
>>> requrests for icl-11.0.
>>> * windows-2008: Add testing of same requests as windows-vista-em64t on
>>> mason, pane, porthole, and shatter.
>>> * redhat_as-4.0-amd64: Remove, folding into redhat_as-4.0-em64t
>>> * redhat_as-5.0-em64t: Remove compiler/binutils runenvs, requrests for
>>> icc-9.1 and icc-10.0, add requests for icc-11.0
>>> * solaris-9: Update sunpro 5.9 patch level to 5.9j10
>>> * solaris-10-amd64: Ditto.
>>> * solaris-10: Ditto, update sunpro 5.8 patch level to 5.8j17
>>>
>>> One other piece of information of note is that operating system upgrades
>>> have been performed on all solaris, redhat and windows platforms. I
>>> don't have exact patch versions handy, but the script used to push the
>>> results out to apache has not been updated with the new versions.
>>>
>>> --Andrew Black

Re: (Roguewave) Nightly testing changes

2009-06-17T15:39:46Z

I think I've got a couple corrections on that list.

One is that you may need to use the os name windows-2008 rather than
win_2008_0-em64t. I've updated fetch_records.pl in perforce, but I'm
not certain if the changes automatically propagate or not when the fetch
is performed. If the changes aren't automatically propagated, we'll
likely need to figure out how to transition the push updates to my user
account.

The second correction is that the testing coverage on windows-2008
includes MSVC 8.0.

--Andrew Black

Martin Sebor wrote:

> Thanks for the heads up! I updated the genxviews script to reflect
> your changes on the result pages (see the commit below). Hopefully
> I got the system abbrevs right. I don't think the Solaris changes
> need any updates to the script.
>
> http://svn.apache.org/viewvc?view=rev&revision=785832
>
> Martin
>
> Andrew Black wrote:
>> Greetings all.
>>
>> The schedule used for the nightly testing of stdcxx builds on the build
>> servers at RogueWave has gotten a little out of date, so I ended up
>> taking some time today to bring it into alignment with the current state
>> of the build servers. This resulted in the following changes being
>> made. Note that I'm using the host name vocabulary used internally by
>> RogueWave for these notes, rather than those names on the
>> http://stdcxx.apache.org/builds/ pages.
>>
>> * windows-2003: Remove all requests (hosts repurposed for windows-2008)
>> * Windows_2000: Remove all requests (host died).
>> * windows_xp: remove requests for icl-9.1, icl-10.0, msvc-7.1, add
>> requests for 32-bit icl-11.0.
>> * windows-xp-em64t: Remove requests for icl-10.0, add requests for
>> 64-bit icl-11.0.
>> * windows-vista-em64t: remove requests for icl-10.0, replace with
>> requrests for icl-11.0.
>> * windows-2008: Add testing of same requests as windows-vista-em64t on
>> mason, pane, porthole, and shatter.
>> * redhat_as-4.0-amd64: Remove, folding into redhat_as-4.0-em64t
>> * redhat_as-5.0-em64t: Remove compiler/binutils runenvs, requrests for
>> icc-9.1 and icc-10.0, add requests for icc-11.0
>> * solaris-9: Update sunpro 5.9 patch level to 5.9j10
>> * solaris-10-amd64: Ditto.
>> * solaris-10: Ditto, update sunpro 5.8 patch level to 5.8j17
>>
>> One other piece of information of note is that operating system upgrades
>> have been performed on all solaris, redhat and windows platforms. I
>> don't have exact patch versions handy, but the script used to push the
>> results out to apache has not been updated with the new versions.
>>
>> --Andrew Black
>

Re: (Roguewave) Nightly testing changes

2009-06-17T15:10:37Z

Thanks for the heads up! I updated the genxviews script to reflect
your changes on the result pages (see the commit below). Hopefully
I got the system abbrevs right. I don't think the Solaris changes
need any updates to the script.

http://svn.apache.org/viewvc?view=rev&revision=785832

Martin

Andrew Black wrote:

> Greetings all.
>
> The schedule used for the nightly testing of stdcxx builds on the build
> servers at RogueWave has gotten a little out of date, so I ended up
> taking some time today to bring it into alignment with the current state
> of the build servers. This resulted in the following changes being
> made. Note that I'm using the host name vocabulary used internally by
> RogueWave for these notes, rather than those names on the
> http://stdcxx.apache.org/builds/ pages.
>
> * windows-2003: Remove all requests (hosts repurposed for windows-2008)
> * Windows_2000: Remove all requests (host died).
> * windows_xp: remove requests for icl-9.1, icl-10.0, msvc-7.1, add
> requests for 32-bit icl-11.0.
> * windows-xp-em64t: Remove requests for icl-10.0, add requests for
> 64-bit icl-11.0.
> * windows-vista-em64t: remove requests for icl-10.0, replace with
> requrests for icl-11.0.
> * windows-2008: Add testing of same requests as windows-vista-em64t on
> mason, pane, porthole, and shatter.
> * redhat_as-4.0-amd64: Remove, folding into redhat_as-4.0-em64t
> * redhat_as-5.0-em64t: Remove compiler/binutils runenvs, requrests for
> icc-9.1 and icc-10.0, add requests for icc-11.0
> * solaris-9: Update sunpro 5.9 patch level to 5.9j10
> * solaris-10-amd64: Ditto.
> * solaris-10: Ditto, update sunpro 5.8 patch level to 5.8j17
>
> One other piece of information of note is that operating system upgrades
> have been performed on all solaris, redhat and windows platforms. I
> don't have exact patch versions handy, but the script used to push the
> results out to apache has not been updated with the new versions.
>
> --Andrew Black

(Roguewave) Nightly testing changes

2009-06-17T12:24:48Z

Greetings all.

The schedule used for the nightly testing of stdcxx builds on the build
servers at RogueWave has gotten a little out of date, so I ended up
taking some time today to bring it into alignment with the current state
of the build servers. This resulted in the following changes being
made. Note that I'm using the host name vocabulary used internally by
RogueWave for these notes, rather than those names on the
http://stdcxx.apache.org/builds/ pages.

* windows-2003: Remove all requests (hosts repurposed for windows-2008)
* Windows_2000: Remove all requests (host died).
* windows_xp: remove requests for icl-9.1, icl-10.0, msvc-7.1, add
requests for 32-bit icl-11.0.
* windows-xp-em64t: Remove requests for icl-10.0, add requests for
64-bit icl-11.0.
* windows-vista-em64t: remove requests for icl-10.0, replace with
requrests for icl-11.0.
* windows-2008: Add testing of same requests as windows-vista-em64t on
mason, pane, porthole, and shatter.
* redhat_as-4.0-amd64: Remove, folding into redhat_as-4.0-em64t
* redhat_as-5.0-em64t: Remove compiler/binutils runenvs, requrests for
icc-9.1 and icc-10.0, add requests for icc-11.0
* solaris-9: Update sunpro 5.9 patch level to 5.9j10
* solaris-10-amd64: Ditto.
* solaris-10: Ditto, update sunpro 5.8 patch level to 5.8j17

One other piece of information of note is that operating system upgrades
have been performed on all solaris, redhat and windows platforms. I
don't have exact patch versions handy, but the script used to push the
results out to apache has not been updated with the new versions.

--Andrew Black

Re: Buildbot - Useful for nightly testing?

2009-06-07T16:42:17Z

Gavin wrote:
> Hi All,

Hi Gavin!

>
> I noticed from the last board report that you are looking for a
> replacement(s) for nightly testing.
>
> We have a Buildbot instance at http://ci.apache.org/buildbot.html &&
> http://ci.apache.org/waterfall .
>
> I have seen some of your test results at stdcxx.apache.org/builds/ and these
> look comprehensive. Whilst Buildbot may not be as thorough with producing
> results I hope that it can help in some way with your build testing.
>
> Currently Buildbot is only available on Ubuntu. There are plans to expand
> the build farm and so Buildbot will be available on other platforms over the
> next few months.
>
> Some questions if I can.
>
> 1. Interested?

Definitely!

>
> 2. Id like to test Stdcxx on Buildbot on our Ubuntu machine, can someone run
> through what simple tests we can run for now? - I'll about getting it on
> there over the next few days.

I'll be interested in looking at the results. I'll need some time
to better understand the current presentation format.

>
> 3. I would like a summary of what you would need to replicate either your
> current build/test setup, or what you believe would be good to have at
> Apache for your needs - consider that no machine is likely to be dedicated
> to one project, but rather shared in a way to benefit all. Mention any
> features of post-build outcomes you have or desire also.

The stdcxx builds pages present the build and test results across
the set of tested configurations of the project on each platform
(a unique combination of compiler, operating system, and hardware
architecture).

For example, the page below consists of 5 tables showing the build
and test results of 16 configurations of stdcxx with gcc 4.1.1 on
Solaris 10/SPARC:

http://stdcxx.apache.org/builds/4.2.x/solaris-10-sparc-gcc-4.1.1.html

The first table, Logs and Columns (http://tinyurl.com/mvwufq#logs),
gives summary info about each build (the OS, hardware architecture,
compiler, the "build type" -- see the last table on the page, titled
Build Types), how old the build result is (WRT the date the page was
created), the svn revision the result corresponds to, the sizes of
various artifacts of the build process, and the number of diagnostics
issued during each stage of the build process.

The second table, Timings (http://tinyurl.com/mvwufq#timings) gives
timings of the stages of the build process.

The next three tables, titled "Results of %d %s from %d logs" show
the results of compiling, linking, and running each of stdcxx tests
(those are divided into tests of locales, unit tests, and example
programs supplied with the project). Every row in each of these
tables represents a single test. Every column corresponds to each
of the builds (configurations) of the project. The cell format,
including the color scheme, is documented in a table titled Codes
and Colors toward the bottom of the page (see
http://tinyurl.com/mvwufq#codes). Only rows with "interesting"
results (i.e., those indicating a problem of some kind) are shown.

The pages are generated from plain text logs created by the build
and test script distributed with stdcxx:
http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/bin/buildntest

The script responsible for generating the pages is xbuildgen:
http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/bin/xbuildgen

Martin

>
> Whilst I couldn't guarantee anything, I would like to take this to
> infrastructure and use it in consideration when planning our purchasing
> requirements for the build farm expansion.
>
> Thanks
>
> Gav...
>

Buildbot - Useful for nightly testing?

2009-06-06T22:20:38Z

Hi All,

I noticed from the last board report that you are looking for a
replacement(s) for nightly testing.

We have a Buildbot instance at http://ci.apache.org/buildbot.html &&
http://ci.apache.org/waterfall .

I have seen some of your test results at stdcxx.apache.org/builds/ and these
look comprehensive. Whilst Buildbot may not be as thorough with producing
results I hope that it can help in some way with your build testing.

Currently Buildbot is only available on Ubuntu. There are plans to expand
the build farm and so Buildbot will be available on other platforms over the
next few months.

Some questions if I can.

1. Interested?

2. Id like to test Stdcxx on Buildbot on our Ubuntu machine, can someone run
through what simple tests we can run for now? - I'll about getting it on
there over the next few days.

3. I would like a summary of what you would need to replicate either your
current build/test setup, or what you believe would be good to have at
Apache for your needs - consider that no machine is likely to be dedicated
to one project, but rather shared in a way to benefit all. Mention any
features of post-build outcomes you have or desire also.

Whilst I couldn't guarantee anything, I would like to take this to
infrastructure and use it in consideration when planning our purchasing
requirements for the build farm expansion.

Thanks

Gav...

Re: svn commit: r777603 - in /stdcxx/branches/4.2.x: etc/config/src/ src/

2009-05-25T09:26:19Z

Farid Zaripov wrote:

>> Why do we need this and the other tests?
>
> I've got the MSVC 10.0 beta recently and I prepairing the stdcxx
> for this compiler.
>
>> I'm pretty sure you know this but just for completeness:
>>
> [...]
>> If there is a compiler that we need _RWSTD_NO_DOMAIN_ERROR_DTOR for,
>> won't we also need a macro for every single one of the rest of C++
>> Standard Library polymorphic classes such as std::ios_base?
>
> Actually, the MSVC 10.0 beta libc contains dtor's for std::length_error
> and std::logic_error only (at least in 15s configuration which I've tested).
> It is still beta for now, but I believe that these dtors will go to the
> release.
>
> Or should I fill the bug report to Microsoft on that issue?

That would be great, thanks! With dtors for arbitrary C++ Standard
Library in their libc there's no way to build/use a third party
implementation such as stdcxx. Imagine one of the dtors doing
something to the class, e.g.:

class length_error: runtime_error { // MSVC 10 definition
char* data;
public:
virtual ~length_error () { delete[] data; }
// ...
}

Martin

>
> Best Regards,
> Farid Zaripov
>

Re: svn commit: r777603 - in /stdcxx/branches/4.2.x: etc/config/src/ src/

2009-05-25T05:15:05Z

> Why do we need this and the other tests?

I've got the MSVC 10.0 beta recently and I prepairing the stdcxx
for this compiler.

> I'm pretty sure you know this but just for completeness:
>
[...]
>
> If there is a compiler that we need _RWSTD_NO_DOMAIN_ERROR_DTOR for,
> won't we also need a macro for every single one of the rest of C++
> Standard Library polymorphic classes such as std::ios_base?

Actually, the MSVC 10.0 beta libc contains dtor's for std::length_error
and std::logic_error only (at least in 15s configuration which I've tested).
It is still beta for now, but I believe that these dtors will go to the
release.

Or should I fill the bug report to Microsoft on that issue?

Best Regards,
Farid Zaripov

Re: svn commit: r777603 - in /stdcxx/branches/4.2.x: etc/config/src/ src/

2009-05-22T15:24:32Z

faridz@... wrote:
> Author: faridz
> Date: Fri May 22 16:30:22 2009
> New Revision: 777603
>
> URL: http://svn.apache.org/viewvc?rev=777603&view=rev
> Log:
> 2009-05-22 Farid Zaripov <faridz@...>
>
> * etc/config/src/DOMAIN_ERROR_DTOR.cpp: New configuration test checking for domain_error dtor

Why do we need this and the other tests?

I'm pretty sure you know this but just for completeness:

Unlike their base class, std::exception, which is normally defined
in the language support library (i.e., the C++ runtime), such as
libsupc++ with gcc, std::domain_error and the rest of the classes
below as well as most other C++ Standard Library classes (most
notoriously iostreams and locales) are defined in the C++ Standard
Library, such as libstdc++ with gcc. Programs that link with stdcxx
must only link with the language runtime and must avoid linking with
the rest of the C++ Standard Library that comes with the compiler
(for gcc, this is done by using the gcc command to link rather than
g++).

If there is a compiler that we need _RWSTD_NO_DOMAIN_ERROR_DTOR for,
won't we also need a macro for every single one of the rest of C++
Standard Library polymorphic classes such as std::ios_base?

> * etc/config/src/INVALID_ARGUMENT_DTOR.cpp: Same for invalid_argument.
> * etc/config/src/LENGTH_ERROR_DTOR.cpp: Same for length_error.
> * etc/config/src/LOGIC_ERROR_DTOR.cpp: Same for logic_error.
> * etc/config/src/OUT_OF_RANGE_DTOR.cpp: Same for out_of_range.
> * etc/config/src/OVERFLOW_ERROR_DTOR.cpp: Same for overflow_error.
> * etc/config/src/RANGE_ERROR_DTOR.cpp: Same for range_error.
> * etc/config/src/RUNTIME_ERROR_DTOR.cpp: Same for runtime_error.
> * etc/config/src/UNDERFLOW_ERROR_DTOR.cpp: Same for underflow_error.
> * src/domain_error.cpp: Define dtor if it is not defined in libc only.

Are you sure you meant libc above? No libc that I know of defines
C++ classes.

What platform is this for?

Martin

> * src/invalid_argument.cpp: Ditto.
> * src/length_error.cpp: Ditto.
> * src/logic_error.cpp: Ditto.
> * src/out_of_range.cpp: Ditto.
> * src/overflow_error.cpp: Ditto.
> * src/range_error.cpp: Ditto.
> * src/runtime_error.cpp: Ditto.
> * src/underflow_error.cpp: Ditto.
>
> Added:
> stdcxx/branches/4.2.x/etc/config/src/DOMAIN_ERROR_DTOR.cpp (with props)
> stdcxx/branches/4.2.x/etc/config/src/INVALID_ARGUMENT_DTOR.cpp (with props)
> stdcxx/branches/4.2.x/etc/config/src/LENGTH_ERROR_DTOR.cpp (with props)
> stdcxx/branches/4.2.x/etc/config/src/LOGIC_ERROR_DTOR.cpp (with props)
> stdcxx/branches/4.2.x/etc/config/src/OUT_OF_RANGE_DTOR.cpp (with props)
> stdcxx/branches/4.2.x/etc/config/src/OVERFLOW_ERROR_DTOR.cpp (with props)
> stdcxx/branches/4.2.x/etc/config/src/RANGE_ERROR_DTOR.cpp (with props)
> stdcxx/branches/4.2.x/etc/config/src/RUNTIME_ERROR_DTOR.cpp (with props)
> stdcxx/branches/4.2.x/etc/config/src/UNDERFLOW_ERROR_DTOR.cpp (with props)
> Modified:
> stdcxx/branches/4.2.x/src/domain_error.cpp
> stdcxx/branches/4.2.x/src/invalid_argument.cpp
> stdcxx/branches/4.2.x/src/length_error.cpp
> stdcxx/branches/4.2.x/src/logic_error.cpp
> stdcxx/branches/4.2.x/src/out_of_range.cpp
> stdcxx/branches/4.2.x/src/overflow_error.cpp
> stdcxx/branches/4.2.x/src/range_error.cpp
> stdcxx/branches/4.2.x/src/runtime_error.cpp
> stdcxx/branches/4.2.x/src/underflow_error.cpp
>
> Added: stdcxx/branches/4.2.x/etc/config/src/DOMAIN_ERROR_DTOR.cpp
> URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/etc/config/src/DOMAIN_ERROR_DTOR.cpp?rev=777603&view=auto
> ==============================================================================
> --- stdcxx/branches/4.2.x/etc/config/src/DOMAIN_ERROR_DTOR.cpp (added)
> +++ stdcxx/branches/4.2.x/etc/config/src/DOMAIN_ERROR_DTOR.cpp Fri May 22 16:30:22 2009
> @@ -0,0 +1,40 @@
> +// checking for domain_error dtor
> +
> +/***************************************************************************
> + *
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements. See the NOTICE file distributed
> + * with this work for additional information regarding copyright
> + * ownership. The ASF licenses this file to you under the Apache
> + * License, Version 2.0 (the License); you may not use this file
> + * except in compliance with the License. You may obtain a copy of
> + * the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> + * implied. See the License for the specific language governing
> + * permissions and limitations under the License.
> + *
> + * Copyright 1999-2007 Rogue Wave Software, Inc.
> + *
> + **************************************************************************/
> +
> +#if 0 // guard invalid preprocessor symbol below
> + // establish a dependency on RUNTIME_IN_STD.cpp
> +# ifndef _RWSTD_NO_RUNTIME_IN_STD
> +# endif // _RWSTD_NO_RUNTIME_IN_STD
> +#endif // 0
> +
> +#define TEST_DTOR
> +#define bad_alloc domain_error
> +#define main test_domain_error_dtor
> +#include "BAD_ALLOC_ASSIGNMENT.cpp"
> +#undef main
> +
> +int main (int argc, char *argv[])
> +{
> + return test_domain_error_dtor (argc, argv);
> +}
>
> Propchange: stdcxx/branches/4.2.x/etc/config/src/DOMAIN_ERROR_DTOR.cpp
> ------------------------------------------------------------------------------
> svn:eol-style = native
>
> Propchange: stdcxx/branches/4.2.x/etc/config/src/DOMAIN_ERROR_DTOR.cpp
> ------------------------------------------------------------------------------
> svn:keywords = Id
>
> Added: stdcxx/branches/4.2.x/etc/config/src/INVALID_ARGUMENT_DTOR.cpp
> URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/etc/config/src/INVALID_ARGUMENT_DTOR.cpp?rev=777603&view=auto
> ==============================================================================
> --- stdcxx/branches/4.2.x/etc/config/src/INVALID_ARGUMENT_DTOR.cpp (added)
> +++ stdcxx/branches/4.2.x/etc/config/src/INVALID_ARGUMENT_DTOR.cpp Fri May 22 16:30:22 2009
> @@ -0,0 +1,40 @@
> +// checking for invalid_argument dtor
> +
> +/***************************************************************************
> + *
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements. See the NOTICE file distributed
> + * with this work for additional information regarding copyright
> + * ownership. The ASF licenses this file to you under the Apache
> + * License, Version 2.0 (the License); you may not use this file
> + * except in compliance with the License. You may obtain a copy of
> + * the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> + * implied. See the License for the specific language governing
> + * permissions and limitations under the License.
> + *
> + * Copyright 1999-2007 Rogue Wave Software, Inc.
> + *
> + **************************************************************************/
> +
> +#if 0 // guard invalid preprocessor symbol below
> + // establish a dependency on RUNTIME_IN_STD.cpp
> +# ifndef _RWSTD_NO_RUNTIME_IN_STD
> +# endif // _RWSTD_NO_RUNTIME_IN_STD
> +#endif // 0
> +
> +#define TEST_DTOR
> +#define bad_alloc invalid_argument
> +#define main test_invalid_argument_dtor
> +#include "BAD_ALLOC_ASSIGNMENT.cpp"
> +#undef main
> +
> +int main (int argc, char *argv[])
> +{
> + return test_invalid_argument_dtor (argc, argv);
> +}
>
> Propchange: stdcxx/branches/4.2.x/etc/config/src/INVALID_ARGUMENT_DTOR.cpp
> ------------------------------------------------------------------------------
> svn:eol-style = native
>
> Propchange: stdcxx/branches/4.2.x/etc/config/src/INVALID_ARGUMENT_DTOR.cpp
> ------------------------------------------------------------------------------
> svn:keywords = Id
>
> Added: stdcxx/branches/4.2.x/etc/config/src/LENGTH_ERROR_DTOR.cpp
> URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/etc/config/src/LENGTH_ERROR_DTOR.cpp?rev=777603&view=auto
> ==============================================================================
> --- stdcxx/branches/4.2.x/etc/config/src/LENGTH_ERROR_DTOR.cpp (added)
> +++ stdcxx/branches/4.2.x/etc/config/src/LENGTH_ERROR_DTOR.cpp Fri May 22 16:30:22 2009
> @@ -0,0 +1,40 @@
> +// checking for length_error dtor
> +
> +/***************************************************************************
> + *
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements. See the NOTICE file distributed
> + * with this work for additional information regarding copyright
> + * ownership. The ASF licenses this file to you under the Apache
> + * License, Version 2.0 (the License); you may not use this file
> + * except in compliance with the License. You may obtain a copy of
> + * the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> + * implied. See the License for the specific language governing
> + * permissions and limitations under the License.
> + *
> + * Copyright 1999-2007 Rogue Wave Software, Inc.
> + *
> + **************************************************************************/
> +
> +#if 0 // guard invalid preprocessor symbol below
> + // establish a dependency on RUNTIME_IN_STD.cpp
> +# ifndef _RWSTD_NO_RUNTIME_IN_STD
> +# endif // _RWSTD_NO_RUNTIME_IN_STD
> +#endif // 0
> +
> +#define TEST_DTOR
> +#define bad_alloc length_error
> +#define main test_length_error_dtor
> +#include "BAD_ALLOC_ASSIGNMENT.cpp"
> +#undef main
> +
> +int main (int argc, char *argv[])
> +{
> + return test_length_error_dtor (argc, argv);
> +}
>
> Propchange: stdcxx/branches/4.2.x/etc/config/src/LENGTH_ERROR_DTOR.cpp
> ------------------------------------------------------------------------------
> svn:eol-style = native
>
> Propchange: stdcxx/branches/4.2.x/etc/config/src/LENGTH_ERROR_DTOR.cpp
> ------------------------------------------------------------------------------
> svn:keywords = Id
>
> Added: stdcxx/branches/4.2.x/etc/config/src/LOGIC_ERROR_DTOR.cpp
> URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/etc/config/src/LOGIC_ERROR_DTOR.cpp?rev=777603&view=auto
> ==============================================================================
> --- stdcxx/branches/4.2.x/etc/config/src/LOGIC_ERROR_DTOR.cpp (added)
> +++ stdcxx/branches/4.2.x/etc/config/src/LOGIC_ERROR_DTOR.cpp Fri May 22 16:30:22 2009
> @@ -0,0 +1,40 @@
> +// checking for logic_error dtor
> +
> +/***************************************************************************
> + *
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements. See the NOTICE file distributed
> + * with this work for additional information regarding copyright
> + * ownership. The ASF licenses this file to you under the Apache
> + * License, Version 2.0 (the License); you may not use this file
> + * except in compliance with the License. You may obtain a copy of
> + * the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> + * implied. See the License for the specific language governing
> + * permissions and limitations under the License.
> + *
> + * Copyright 1999-2007 Rogue Wave Software, Inc.
> + *
> + **************************************************************************/
> +
> +#if 0 // guard invalid preprocessor symbol below
> + // establish a dependency on RUNTIME_IN_STD.cpp
> +# ifndef _RWSTD_NO_RUNTIME_IN_STD
> +# endif // _RWSTD_NO_RUNTIME_IN_STD
> +#endif // 0
> +
> +#define TEST_DTOR
> +#define bad_alloc logic_error
> +#define main test_logic_error_dtor
> +#include "BAD_ALLOC_ASSIGNMENT.cpp"
> +#undef main
> +
> +int main (int argc, char *argv[])
> +{
> + return test_logic_error_dtor (argc, argv);
> +}
>
> Propchange: stdcxx/branches/4.2.x/etc/config/src/LOGIC_ERROR_DTOR.cpp
> ------------------------------------------------------------------------------
> svn:eol-style = native
>
> Propchange: stdcxx/branches/4.2.x/etc/config/src/LOGIC_ERROR_DTOR.cpp
> ------------------------------------------------------------------------------
> svn:keywords = Id
>
> Added: stdcxx/branches/4.2.x/etc/config/src/OUT_OF_RANGE_DTOR.cpp
> URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/etc/config/src/OUT_OF_RANGE_DTOR.cpp?rev=777603&view=auto
> ==============================================================================
> --- stdcxx/branches/4.2.x/etc/config/src/OUT_OF_RANGE_DTOR.cpp (added)
> +++ stdcxx/branches/4.2.x/etc/config/src/OUT_OF_RANGE_DTOR.cpp Fri May 22 16:30:22 2009
> @@ -0,0 +1,40 @@
> +// checking for out_of_range dtor
> +
> +/***************************************************************************
> + *
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements. See the NOTICE file distributed
> + * with this work for additional information regarding copyright
> + * ownership. The ASF licenses this file to you under the Apache
> + * License, Version 2.0 (the License); you may not use this file
> + * except in compliance with the License. You may obtain a copy of
> + * the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> + * implied. See the License for the specific language governing
> + * permissions and limitations under the License.
> + *
> + * Copyright 1999-2007 Rogue Wave Software, Inc.
> + *
> + **************************************************************************/
> +
> +#if 0 // guard invalid preprocessor symbol below
> + // establish a dependency on RUNTIME_IN_STD.cpp
> +# ifndef _RWSTD_NO_RUNTIME_IN_STD
> +# endif // _RWSTD_NO_RUNTIME_IN_STD
> +#endif // 0
> +
> +#define TEST_DTOR
> +#define bad_alloc out_of_range
> +#define main test_out_of_range_dtor
> +#include "BAD_ALLOC_ASSIGNMENT.cpp"
> +#undef main
> +
> +int main (int argc, char *argv[])
> +{
> + return test_out_of_range_dtor (argc, argv);
> +}
>
> Propchange: stdcxx/branches/4.2.x/etc/config/src/OUT_OF_RANGE_DTOR.cpp
> ------------------------------------------------------------------------------
> svn:eol-style = native
>
> Propchange: stdcxx/branches/4.2.x/etc/config/src/OUT_OF_RANGE_DTOR.cpp
> ------------------------------------------------------------------------------
> svn:keywords = Id
>
> Added: stdcxx/branches/4.2.x/etc/config/src/OVERFLOW_ERROR_DTOR.cpp
> URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/etc/config/src/OVERFLOW_ERROR_DTOR.cpp?rev=777603&view=auto
> ==============================================================================
> --- stdcxx/branches/4.2.x/etc/config/src/OVERFLOW_ERROR_DTOR.cpp (added)
> +++ stdcxx/branches/4.2.x/etc/config/src/OVERFLOW_ERROR_DTOR.cpp Fri May 22 16:30:22 2009
> @@ -0,0 +1,40 @@
> +// checking for overflow_error dtor
> +
> +/***************************************************************************
> + *
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements. See the NOTICE file distributed
> + * with this work for additional information regarding copyright
> + * ownership. The ASF licenses this file to you under the Apache
> + * License, Version 2.0 (the License); you may not use this file
> + * except in compliance with the License. You may obtain a copy of
> + * the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> + * implied. See the License for the specific language governing
> + * permissions and limitations under the License.
> + *
> + * Copyright 1999-2007 Rogue Wave Software, Inc.
> + *
> + **************************************************************************/
> +
> +#if 0 // guard invalid preprocessor symbol below
> + // establish a dependency on RUNTIME_IN_STD.cpp
> +# ifndef _RWSTD_NO_RUNTIME_IN_STD
> +# endif // _RWSTD_NO_RUNTIME_IN_STD
> +#endif // 0
> +
> +#define TEST_DTOR
> +#define bad_alloc overflow_error
> +#define main test_overflow_error_dtor
> +#include "BAD_ALLOC_ASSIGNMENT.cpp"
> +#undef main
> +
> +int main (int argc, char *argv[])
> +{
> + return test_overflow_error_dtor (argc, argv);
> +}
>
> Propchange: stdcxx/branches/4.2.x/etc/config/src/OVERFLOW_ERROR_DTOR.cpp
> ------------------------------------------------------------------------------
> svn:eol-style = native
>
> Propchange: stdcxx/branches/4.2.x/etc/config/src/OVERFLOW_ERROR_DTOR.cpp
> ------------------------------------------------------------------------------
> svn:keywords = Id
>
> Added: stdcxx/branches/4.2.x/etc/config/src/RANGE_ERROR_DTOR.cpp
> URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/etc/config/src/RANGE_ERROR_DTOR.cpp?rev=777603&view=auto
> ==============================================================================
> --- stdcxx/branches/4.2.x/etc/config/src/RANGE_ERROR_DTOR.cpp (added)
> +++ stdcxx/branches/4.2.x/etc/config/src/RANGE_ERROR_DTOR.cpp Fri May 22 16:30:22 2009
> @@ -0,0 +1,40 @@
> +// checking for range_error dtor
> +
> +/***************************************************************************
> + *
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements. See the NOTICE file distributed
> + * with this work for additional information regarding copyright
> + * ownership. The ASF licenses this file to you under the Apache
> + * License, Version 2.0 (the License); you may not use this file
> + * except in compliance with the License. You may obtain a copy of
> + * the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> + * implied. See the License for the specific language governing
> + * permissions and limitations under the License.
> + *
> + * Copyright 1999-2007 Rogue Wave Software, Inc.
> + *
> + **************************************************************************/
> +
> +#if 0 // guard invalid preprocessor symbol below
> + // establish a dependency on RUNTIME_IN_STD.cpp
> +# ifndef _RWSTD_NO_RUNTIME_IN_STD
> +# endif // _RWSTD_NO_RUNTIME_IN_STD
> +#endif // 0
> +
> +#define TEST_DTOR
> +#define bad_alloc range_error
> +#define main test_range_error_dtor
> +#include "BAD_ALLOC_ASSIGNMENT.cpp"
> +#undef main
> +
> +int main (int argc, char *argv[])
> +{
> + return test_range_error_dtor (argc, argv);
> +}
>
> Propchange: stdcxx/branches/4.2.x/etc/config/src/RANGE_ERROR_DTOR.cpp
> ------------------------------------------------------------------------------
> svn:eol-style = native
>
> Propchange: stdcxx/branches/4.2.x/etc/config/src/RANGE_ERROR_DTOR.cpp
> ------------------------------------------------------------------------------
> svn:keywords = Id
>
> Added: stdcxx/branches/4.2.x/etc/config/src/RUNTIME_ERROR_DTOR.cpp
> URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/etc/config/src/RUNTIME_ERROR_DTOR.cpp?rev=777603&view=auto
> ==============================================================================
> --- stdcxx/branches/4.2.x/etc/config/src/RUNTIME_ERROR_DTOR.cpp (added)
> +++ stdcxx/branches/4.2.x/etc/config/src/RUNTIME_ERROR_DTOR.cpp Fri May 22 16:30:22 2009
> @@ -0,0 +1,40 @@
> +// checking for runtime_error dtor
> +
> +/***************************************************************************
> + *
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements. See the NOTICE file distributed
> + * with this work for additional information regarding copyright
> + * ownership. The ASF licenses this file to you under the Apache
> + * License, Version 2.0 (the License); you may not use this file
> + * except in compliance with the License. You may obtain a copy of
> + * the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> + * implied. See the License for the specific language governing
> + * permissions and limitations under the License.
> + *
> + * Copyright 1999-2007 Rogue Wave Software, Inc.
> + *
> + **************************************************************************/
> +
> +#if 0 // guard invalid preprocessor symbol below
> + // establish a dependency on RUNTIME_IN_STD.cpp
> +# ifndef _RWSTD_NO_RUNTIME_IN_STD
> +# endif // _RWSTD_NO_RUNTIME_IN_STD
> +#endif // 0
> +
> +#define TEST_DTOR
> +#define bad_alloc runtime_error
> +#define main test_runtime_error_dtor
> +#include "BAD_ALLOC_ASSIGNMENT.cpp"
> +#undef main
> +
> +int main (int argc, char *argv[])
> +{
> + return test_runtime_error_dtor (argc, argv);
> +}
>
> Propchange: stdcxx/branches/4.2.x/etc/config/src/RUNTIME_ERROR_DTOR.cpp
> ------------------------------------------------------------------------------
> svn:eol-style = native
>
> Propchange: stdcxx/branches/4.2.x/etc/config/src/RUNTIME_ERROR_DTOR.cpp
> ------------------------------------------------------------------------------
> svn:keywords = Id
>
> Added: stdcxx/branches/4.2.x/etc/config/src/UNDERFLOW_ERROR_DTOR.cpp
> URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/etc/config/src/UNDERFLOW_ERROR_DTOR.cpp?rev=777603&view=auto
> ==============================================================================
> --- stdcxx/branches/4.2.x/etc/config/src/UNDERFLOW_ERROR_DTOR.cpp (added)
> +++ stdcxx/branches/4.2.x/etc/config/src/UNDERFLOW_ERROR_DTOR.cpp Fri May 22 16:30:22 2009
> @@ -0,0 +1,40 @@
> +// checking for underflow_error dtor
> +
> +/***************************************************************************
> + *
> + * Licensed to the Apache Software Foundation (ASF) under one or more
> + * contributor license agreements. See the NOTICE file distributed
> + * with this work for additional information regarding copyright
> + * ownership. The ASF licenses this file to you under the Apache
> + * License, Version 2.0 (the License); you may not use this file
> + * except in compliance with the License. You may obtain a copy of
> + * the License at
> + *
> + * http://www.apache.org/licenses/LICENSE-2.0
> + *
> + * Unless required by applicable law or agreed to in writing, software
> + * distributed under the License is distributed on an "AS IS" BASIS,
> + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
> + * implied. See the License for the specific language governing
> + * permissions and limitations under the License.
> + *
> + * Copyright 1999-2007 Rogue Wave Software, Inc.
> + *
> + **************************************************************************/
> +
> +#if 0 // guard invalid preprocessor symbol below
> + // establish a dependency on RUNTIME_IN_STD.cpp
> +# ifndef _RWSTD_NO_RUNTIME_IN_STD
> +# endif // _RWSTD_NO_RUNTIME_IN_STD
> +#endif // 0
> +
> +#define TEST_DTOR
> +#define bad_alloc underflow_error
> +#define main test_underflow_error_dtor
> +#include "BAD_ALLOC_ASSIGNMENT.cpp"
> +#undef main
> +
> +int main (int argc, char *argv[])
> +{
> + return test_underflow_error_dtor (argc, argv);
> +}
>
> Propchange: stdcxx/branches/4.2.x/etc/config/src/UNDERFLOW_ERROR_DTOR.cpp
> ------------------------------------------------------------------------------
> svn:eol-style = native
>
> Propchange: stdcxx/branches/4.2.x/etc/config/src/UNDERFLOW_ERROR_DTOR.cpp
> ------------------------------------------------------------------------------
> svn:keywords = Id
>
> Modified: stdcxx/branches/4.2.x/src/domain_error.cpp
> URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/src/domain_error.cpp?rev=777603&r1=777602&r2=777603&view=diff
> ==============================================================================
> --- stdcxx/branches/4.2.x/src/domain_error.cpp (original)
> +++ stdcxx/branches/4.2.x/src/domain_error.cpp Fri May 22 16:30:22 2009
> @@ -32,6 +32,8 @@
>
> _RWSTD_NAMESPACE (std) {
>
> +#ifdef _RWSTD_NO_DOMAIN_ERROR_DTOR
> +
> // outlined to avoid generating a vtable in each translation unit
> // that uses the class
> /* virtual */ domain_error::
> @@ -40,4 +42,6 @@
> // no-op
> }
>
> +#endif // _RWSTD_NO_DOMAIN_ERROR_DTOR
> +
> } // namespace std
>
> Modified: stdcxx/branches/4.2.x/src/invalid_argument.cpp
> URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/src/invalid_argument.cpp?rev=777603&r1=777602&r2=777603&view=diff
> ==============================================================================
> --- stdcxx/branches/4.2.x/src/invalid_argument.cpp (original)
> +++ stdcxx/branches/4.2.x/src/invalid_argument.cpp Fri May 22 16:30:22 2009
> @@ -32,6 +32,8 @@
>
> _RWSTD_NAMESPACE (std) {
>
> +#ifdef _RWSTD_NO_INVALID_ARGUMENT_DTOR
> +
> // outlined to avoid generating a vtable in each translation unit
> // that uses the class
> /* virtual */ invalid_argument::
> @@ -40,4 +42,6 @@
> // no-op
> }
>
> +#endif // _RWSTD_NO_INVALID_ARGUMENT_DTOR
> +
> } // namespace std
>
> Modified: stdcxx/branches/4.2.x/src/length_error.cpp
> URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/src/length_error.cpp?rev=777603&r1=777602&r2=777603&view=diff
> ==============================================================================
> --- stdcxx/branches/4.2.x/src/length_error.cpp (original)
> +++ stdcxx/branches/4.2.x/src/length_error.cpp Fri May 22 16:30:22 2009
> @@ -32,6 +32,8 @@
>
> _RWSTD_NAMESPACE (std) {
>
> +#ifdef _RWSTD_NO_LENGTH_ERROR_DTOR
> +
> // outlined to avoid generating a vtable in each translation unit
> // that uses the class
> /* virtual */ length_error::
> @@ -40,4 +42,6 @@
> // no-op
> }
>
> +#endif // _RWSTD_NO_LENGTH_ERROR_DTOR
> +
> } // namespace std
>
> Modified: stdcxx/branches/4.2.x/src/logic_error.cpp
> URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/src/logic_error.cpp?rev=777603&r1=777602&r2=777603&view=diff
> ==============================================================================
> --- stdcxx/branches/4.2.x/src/logic_error.cpp (original)
> +++ stdcxx/branches/4.2.x/src/logic_error.cpp Fri May 22 16:30:22 2009
> @@ -32,6 +32,8 @@
>
> _RWSTD_NAMESPACE (std) {
>
> +#ifdef _RWSTD_NO_LOGIC_ERROR_DTOR
> +
> // outlined to avoid generating a vtable in each translation unit
> // that uses the class
> /* virtual */ logic_error::
> @@ -40,4 +42,6 @@
> // no-op
> }
>
> +#endif // _RWSTD_NO_LOGIC_ERROR_DTOR
> +
> } // namespace std
>
> Modified: stdcxx/branches/4.2.x/src/out_of_range.cpp
> URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/src/out_of_range.cpp?rev=777603&r1=777602&r2=777603&view=diff
> ==============================================================================
> --- stdcxx/branches/4.2.x/src/out_of_range.cpp (original)
> +++ stdcxx/branches/4.2.x/src/out_of_range.cpp Fri May 22 16:30:22 2009
> @@ -32,6 +32,8 @@
>
> _RWSTD_NAMESPACE (std) {
>
> +#ifdef _RWSTD_NO_OUT_OF_RANGE_DTOR
> +
> // outlined to avoid generating a vtable in each translation unit
> // that uses the class
> /* virtual */ out_of_range::
> @@ -40,4 +42,6 @@
> // no-op
> }
>
> +#endif // _RWSTD_NO_OUT_OF_RANGE_DTOR
> +
> } // namespace std
>
> Modified: stdcxx/branches/4.2.x/src/overflow_error.cpp
> URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/src/overflow_error.cpp?rev=777603&r1=777602&r2=777603&view=diff
> ==============================================================================
> --- stdcxx/branches/4.2.x/src/overflow_error.cpp (original)
> +++ stdcxx/branches/4.2.x/src/overflow_error.cpp Fri May 22 16:30:22 2009
> @@ -32,6 +32,8 @@
>
> _RWSTD_NAMESPACE (std) {
>
> +#ifdef _RWSTD_NO_OVERFLOW_ERROR_DTOR
> +
> // outlined to avoid generating a vtable in each translation unit
> // that uses the class
> /* virtual */ overflow_error::
> @@ -40,4 +42,6 @@
> // no-op
> }
>
> +#endif // _RWSTD_NO_OVERFLOW_ERROR_DTOR
> +
> } // namespace std
>
> Modified: stdcxx/branches/4.2.x/src/range_error.cpp
> URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/src/range_error.cpp?rev=777603&r1=777602&r2=777603&view=diff
> ==============================================================================
> --- stdcxx/branches/4.2.x/src/range_error.cpp (original)
> +++ stdcxx/branches/4.2.x/src/range_error.cpp Fri May 22 16:30:22 2009
> @@ -32,6 +32,8 @@
>
> _RWSTD_NAMESPACE (std) {
>
> +#ifdef _RWSTD_NO_RANGE_ERROR_DTOR
> +
> // outlined to avoid generating a vtable in each translation unit
> // that uses the class
> /* virtual */ range_error::
> @@ -40,4 +42,6 @@
> // no-op
> }
>
> +#endif // _RWSTD_NO_RANGE_ERROR_DTOR
> +
> } // namespace std
>
> Modified: stdcxx/branches/4.2.x/src/runtime_error.cpp
> URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/src/runtime_error.cpp?rev=777603&r1=777602&r2=777603&view=diff
> ==============================================================================
> --- stdcxx/branches/4.2.x/src/runtime_error.cpp (original)
> +++ stdcxx/branches/4.2.x/src/runtime_error.cpp Fri May 22 16:30:22 2009
> @@ -32,6 +32,8 @@
>
> _RWSTD_NAMESPACE (std) {
>
> +#ifdef _RWSTD_NO_RUNTIME_ERROR_DTOR
> +
> // outlined to avoid generating a vtable in each translation unit
> // that uses the class
> /* virtual */ runtime_error::
> @@ -40,4 +42,6 @@
> // no-op
> }
>
> +#endif // _RWSTD_NO_RUNTIME_ERROR_DTOR
> +
> } // namespace std
>
> Modified: stdcxx/branches/4.2.x/src/underflow_error.cpp
> URL: http://svn.apache.org/viewvc/stdcxx/branches/4.2.x/src/underflow_error.cpp?rev=777603&r1=777602&r2=777603&view=diff
> ==============================================================================
> --- stdcxx/branches/4.2.x/src/underflow_error.cpp (original)
> +++ stdcxx/branches/4.2.x/src/underflow_error.cpp Fri May 22 16:30:22 2009
> @@ -32,6 +32,8 @@
>
> _RWSTD_NAMESPACE (std) {
>
> +#ifdef _RWSTD_NO_UNDERFLOW_ERROR_DTOR
> +
> // outlined to avoid generating a vtable in each translation unit
> // that uses the class
> /* virtual */ underflow_error::
> @@ -40,4 +42,6 @@
> // no-op
> }
>
> +#endif // _RWSTD_NO_UNDERFLOW_ERROR_DTOR
> +
> } // namespace std
>
>

Re: tellp()

2009-05-12T17:28:27Z

[CC'ing dev@...]

Steve Clamage wrote:

> I have a bug report where the customer expects to open a file for
> appending, and have tellp() pointing to EOF before doing anything else.
> Sample program:
>
> mytest.cc
> ---------
> #include <iostream>
> #include <fstream>
> using namespace std;
>
> int main(int argc, char** argv)
> {
> if(argc != 2)
> {
> printf("Wrong nums of arguments\n");
> return 1;
> }
> ofstream ofs;
> ofs.open(argv[1], ios::out|ios::app);
> cout << "tellp(): " << ofs.tellp() << '\n';
> }
>
> % ls -l zout
> -rw-rw-r-- 1 clamage staff 347 May 12 07:49 zout
> % CC mystest.cc
> % a.out zout
> tellp():0
>
> The customer expects 347 in this example. Is that a correct expectation?
> libCstd, STLport, and stdcxx all print 0, but g++ prints 347.

I'm not sure the standard is 100% clear on this. Here's why:

tellp() calls rdbuf()->pubseekoff(0, ios::cur, ios::out), which
calls seekoff() with the same arguments.

filebuf::seekoff(0, ios::cur, ios::out) calls fseek(file, 0,
SEEK_CUR).

So far so good. The problem is the Returns clause for seekoff():

Returns: a newly constructed pos_type object that stores the
resultant stream position, if possible. If the positioning
operation fails, or if the object cannot represent the resultant
stream position, returns pos_type(off_type(-1)).

This doesn't say where the resultant position comes from:

* Is it the value obtained by calling ftell(file)? If so,
ftell() returns the position of the end of the file.
* Is the value obtained using some other mechanism, such as
"as if" by calling lseek(fileno(file), 0, SEEK_CUR)? If so,
lseek() returns 0.
* Is the value calculated using some other algorithm? If so,
which one?

I enhanced the program to show the behavior of C stdio and UNIX I/O.
See below. I think we should open an new issue to clarify what the
spec means.

Btw., calling lseek(fileno(file), 0, SEEK_CUR) on the underlying
FILE itself does actually return the same value as tellp(). It's
when filebuf is implemented in terms of POSIX streams as opposed
to stdio that we get this different behavior.

Martin

#include <cstdio>
#include <iostream>
#include <fstream>

#include <fcntl.h>
#include <unistd.h>

using namespace std;

int main(int argc, char** argv)
{
if(argc != 2)
{
printf("Wrong nums of arguments\n");
return 1;
}
ofstream ofs;
ofs.open(argv[1], ios::out|ios::app);
cout << "tellp(): " << ofs.tellp() << '\n';

FILE *fp = fopen (argv [1], "a");
cout << "ftell(): " << (fp ? ftell (fp) : -1) << '\n';

int fd = open (argv [1], O_WRONLY | O_APPEND);
cout << "lseek(): " << lseek (fd, 0, SEEK_CUR) << '\n';
}

The output with stdcxx is:

tellp(): 0
ftell(): 567
lseek(): 0

>
>
> ---
> Steve Clamage, stephen.clamage@...

RE: Problem building Standard Library

2009-05-08T08:54:01Z

An update on this issue: I asked the customer for a preprocessed file so
I can see what headers are being include, etc.

Turns out that on this platform the include/ansi is needed and the
customer was not including it. Therefore when the customer was
including the c headers they were getting them from the wrong location.

Jeremy

-----Original Message-----
From: Farid Zaripov [mailto:faridz@...]
Sent: Thursday, May 07, 2009 8:51 AM
To: dev@...
Subject: RE: Problem building Standard Library

> Turns out they are not getting this error when building the library
> but when they are building their application and using the Standard
Library.
>
> /illustrate/iplus/source/rw_buildspace/include/rw/_iosfwd.h:176:
error:
> '_RWSTD_SEEK_SET' was not declared in this scope
> /illustrate/iplus/source/rw_buildspace/include/rw/_iosfwd.h:177:
error:
> '_RWSTD_SEEK_CUR' was not declared in this scope
> /illustrate/iplus/source/rw_buildspace/include/rw/_iosfwd.h:178:
error:
> '_RWSTD_SEEK_END' was not declared in this scope
> /illustrate/iplus/source/rw_buildspace/include/rw/_iterbase.h:82:
error:
> '_RWSTD_PTRDIFF_T' does not name a type
> /illustrate/iplus/source/rw_buildspace/include/rw/_iterbase.h:93:
error:
> '_RWSTD_PTRDIFF_T' does not name a type
> /illustrate/iplus/source/rw_buildspace/include/rw/_iterbase.h:104:
> error: expected type-specifier before '_RWSTD_PTRDIFF_T'
>
> Any ideas?

It looks like their application has its own config.h file, which is
included instead of our library header file.

Martin, perhaps it worth to put some predefined macro in our config.h
file at configuration step and check that macro in <rw/_config.h> header
right after the <config.h> included. Then if the macro above is not
defined, issue #error with descriptive reason, something like "Not
STDCXX's config.h file is included.
Check that path to the STDCXX's config.h file is first in the list of
include directories."

Farid.

RE: Problem building Standard Library

2009-05-07T07:51:18Z

> Turns out they are not getting this error when building the library but
> when they are building their application and using the Standard Library.
>
> /illustrate/iplus/source/rw_buildspace/include/rw/_iosfwd.h:176: error:
> '_RWSTD_SEEK_SET' was not declared in this scope
> /illustrate/iplus/source/rw_buildspace/include/rw/_iosfwd.h:177: error:
> '_RWSTD_SEEK_CUR' was not declared in this scope
> /illustrate/iplus/source/rw_buildspace/include/rw/_iosfwd.h:178: error:
> '_RWSTD_SEEK_END' was not declared in this scope
> /illustrate/iplus/source/rw_buildspace/include/rw/_iterbase.h:82: error:
> '_RWSTD_PTRDIFF_T' does not name a type
> /illustrate/iplus/source/rw_buildspace/include/rw/_iterbase.h:93: error:
> '_RWSTD_PTRDIFF_T' does not name a type
> /illustrate/iplus/source/rw_buildspace/include/rw/_iterbase.h:104:
> error: expected type-specifier before '_RWSTD_PTRDIFF_T'
>
> Any ideas?

It looks like their application has its own config.h file, which is
included instead of our library header file.

Martin, perhaps it worth to put some predefined macro in our config.h file
at
configuration step and check that macro in <rw/_config.h> header right after
the <config.h> included. Then if the macro above is not defined, issue
#error
with descriptive reason, something like "Not STDCXX's config.h file is
included.
Check that path to the STDCXX's config.h file is first in the list of
include
directories."

Farid.

Re: Problem building Standard Library

2009-05-06T08:00:17Z

Jeremy Dean wrote:

The library wouldn't build w/o these macros defined either. There
must be something wrong with their setup. Again, to be able to tell
what it might be we need to see the full log of the failed build
(i.e., the command line arguments to the compiler and all errors).

Martin

>
> Jeremy
>
> -----Original Message-----
> From: Martin Sebor [mailto:msebor@...]
> Sent: Friday, May 01, 2009 9:13 AM
> To: dev@...
> Subject: Re: Problem building Standard Library
>
> Jeremy Dean wrote:
>>
>>
>> I have a customer on Suse Linux 10update2 that is trying to build
>> apache Standard Library stdcxx-4.2.1.1 (Sourcepro edition 10 update
>> 1). They are getting the error described in
>> http://issues.apache.org/jira/browse/STDCXX-1029
>>
>> I recommended that customer reinstall Suse Linux 10.0 as that what was
>
>> certified. Here are the steps they took, but are still getting the
>> error described:
>>
>> We reinstalled Suse Linux 10.2 without GCC 4.1.2. I then installed GCC
>
>> 4.1.0 from the given website. Afterwards, I reinstalled the latest
>> version of SourcePro and built it.
>> When we tried building our library again, we still get the
>> _RWSTD_SEEK_SET compile error. So we are using everything as
>> recommended, but the issue still exists. Can you help?
>
> STDCXX-1029 turned out to be invalid. It was caused by using an
> installation of gcc configured for another system. As Jakub Jelinek
> explains in his comment on gcc bug 37405
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37405
> gcc must be used on the platform it's configured for. Unless there is a
> good reason to do otherwise, it's usually best to use the default
> version of gcc that comes with the system.
>
> That said, it's also possible that the error is due to some other
> underlying problem. In order to be able to tell, I'd need to see the
> actual error (i.e., the build log for the library as well as the
> contents of $BUILDDIR/include/config.log).
>
> Martin
>
>> Thanks,
>>
>>
>>
>> Jeremy
>>
>> Jeremy Dean
>> Rogue Wave Software, Inc.
>> Technical Support
>> Phone: 303-545-3205 -- 1-800-404-4767
>> E-mail: support@...
>> Web: http://www.roguewave.com/support Knowledge Base entries:
>> http://www.roguewave.com/kbdocs/search.html
>> View issues online at:
>> http://www.roguewave.com/youraccount/login/
>>
>
>

RE: Problem building Standard Library

2009-05-06T06:42:33Z

Turns out they are not getting this error when building the library but
when they are building their application and using the Standard Library.

/illustrate/iplus/source/rw_buildspace/include/rw/_iosfwd.h:176: error:
'_RWSTD_SEEK_SET' was not declared in this scope
/illustrate/iplus/source/rw_buildspace/include/rw/_iosfwd.h:177: error:
'_RWSTD_SEEK_CUR' was not declared in this scope
/illustrate/iplus/source/rw_buildspace/include/rw/_iosfwd.h:178: error:
'_RWSTD_SEEK_END' was not declared in this scope
/illustrate/iplus/source/rw_buildspace/include/rw/_iterbase.h:82: error:
'_RWSTD_PTRDIFF_T' does not name a type
/illustrate/iplus/source/rw_buildspace/include/rw/_iterbase.h:93: error:
'_RWSTD_PTRDIFF_T' does not name a type
/illustrate/iplus/source/rw_buildspace/include/rw/_iterbase.h:104:
error: expected type-specifier before '_RWSTD_PTRDIFF_T'

Any ideas?

Jeremy

-----Original Message-----
From: Martin Sebor [mailto:msebor@...]
Sent: Friday, May 01, 2009 9:13 AM
To: dev@...
Subject: Re: Problem building Standard Library

Jeremy Dean wrote:
>
>
> I have a customer on Suse Linux 10update2 that is trying to build
> apache Standard Library stdcxx-4.2.1.1 (Sourcepro edition 10 update
> 1). They are getting the error described in
> http://issues.apache.org/jira/browse/STDCXX-1029
>
> I recommended that customer reinstall Suse Linux 10.0 as that what was

> certified. Here are the steps they took, but are still getting the
> error described:
>
> We reinstalled Suse Linux 10.2 without GCC 4.1.2. I then installed GCC

> 4.1.0 from the given website. Afterwards, I reinstalled the latest
> version of SourcePro and built it.
> When we tried building our library again, we still get the
> _RWSTD_SEEK_SET compile error. So we are using everything as
> recommended, but the issue still exists. Can you help?

STDCXX-1029 turned out to be invalid. It was caused by using an
installation of gcc configured for another system. As Jakub Jelinek
explains in his comment on gcc bug 37405
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37405
gcc must be used on the platform it's configured for. Unless there is a
good reason to do otherwise, it's usually best to use the default
version of gcc that comes with the system.

That said, it's also possible that the error is due to some other
underlying problem. In order to be able to tell, I'd need to see the
actual error (i.e., the build log for the library as well as the
contents of $BUILDDIR/include/config.log).

Martin

>
> Thanks,
>
>
>
> Jeremy
>
> Jeremy Dean
> Rogue Wave Software, Inc.
> Technical Support
> Phone: 303-545-3205 -- 1-800-404-4767
> E-mail: support@...
> Web: http://www.roguewave.com/support Knowledge Base entries:
> http://www.roguewave.com/kbdocs/search.html
> View issues online at:
> http://www.roguewave.com/youraccount/login/
>

Re: Problem building Standard Library

2009-05-01T08:12:50Z

Jeremy Dean wrote:

>
>
> I have a customer on Suse Linux 10update2 that is trying to build apache
> Standard Library stdcxx-4.2.1.1 (Sourcepro edition 10 update 1). They
> are getting the error described in
> http://issues.apache.org/jira/browse/STDCXX-1029
>
> I recommended that customer reinstall Suse Linux 10.0 as that what was
> certified. Here are the steps they took, but are still getting the
> error described:
>
> We reinstalled Suse Linux 10.2 without GCC 4.1.2. I then installed GCC
> 4.1.0 from the given website. Afterwards, I reinstalled the latest
> version of SourcePro and built it.
> When we tried building our library again, we still get the
> _RWSTD_SEEK_SET compile error. So we are using everything as
> recommended, but the issue still exists. Can you help?

STDCXX-1029 turned out to be invalid. It was caused by using
an installation of gcc configured for another system. As Jakub
Jelinek explains in his comment on gcc bug 37405
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37405
gcc must be used on the platform it's configured for. Unless
there is a good reason to do otherwise, it's usually best to
use the default version of gcc that comes with the system.

That said, it's also possible that the error is due to some
other underlying problem. In order to be able to tell, I'd
need to see the actual error (i.e., the build log for the
library as well as the contents of $BUILDDIR/include/config.log).

Martin

>
> Thanks,
>
>
>
> Jeremy
>
> Jeremy Dean
> Rogue Wave Software, Inc.
> Technical Support
> Phone: 303-545-3205 -- 1-800-404-4767
> E-mail: support@...
> Web: http://www.roguewave.com/support
> Knowledge Base entries:
> http://www.roguewave.com/kbdocs/search.html
> View issues online at:
> http://www.roguewave.com/youraccount/login/
>

Problem building Standard Library

2009-05-01T03:41:40Z

I have a customer on Suse Linux 10update2 that is trying to build apache
Standard Library stdcxx-4.2.1.1 (Sourcepro edition 10 update 1). They
are getting the error described in
http://issues.apache.org/jira/browse/STDCXX-1029

I recommended that customer reinstall Suse Linux 10.0 as that what was
certified. Here are the steps they took, but are still getting the
error described:

We reinstalled Suse Linux 10.2 without GCC 4.1.2. I then installed GCC
4.1.0 from the given website. Afterwards, I reinstalled the latest
version of SourcePro and built it.
When we tried building our library again, we still get the
_RWSTD_SEEK_SET compile error. So we are using everything as
recommended, but the issue still exists. Can you help?

Thanks,

Jeremy

Jeremy Dean
Rogue Wave Software, Inc.
Technical Support
Phone: 303-545-3205 -- 1-800-404-4767
E-mail: support@...
Web: http://www.roguewave.com/support
Knowledge Base entries:
http://www.roguewave.com/kbdocs/search.html
View issues online at:
http://www.roguewave.com/youraccount/login/