Re: x.y.z numbering and releases
On Fri, Jan 20, 2006 at 01:39:36AM -0600, William A. Rowe, Jr. wrote: > William A. Rowe, Jr. wrote: > > > >I do believe it does, granted the 1.2.3-rc3 branch would be internally > >labeled (version id) 1.2.3, but the branch it sits on and the tarballs > >it's packaged in both clearly designate 1.2.3. > > they designate 1.2.3-rc3!!! Only the internal directory path within the > tarball and appropriate header files omit the -rc3 desigation, such that... > > >This resolves Justin's > >concern about rerolling the tarball, and addresses your concern that > >like several other Apache packages, you would like to have several > >review cycles. Thought you were missing a key phrase or two. =) -- justin
Re: x.y.z numbering and releases
William A. Rowe, Jr. wrote: I do believe it does, granted the 1.2.3-rc3 branch would be internally labeled (version id) 1.2.3, but the branch it sits on and the tarballs it's packaged in both clearly designate 1.2.3. they designate 1.2.3-rc3!!! Only the internal directory path within the tarball and appropriate header files omit the -rc3 desigation, such that... This resolves Justin's concern about rerolling the tarball, and addresses your concern that like several other Apache packages, you would like to have several review cycles.
Re: x.y.z numbering and releases
Martin Sebor wrote: I have no objection to tagging the 1.2.3 branch 1.2.3-rcN for each tarball that's about to be voted on but I suspect that may not fully address your concerns (i.e., the fact that there is a 1.2.3 branch before an official release has taken place). I do believe it does, granted the 1.2.3-rc3 branch would be internally labeled (version id) 1.2.3, but the branch it sits on and the tarballs it's packaged in both clearly designate 1.2.3. This resolves Justin's concern about rerolling the tarball, and addresses your concern that like several other Apache packages, you would like to have several review cycles. If there is an easy way to rename a branch I suppose we could start with a 1.2.3-not-an-official-release-yet (or whatever) branch and, once the release is approved, rename it to 1.2.3. svn rm? It's a lovely thing :) It would even point the file renamed back at the branch it originated from (documenting that yes, in fact the -rc3 candidate became official.) I wonder what it is about the ASF that makes us different from the other open source projects and that requires us to adopt such an unconventional policy. It's not, this isn't ASF policy, it's the original httpd committer's policy, so don't be surprized by Roy or others chiming in that there is only one right way :) It's been that way in httpd-land forever. But that doesn't mean that projects can't adopt, with appropriate safeguards against confusion, policies that match their own style. Bill
Re: 21.string.cons test
Liviu Nicoara wrote: Attached is my attempt at converting the lib.string.cons test. It contains the additional new_test.h/new.cpp and string_test.h/string_test.cpp for support. Great, thanks! I spotted a few problems (the %lu formatting specifier used where size_t was being passed -- the correct C99 modifier for size_t is %zu). I corrected them and made a few other "improvements" (and also disabled the copy_string() function until we actually build a shared rwtest library) and committed the result here: http://svn.apache.org/viewcvs.cgi?rev=370707&view=rev Martin
Re: x.y.z numbering and releases
Justin Erenkrantz wrote: --On January 19, 2006 4:29:33 PM -0700 Martin Sebor <[EMAIL PROTECTED]> wrote: If there is an easy way to rename a branch I suppose we could start with a 1.2.3-not-an-official-release-yet (or whatever) branch and, once the release is approved, rename it to 1.2.3. svn mv tags/1.2.3-not-an-official-release-yet tags/1.2.3 Nifty -- thanks! :) Again, my take is that a release candidate is not a good idea; instead, I feel you should just burn the number. But, if you insist on a rc process, some ASF projects have done that with varying measure of success. But I feel that this seems like going too far. I have been following several open source projects for years (e.g., gcc, glibc, GNU make, STLport) but this is the first time I've ever even heard of this policy. Do you know of any projects outside the ASF that use it? If not, I wonder what it is about the ASF that makes us different from the other open source projects and that requires us to adopt such an unconventional policy. The critical point of the ASF's release policy is that there are at least three PMC members voting +1 and that there are more positive than negative votes. A RM will create a release individually, but in order to distribute the release and call it Apache XYZ, it needs the approval of the PMC (as denoted by their votes). The specifics of how each project gets to that is up to each PMC. The concern I had with your earlier comments was altering the source, assuming all of the prior votes counted, and not having any identification to know that the source had changed. That's dangerous behavior because it facilitates confusion over what we're all voting on and what users will download. -- justin I see. It was a mistake caused by my inexperience with the ASF release process. I certainly agree and understand that it needs to be avoided and why. I will keep it in mind for the next release (although I hope to do a better job of making sure that the first tarball is good to begin with! :) Thanks again for your helpful comments! Martin
Re: x.y.z numbering and releases
--On January 19, 2006 4:29:33 PM -0700 Martin Sebor <[EMAIL PROTECTED]> wrote: If there is an easy way to rename a branch I suppose we could start with a 1.2.3-not-an-official-release-yet (or whatever) branch and, once the release is approved, rename it to 1.2.3. svn mv tags/1.2.3-not-an-official-release-yet tags/1.2.3 Again, my take is that a release candidate is not a good idea; instead, I feel you should just burn the number. But, if you insist on a rc process, some ASF projects have done that with varying measure of success. But I feel that this seems like going too far. I have been following several open source projects for years (e.g., gcc, glibc, GNU make, STLport) but this is the first time I've ever even heard of this policy. Do you know of any projects outside the ASF that use it? If not, I wonder what it is about the ASF that makes us different from the other open source projects and that requires us to adopt such an unconventional policy. The critical point of the ASF's release policy is that there are at least three PMC members voting +1 and that there are more positive than negative votes. A RM will create a release individually, but in order to distribute the release and call it Apache XYZ, it needs the approval of the PMC (as denoted by their votes). The specifics of how each project gets to that is up to each PMC. The concern I had with your earlier comments was altering the source, assuming all of the prior votes counted, and not having any identification to know that the source had changed. That's dangerous behavior because it facilitates confusion over what we're all voting on and what users will download. -- justin
Re: 21.string.cons test
Liviu Nicoara wrote: Attached is my attempt at converting the lib.string.cons test. It contains the additional new_test.h/new.cpp and string_test.h/string_test.cpp for support. Do you happen to also have the test for the replacement operator new? The current one fails with the changes to new.cpp (because new.cpp uses the driver without initializing it first). Martin
Re: [VOTE] publish stdcxx 4.1.3, take 2
+1 Tested on RH AS 4 Itanium, EM64T, and SUSE (x86) (all with gcc). Martin Sebor wrote: > Justin Erenkrantz wrote: > [...] > >>>Since several of them are involved and would require us to recertify >>>the library on all the platforms where it has passed my goal is to get >>>them fixed in 4.1.4. Does that sound reasonable? >> >> >>Sure. Let's just note that Mac OS X isn't supported in the release notes. > > > Okay, this has been done: > http://svn.apache.org/viewcvs.cgi?rev=368452&view=rev > > I also noticed a symbol versioning issue in gcc optimized builds > on Solaris that causes unsats when linking. Since symbol versioning > is still experimental I disabled it on the 4.1.3 branch: > http://svn.apache.org/viewcvs.cgi?rev=368485&view=rev > > I created a new tarball incorporating these changes and replaced > the old one with it. Here's the link again for convenience: > http://people.apache.org/~sebor/stdcxx/stdcxx-incubating-4.1.3.tar.gz > The md5sum for this file is f1bc9bd5ef0966f994a9183e7353176d. > > Since these were the only changes I only smoke-tested this new tarball > with gcc 3.2.3 on Linux and gcc 4.0.2 Solaris with successul results. > I hereby cast my +1 vote to publish this tarball :) > > I assume everyone else's votes are still good and that we just need > a positive vote from you, Bill, or Ben before we can ask the Incubator > PMC for permission to publish it. > > Here's a tally of votes thus far: > >+1: 4 + 1 (johnh, lnicoara, ajindal, sebor + willson) > 0: none >-1: none > > Thanks > Martin >
Re: x.y.z numbering and releases
William A. Rowe, Jr. wrote: Martin Sebor wrote: [...] However, I believe that the issue can be just as effectively dealt with by implementing the -rcN (or similar) suffix policy that Bill mentioned in his first post, with the additional (and IMO essential) advantage of preserving the well-established meaning of the version number grounded in precisely defined technical criteria. I agree with Martin -if- the SVN tag is also designated tags/1.2.3-rcN until it's voted in, and then copied or renamed to tags/1.2.3 upon release. I have no objection to tagging the 1.2.3 branch 1.2.3-rcN for each tarball that's about to be voted on but I suspect that may not fully address your concerns (i.e., the fact that there is a 1.2.3 branch before an official release has taken place). If there is an easy way to rename a branch I suppose we could start with a 1.2.3-not-an-official-release-yet (or whatever) branch and, once the release is approved, rename it to 1.2.3. But I feel that this seems like going too far. I have been following several open source projects for years (e.g., gcc, glibc, GNU make, STLport) but this is the first time I've ever even heard of this policy. Do you know of any projects outside the ASF that use it? If not, I wonder what it is about the ASF that makes us different from the other open source projects and that requires us to adopt such an unconventional policy. Martin
[jira] Commented: (STDCXX-124) [gcc 3.4.4/FreeBSD 6.0] compilation errors due to misconfiguration
[ http://issues.apache.org/jira/browse/STDCXX-124?page=comments#action_12363324 ] Martin Sebor commented on STDCXX-124: - Looks like the SIZE_T.cpp test (among others) fails to link due to some missing symbols: gcc -c -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align -D_RWSTDDEBUG -pthread -D_RWSTD_USE_CONFIG -I. /tmp/sebor/trunk/etc/config/src/SIZE_T.cpp /tmp/sebor/trunk/etc/config/src/SIZE_T.cpp: In function `void get_type_names(int, ...)': /tmp/sebor/trunk/etc/config/src/SIZE_T.cpp:152: warning: unsigned int format, different type arg (arg 2) /tmp/sebor/trunk/etc/config/src/SIZE_T.cpp: At global scope: /tmp/sebor/trunk/etc/config/src/SIZE_T.cpp:47: warning: unused parameter 'dummy' gcc SIZE_T.o -pthread -lm -lsupc++ -o SIZE_T /usr/lib/libsupc++.a(eh_throw.o)(.text.__cxa_throw+0x18): In function `__cxa_throw':: undefined reference to `__cxxabiv1::__unexpected_handler' /usr/lib/libsupc++.a(eh_throw.o)(.text.__cxa_throw+0x2c): In function `__cxa_throw':: undefined reference to `__cxxabiv1::__terminate_handler' /usr/lib/libsupc++.a(eh_terminate.o)(.text._ZSt9terminatev+0x10): In function `std::terminate()':: undefined reference to `__cxxabiv1::__terminate_handler' /usr/lib/libsupc++.a(eh_terminate.o)(.text._ZSt10unexpectedv+0x10): In function `std::unexpected()':: undefined reference to `__cxxabiv1::__unexpected_handler' /usr/lib/libsupc++.a(eh_terminate.o)(.text._ZSt13set_terminatePFvvE+0x8): In function `std::set_terminate(void (*)())':: undefined reference to `__cxxabiv1::__terminate_handler' /usr/lib/libsupc++.a(eh_terminate.o)(.text._ZSt14set_unexpectedPFvvE+0x8): In function `std::set_unexpected(void (*)())':: undefined reference to `__cxxabiv1::__unexpected_handler' > [gcc 3.4.4/FreeBSD 6.0] compilation errors due to misconfiguration > -- > > Key: STDCXX-124 > URL: http://issues.apache.org/jira/browse/STDCXX-124 > Project: STDCXX > Type: Bug > Components: Configuration > Versions: 4.1.3 > Environment: gcc 3.4.4, FreeBSD 6.0 > Reporter: Martin Sebor > Priority: Critical > Fix For: 4.1.2 > > $ nice gmake BUILDTYPE=15s BUILDDIR=/tmp/sebor/gcc-3.4.4-15s > GNUmakefile:283: "CONFIG not specified, using gcc.config" > creating BUILDDIR=/tmp/sebor/gcc-3.4.4-15s > generating /tmp/sebor/gcc-3.4.4-15s/makefile.in from > /tmp/sebor/trunk/etc/config/gcc.config > gmake[1]: Entering directory `/tmp/sebor/gcc-3.4.4-15s' > gmake[2]: Entering directory `/tmp/sebor/gcc-3.4.4-15s/include' > gmake config > gmake[3]: Entering directory `/tmp/sebor/gcc-3.4.4-15s/include' > configuring for gcc-3.4.4 on freebsd-6.0-release-alpha > checking if compiler is sane ok > checking if linker is sane ok > checking if run environment is saneok > checking system architecture LP64 little endian > ... > gmake[2]: Entering directory `/tmp/sebor/gcc-3.4.4-15s/lib' > gcc -c -I/tmp/sebor/trunk/include/ansi -D_RWSTDDEBUG -pthread > -D_RWSTD_USE_CONFIG -I/tmp/sebor/gcc-3.4.4-15s/include > -I/tmp/sebor/trunk/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual > -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align > /tmp/sebor/trunk/src/assert.cpp > gcc -c -I/tmp/sebor/trunk/include/ansi -D_RWSTDDEBUG -pthread > -D_RWSTD_USE_CONFIG -I/tmp/sebor/gcc-3.4.4-15s/include > -I/tmp/sebor/trunk/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual > -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align > /tmp/sebor/trunk/src/atomic-cxx.S > gcc -c -I/tmp/sebor/trunk/include/ansi -D_RWSTDDEBUG -pthread > -D_RWSTD_USE_CONFIG -I/tmp/sebor/gcc-3.4.4-15s/include > -I/tmp/sebor/trunk/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual > -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align > /tmp/sebor/trunk/src/bitset.cpp > In file included from /tmp/sebor/trunk/include/string:32, > from /tmp/sebor/trunk/include/bitset:27, > from /tmp/sebor/trunk/src/bitset.cpp:24: > /tmp/sebor/trunk/include/rw/_iosfwd.h:168: error: `_RWSTD_SEEK_SET' was not > declared in this scope > /tmp/sebor/trunk/include/rw/_iosfwd.h:168: error: enumerator value for > `__rw_beg' not integer constant > [... many other errors...] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (STDCXX-124) [gcc 3.4.4/FreeBSD 6.0] compilation errors due to misconfiguration
[gcc 3.4.4/FreeBSD 6.0] compilation errors due to misconfiguration -- Key: STDCXX-124 URL: http://issues.apache.org/jira/browse/STDCXX-124 Project: STDCXX Type: Bug Components: Configuration Versions: 4.1.3 Environment: gcc 3.4.4, FreeBSD 6.0 Reporter: Martin Sebor Priority: Critical Fix For: 4.1.2 $ nice gmake BUILDTYPE=15s BUILDDIR=/tmp/sebor/gcc-3.4.4-15s GNUmakefile:283: "CONFIG not specified, using gcc.config" creating BUILDDIR=/tmp/sebor/gcc-3.4.4-15s generating /tmp/sebor/gcc-3.4.4-15s/makefile.in from /tmp/sebor/trunk/etc/config/gcc.config gmake[1]: Entering directory `/tmp/sebor/gcc-3.4.4-15s' gmake[2]: Entering directory `/tmp/sebor/gcc-3.4.4-15s/include' gmake config gmake[3]: Entering directory `/tmp/sebor/gcc-3.4.4-15s/include' configuring for gcc-3.4.4 on freebsd-6.0-release-alpha checking if compiler is sane ok checking if linker is sane ok checking if run environment is saneok checking system architecture LP64 little endian ... gmake[2]: Entering directory `/tmp/sebor/gcc-3.4.4-15s/lib' gcc -c -I/tmp/sebor/trunk/include/ansi -D_RWSTDDEBUG -pthread -D_RWSTD_USE_CONFIG -I/tmp/sebor/gcc-3.4.4-15s/include -I/tmp/sebor/trunk/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align /tmp/sebor/trunk/src/assert.cpp gcc -c -I/tmp/sebor/trunk/include/ansi -D_RWSTDDEBUG -pthread -D_RWSTD_USE_CONFIG -I/tmp/sebor/gcc-3.4.4-15s/include -I/tmp/sebor/trunk/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align /tmp/sebor/trunk/src/atomic-cxx.S gcc -c -I/tmp/sebor/trunk/include/ansi -D_RWSTDDEBUG -pthread -D_RWSTD_USE_CONFIG -I/tmp/sebor/gcc-3.4.4-15s/include -I/tmp/sebor/trunk/include -pedantic -nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align /tmp/sebor/trunk/src/bitset.cpp In file included from /tmp/sebor/trunk/include/string:32, from /tmp/sebor/trunk/include/bitset:27, from /tmp/sebor/trunk/src/bitset.cpp:24: /tmp/sebor/trunk/include/rw/_iosfwd.h:168: error: `_RWSTD_SEEK_SET' was not declared in this scope /tmp/sebor/trunk/include/rw/_iosfwd.h:168: error: enumerator value for `__rw_beg' not integer constant [... many other errors...] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
23.containers.deque.modifiers.cpp
I have attached my tentative porting of lib.deque.modifiers test to the
new driver. Martin, I would appreciate suggestions for improving the
sections which use ToString class (one of those uses split formatting).
Thanks,
Liviu
/***
*
* 23.containers.deque.modifiers.cpp - test exercising [lib.deque.modifiers]
*
* $Id$
*
***
*
* Copyright (c) 1994-2005 Quovadx, Inc., acting through its Rogue Wave
* Software division. Licensed under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance with the
* License.Youmay obtain a copy ofthe Licenseat
* http://www.apache.org/licenses/LICENSE-2.0.Unless requiredby
* 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.
*
**/
#ifdef _MSC_VER
// silence warning C4244: 'argument' : conversion from 'T' to
// 'const std::allocator<_TypeT>::value_type', possible loss of data
// issued for deque::assign(InputIterator a, InputIterator b) and
// deque::insert(iterator, InputIterator a, InputIterator b) due
// the implicit conversion of a to size_type and b to value_type
// required by DR 438:
// http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#438
# pragma warning (disable: 4244)
#endif
#include // for sprintf()
#include// for strlen()
#include
#ifndef _RWSTD_NO_REPLACEABLE_NEW_DELETE
// disabled for MSVC since it can't reliably replace the operators
# define DEFINE_REPLACEMENT_NEW_AND_DELETE
#endif // _RWSTD_NO_REPLACEABLE_NEW_DELETE
#include
#include
#include
#include
/**/
// for convenience
typedef unsigned char UChar;
/**/
typedef std::deque > Deque;
std::size_t new_capacity;
namespace __rw {
_RWSTD_SPECIALIZED_FUNCTION
inline Deque::size_type
__rw_new_capacity(Deque::size_type n, const Deque*)
{
if (n) {
// non-zero size argument indicates a request for an increase
// in the capacity of a deque object's dynamically sizable
// vector of nodes
return n * 2;
}
// zero size argument is a request for the initial size of a deque
// object's dynamically sizable vector of nodes or for the size of
// the objects's fixed-size buffer for elements
return new_capacity;
}
}
/**/
enum {
NewThrows = 0x1 /* cause operator new to throw */,
CopyCtorThrows = 0x2 /* cause element's copy ctor to throw */,
AssignmentThrows = 0x4 /* cause element's assignment to throw */
};
enum MemberFunction {
Assign_n/* deque::assign (size_type, const_reference) */,
AssignRange /* deque::assign (InputIterator, InputIterator) */,
Erase_1 /* deque::erase (iterator) */,
EraseRange /* deque::erase (iterator, iterator) */,
Insert_1/* deque::insert (iterator, const_reference) */,
Insert_n/* deque::insert (iterator, size_type, const_reference) */,
InsertRange /* deque::insert (iterator, InputIterator, InputIterator) */
};
// causes operator new, deque element's copy ctor, or assignment operator
// to throw an exception and iterates as long as the member function exits
// by throwing an exception; verifies that the exception had no effects
// on the container
template
void exception_loop (int line /* line number in caller*/,
MemberFunction mfun /* deque member function */,
const char *fcall /* function call string */,
int exceptions /* enabled exceptions */,
Deque &deq /* container to call function on */,
const Deque::iterator &it /* iterator into container */,
int n /* number of elements or offset */,
const X*x /* pointer to an element or 0 */,
const Iterator &first /* beginning of range */,
const Iterator &last /* end of range to insert */,
int*n_copy /* number of copy ctors */,
int*n_asgn /* number of assignments */)
{
std::size_t throw_after = 0;
// get the initial size of the container and its begin() iterator
// to detect illegal changes after an exception (i.e., violations
// if the strong exception guarantee)
[jira] Closed: (STDCXX-123) EDG eccp 3.7] misconfiguration due to ill-formed C++ code in libc_decl.sh
[ http://issues.apache.org/jira/browse/STDCXX-123?page=all ] Martin Sebor closed STDCXX-123: --- Resolution: Fixed Fixed by the referenced change. > EDG eccp 3.7] misconfiguration due to ill-formed C++ code in libc_decl.sh > - > > Key: STDCXX-123 > URL: http://issues.apache.org/jira/browse/STDCXX-123 > Project: STDCXX > Type: Bug > Components: Configuration > Versions: 4.1.3 > Environment: EDG eccp 3.7 > Reporter: Martin Sebor > Assignee: Martin Sebor > Priority: Critical > Fix For: 4.1.4 > > EDG eccp 3.7 (released in January '06) started to issue a new error (see > below). The error is causing all config tests for the presence of libc > function declarations in libc headers to fail. > eccp -c -DCHECK_DECL -A -x --template_directory=/build/sebor/eccp-3.7-15s/lib > -g --display_error_number --remarks --diag_suppress > 193,236,340,401,261,479,487,678,679,815 -DHDRNAME= > -DFUNNAME=acos -DFUN=acos(0.0) -DTAKE_ADDR=0 > /tmp/libc_decl_tmpsrc-27371.cpp -o /tmp/acos-27371.o && eccp > /tmp/libc_decl_tmpsrc-27371.cpp > --template_directory=/build/sebor/eccp-3.7-15s/lib /usr/lib/libpthread.so > -lm > "/tmp/libc_decl_tmpsrc-27371.cpp", line 13: error #961-D: use of a type with > no linkage to declare a variable with linkage > } funptri; > ^ > 1 error detected in the compilation of "/tmp/libc_decl_tmpsrc-27371.cpp". > Note that gcc detects the same violation but only issues a warning: > non-local variable ' u' uses anonymous type -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
21.string.cons test
Attached is my attempt at converting the lib.string.cons test. It contains the additional new_test.h/new.cpp and string_test.h/string_test.cpp for support. Liviu 21.string.cons.tgz Description: application/compressed-tar
[jira] Assigned: (STDCXX-123) EDG eccp 3.7] misconfiguration due to ill-formed C++ code in libc_decl.sh
[ http://issues.apache.org/jira/browse/STDCXX-123?page=all ] Martin Sebor reassigned STDCXX-123: --- Assign To: Martin Sebor > EDG eccp 3.7] misconfiguration due to ill-formed C++ code in libc_decl.sh > - > > Key: STDCXX-123 > URL: http://issues.apache.org/jira/browse/STDCXX-123 > Project: STDCXX > Type: Bug > Components: Configuration > Versions: 4.1.3 > Environment: EDG eccp 3.7 > Reporter: Martin Sebor > Assignee: Martin Sebor > Priority: Critical > Fix For: 4.1.4 > > EDG eccp 3.7 (released in January '06) started to issue a new error (see > below). The error is causing all config tests for the presence of libc > function declarations in libc headers to fail. > eccp -c -DCHECK_DECL -A -x --template_directory=/build/sebor/eccp-3.7-15s/lib > -g --display_error_number --remarks --diag_suppress > 193,236,340,401,261,479,487,678,679,815 -DHDRNAME= > -DFUNNAME=acos -DFUN=acos(0.0) -DTAKE_ADDR=0 > /tmp/libc_decl_tmpsrc-27371.cpp -o /tmp/acos-27371.o && eccp > /tmp/libc_decl_tmpsrc-27371.cpp > --template_directory=/build/sebor/eccp-3.7-15s/lib /usr/lib/libpthread.so > -lm > "/tmp/libc_decl_tmpsrc-27371.cpp", line 13: error #961-D: use of a type with > no linkage to declare a variable with linkage > } funptri; > ^ > 1 error detected in the compilation of "/tmp/libc_decl_tmpsrc-27371.cpp". > Note that gcc detects the same violation but only issues a warning: > non-local variable ' u' uses anonymous type -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (STDCXX-123) EDG eccp 3.7] misconfiguration due to ill-formed C++ code in libc_decl.sh
EDG eccp 3.7] misconfiguration due to ill-formed C++ code in libc_decl.sh - Key: STDCXX-123 URL: http://issues.apache.org/jira/browse/STDCXX-123 Project: STDCXX Type: Bug Components: Configuration Versions: 4.1.3 Environment: EDG eccp 3.7 Reporter: Martin Sebor Priority: Critical Fix For: 4.1.4 EDG eccp 3.7 (released in January '06) started to issue a new error (see below). The error is causing all config tests for the presence of libc function declarations in libc headers to fail. eccp -c -DCHECK_DECL -A -x --template_directory=/build/sebor/eccp-3.7-15s/lib -g --display_error_number --remarks --diag_suppress 193,236,340,401,261,479,487,678,679,815 -DHDRNAME= -DFUNNAME=acos -DFUN=acos(0.0) -DTAKE_ADDR=0 /tmp/libc_decl_tmpsrc-27371.cpp -o /tmp/acos-27371.o && eccp /tmp/libc_decl_tmpsrc-27371.cpp --template_directory=/build/sebor/eccp-3.7-15s/lib /usr/lib/libpthread.so -lm "/tmp/libc_decl_tmpsrc-27371.cpp", line 13: error #961-D: use of a type with no linkage to declare a variable with linkage } funptri; ^ 1 error detected in the compilation of "/tmp/libc_decl_tmpsrc-27371.cpp". Note that gcc detects the same violation but only issues a warning: non-local variable ' u' uses anonymous type -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
