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
On Fri, Sep 4, 2009 at 05:48, Farid Zaripov<faridz@apache.org> 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@gmail.com
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
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@gmail.com
> 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.
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 >
> -----Original Message-----l > From: Martin Sebor [mailto:msebor@gmail.com] > Sent: Wednesday, August 26, 2009 1:02 AM > To: dev@stdcxx.apache.org > 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.
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
>
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] -- View this message in context: http://www.nabble.com/Problem-building-Standard-Library-tp23331169p25108978.html Sent from the stdcxx-dev mailing list archive at Nabble.com.
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
>> 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
Stefan Teleman wrote: > On Fri, Aug 14, 2009 at 16:24, Martin Sebor<msebor@gmail.com> 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 >
On Fri, Aug 14, 2009 at 16:24, Martin Sebor<msebor@gmail.com> 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@gmail.com
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@gmail.com> 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 >
On Fri, Aug 14, 2009 at 15:18, Martin Sebor<msebor@gmail.com> 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@gmail.com
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
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@ispras.ru>
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
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
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 >
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
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
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... >
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...
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
>
> 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
faridz@apache.org 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@apache.org>
>
> * 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
>
>
[CC'ing dev@stdcxx.apache.org]
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@sun.com
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@apache.org] Sent: Thursday, May 07, 2009 8:51 AM To: dev@stdcxx.apache.org 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.
> 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.
Jeremy Dean wrote: > 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? 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@gmail.com] > Sent: Friday, May 01, 2009 9:13 AM > To: dev@stdcxx.apache.org > 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@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/ >> > >
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@gmail.com] Sent: Friday, May 01, 2009 9:13 AM To: dev@stdcxx.apache.org 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@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/ >
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@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/ >
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/
Jeremy Dean wrote:
> I have a customer that getting the following error when trying to
> compile his code:
>
> Platform: Solaris 9
> Compiler: SunPro 5.9
> Build: Multithreaded-Debug-shared
>
> Error Message:
> "include/map", line 206: Error: second is not a member of RWCString.
> "GOCC_GuiPref.cc", line 93: Where: While instantiating
> "std::map<RWCString, GOCC_WinPref*, std::less<RWCString>,
> std::allocator<RWCString>>::operator[](const RWCString&)".
This doesn't look like a valid specialization of std::map. The
template is declared like so:
template <class Key, class T,
class Compare = less<Key>,
class Allocator = allocator<pair<const Key, T> > >
class map;
I.e., the type of map from RWCString to GOCC_WinPref* is:
map<RWCString, GOCC_WinPref*,
less<RWCString>,
allocator<pair<const RWCString, GOCC_WinPref*> > >;
Note that allocator is specialized on
pair<const RWCString, GOCC_WinPref*>.
Martin
>
> Code:
> Line 206 of Map looks like this:
> mapped_type& operator[] (const key_type &__k) {
> // note: temporary is necessary to avoid an xlC 5.0 bug (PR
> #25040)
> iterator __i = insert (value_type (__k, mapped_type ())).first;
> return (*__i).second;
> }
>
> Jeremy
>
>
I have a customer that getting the following error when trying to
compile his code:
Platform: Solaris 9
Compiler: SunPro 5.9
Build: Multithreaded-Debug-shared
Error Message:
"include/map", line 206: Error: second is not a member of RWCString.
"GOCC_GuiPref.cc", line 93: Where: While instantiating
"std::map<RWCString, GOCC_WinPref*, std::less<RWCString>,
std::allocator<RWCString>>::operator[](const RWCString&)".
Code:
Line 206 of Map looks like this:
mapped_type& operator[] (const key_type &__k) {
// note: temporary is necessary to avoid an xlC 5.0 bug (PR
#25040)
iterator __i = insert (value_type (__k, mapped_type ())).first;
return (*__i).second;
}
Jeremy
-------- Original Message -------- Subject: [Travel Assistance] Applications for ApacheCon EU 2009 - Now Open Date: Fri, 23 Jan 2009 13:28:19 +0000 From: Tony Stevenson <pctony@apache.org> To: travel-assistance@apache.org The Travel Assistance Committee is now accepting applications for those wanting to attend ApacheCon EU 2009 between the 23rd and 27th March 2009 in Amsterdam. The Travel Assistance Committee is looking for people who would like to be able to attend ApacheCon EU 2009 who need some financial support in order to get there. There are very few places available and the criteria is high, that aside applications are open to all open source developers who feel that their attendance would benefit themselves, their project(s), the ASF or open source in general. Financial assistance is available for travel, accommodation and entrance fees either in full or in part, depending on circumstances. It is intended that all our ApacheCon events are covered, so it may be prudent for those in the United States or Asia to wait until an event closer to them comes up - you are all welcome to apply for ApacheCon EU of course, but there must be compelling reasons for you to attend an event further away that your home location for your application to be considered above those closer to the event location. More information can be found on the main Apache website at http://www.apache.org/travel/index.html - where you will also find a link to the online application form. Time is very tight for this event, so applications are open now and will end on the 4th February 2009 - to give enough time for travel arrangements to be made. Good luck to all those that apply. Regards, The Travel Assistance Committee -- ------------------------------------------------------------------ Tony Stevenson tony@pc-tony.com // pctony@apache.org // pctony@freenode.net http://blog.pc-tony.com/ 1024D/51047D66 ECAF DC55 C608 5E82 0B5E 3359 C9C7 924E 5104 7D66 ------------------------------------------------------------------
An update on the results: they are now current, but all testsuite builds fail with errors in the Rogue Wave test driver file lockfile.cpp (see below). I've just committed a fix for this error so once it's picked up by the nightly test infrastructure we should start seeing some hopefully more useful build results, probably sometime tomorrow. $(TOPDIR)/tests/src/lockfile.cpp: In destructor 'virtual RWQELockFile::~RWQELockFile()': $(TOPDIR)/tests/src/lockfile.cpp:161: error: 'free' was not declared in this scope $(TOPDIR)/tests/src/lockfile.cpp: In member function 'void RWQELockFile::copyName(const char*)': $(TOPDIR)/tests/src/lockfile.cpp:218: error: 'malloc' was not declared in this scope gmake: *** [lockfile.o] Error 1 Martin Sebor wrote: > > > Andrew Black-5 wrote: >> >> Greetings Martin >> >> I took a glance at the logs for the 4.2.x exports, and observe the >> following error message: >> >> /usr/bin/scp: Argument list too long >> >> This particular message is generated when the exporter script attempts >> to copy the generated files out to Apache. The solution as I see it >> will be to manually perform the export, splitting the export list into >> pieces to avoid overloading scp. You'll then need to manually update >> the cache file as is done at the end of static_export.sh. >> >> > > It turns out that cleaning out the $HOME/.stdcxx-cache/4.2.x directory > and re-running the $HOME/bin/pubres.sh script fixed the problem. There > were over 30,000 files in the directory, nearly half of them empty. All > the empty ones were from sometime in September. There still are a bunch > of them in $HOME/.stdcxx-cache/4.3.x although not nearly as many. > > I'm in the process of running $HOME/bin/mkxviews on people.apache.org > now. When it's done and when the Web server picks up the changes the > 4.2.x results should be up to date. Let's keep an eye on the results > page over the next few days to make sure the problem is gone: > > http://stdcxx.apache.org/builds/4.2.x/ > > > >> >> --Andrew Black >> >> Martin Sebor wrote: >>> The page has been updated but it looks like all the builds are stale >>> (33 days old). Let me see if I can find the time to figure out what's >>> going on tomorrow. If not, I'm travelling starting Wednesday so it >>> might need to wait until the 26th. >>> >>> >>> Martin Sebor-2 wrote: >>>> Farid Zaripov wrote: >>>>> The latest nightly builds report for 4.2.x branch generated >>>>> Tue Nov 11 15:00:39 UTC 2008 - over a month ago. >>>> Weird, the others are up to date. >>>> >>>> [...investigating...] >>>> >>>> I think I've got it. Seems that the SSL certificate had expired >>>> and needed to be refreshed in order for svn to proceed with source >>>> code update. >>>> >>>> The page is up to date now (it will take a bit for the web server >>>> to pick it up). >>>> >>>> Martin >>>> >>>>> Farid. >>>>> >>>> >>>> >>> >> >> > > -- View this message in context: http://www.nabble.com/Outdated-nightly-builds-results-on-apache.org-tp20976643p21282005.html Sent from the stdcxx-dev mailing list archive at Nabble.com.
Andrew Black-5 wrote: > > Greetings Martin > > I took a glance at the logs for the 4.2.x exports, and observe the > following error message: > > /usr/bin/scp: Argument list too long > > This particular message is generated when the exporter script attempts > to copy the generated files out to Apache. The solution as I see it > will be to manually perform the export, splitting the export list into > pieces to avoid overloading scp. You'll then need to manually update > the cache file as is done at the end of static_export.sh. > > It turns out that cleaning out the $HOME/.stdcxx-cache/4.2.x directory and re-running the $HOME/bin/pubres.sh script fixed the problem. There were over 30,000 files in the directory, nearly half of them empty. All the empty ones were from sometime in September. There still are a bunch of them in $HOME/.stdcxx-cache/4.3.x although not nearly as many. I'm in the process of running $HOME/bin/mkxviews on people.apache.org now. When it's done and when the Web server picks up the changes the 4.2.x results should be up to date. Let's keep an eye on the results page over the next few days to make sure the problem is gone: http://stdcxx.apache.org/builds/4.2.x/ > > --Andrew Black > > Martin Sebor wrote: >> The page has been updated but it looks like all the builds are stale >> (33 days old). Let me see if I can find the time to figure out what's >> going on tomorrow. If not, I'm travelling starting Wednesday so it >> might need to wait until the 26th. >> >> >> Martin Sebor-2 wrote: >>> Farid Zaripov wrote: >>>> The latest nightly builds report for 4.2.x branch generated >>>> Tue Nov 11 15:00:39 UTC 2008 - over a month ago. >>> Weird, the others are up to date. >>> >>> [...investigating...] >>> >>> I think I've got it. Seems that the SSL certificate had expired >>> and needed to be refreshed in order for svn to proceed with source >>> code update. >>> >>> The page is up to date now (it will take a bit for the web server >>> to pick it up). >>> >>> Martin >>> >>>> Farid. >>>> >>> >>> >> > > -- View this message in context: http://www.nabble.com/Outdated-nightly-builds-results-on-apache.org-tp20976643p21269973.html Sent from the stdcxx-dev mailing list archive at Nabble.com.
Andrew Black wrote: > Greetings Martin > > I took a glance at the logs for the 4.2.x exports, and observe the > following error message: > > /usr/bin/scp: Argument list too long > > This particular message is generated when the exporter script attempts > to copy the generated files out to Apache. The solution as I see it > will be to manually perform the export, splitting the export list into > pieces to avoid overloading scp. You'll then need to manually update > the cache file as is done at the end of static_export.sh. Ah, thanks! I didn't get to this today so it'll have to wait until I get back from my trip on 12/25. In the unlikely event that I forget anyone affected by this should feel to pester me ;-) Sorry for the delays in getting this fixed... Martin > > --Andrew Black > > Martin Sebor wrote: >> The page has been updated but it looks like all the builds are stale >> (33 days old). Let me see if I can find the time to figure out what's >> going on tomorrow. If not, I'm travelling starting Wednesday so it >> might need to wait until the 26th. >> >> >> Martin Sebor-2 wrote: >>> Farid Zaripov wrote: >>>> The latest nightly builds report for 4.2.x branch generated >>>> Tue Nov 11 15:00:39 UTC 2008 - over a month ago. >>> Weird, the others are up to date. >>> >>> [...investigating...] >>> >>> I think I've got it. Seems that the SSL certificate had expired >>> and needed to be refreshed in order for svn to proceed with source >>> code update. >>> >>> The page is up to date now (it will take a bit for the web server >>> to pick it up). >>> >>> Martin >>> >>>> Farid. >>>> >>> >