RE: type_traits and other things

[Eric Lemings]

FYI,

As of last night, TR1 just passed unanimously.  I believe it
is to be officially incorporated into the standard next.

Eric.

> -Original Message-
> From: Herb Sutter [mailto:[EMAIL PROTECTED] 
> Sent: Monday, October 10, 2005 5:58 PM
> Subject: TR1 passed unanimously...
> 
> 
> FYI, DTR 19768, also known as our lovable Library Extensions
> TR #1, just passed its JTC1 ballot unanimously. Matt will be
> making up a final PDF for publication.
> 
> Thanks, LWG and Matt for all your work in getting this baby
> out the door!
> 
> Herb

RE: stdcxx question

[Eric Lemings]

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 30, 2005 6:03 PM
> To: John Benito; stdcxx-user@incubator.apache.org; 
> stdcxx-dev@incubator.apache.org
> Subject: Re: stdcxx question
> 
> 
> John Benito wrote:
> > Martin,
> > 
> > Thanks for the quick and correct response.  By specifying the full 
> > path
> > for BUILDDIR, I get a lot farther in the process.  I am now 
> hitting a 
> > makefile
> > issue in that mapfile.gcc-4 and no rule to make the target, 
> and in fact 
> > I do
> > not seem to have a mapfile.gcc-4.  Do I need to download a 
> mapfile.gcc-4?
> 
> No, I'm afraid there isn't one. The project wasn't fully 
> ported to gcc 4 at the time of the snapshot, and this bit 
> still isn't implemented today (you should be able to build 
> and use an archive library with gcc without needing this 
> file). You should also be able to avoid this error when 
> building a shared library by deleting the line that defines 
> the MAPFILE make variable from the generated 
> $BUILDDIR/makefile.in file.

...or do what I did and just link gcc-4 to gcc-3.  It seems to
build and work just fine.

Eric.

RE: question about serving pages from a database

[Eric Lemings]

I'm not 100% sure but I'd say PHP (http://www.php.net/manual/en/)
would be your best bet.  It has a ton of interfaces:  I'm sure
Subversions support is out there somewhere.

Brad.

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, January 17, 2006 4:24 PM
> To: [EMAIL PROTECTED]
> Cc: stdcxx-dev@incubator.apache.org
> Subject: question about serving pages from a database
> 
> 
> Does anyone have any suggestion for how to get browsers to 
> render html files stored in a Subversion database? Here's 
> some more detail about the problem we're trying to solve:
> 
>http://issues.apache.org/jira/browse/STDCXX-12
>http://issues.apache.org/jira/browse/STDCXX-122
> 
> Thanks
> Martin
> 

[PATCH] GCC compiler on Mac OS X 10.4.6 Tiger (Darwin) does not understand -pthread or -pthreads options.

[Eric Lemings]

http://issues.apache.org/jira/browse/STDCXX-191

Index: etc/config/gcc.config
===
--- etc/config/gcc.config   (revision 410400)
+++ etc/config/gcc.config   (working copy)
@@ -157,8 +157,11 @@
   MULTI_CPPFLAGS_POSIX = -D_REENTRANT
   MULTI_LDFLAGS_POSIX   = -lpthread
 else
-  MULTI_CPPFLAGS_POSIX = -pthread
-  MULTI_LDFLAGS_POSIX  = -pthread
+  # option doesn't exist in Darwin gcc
+  ifneq ($(OSNAME),Darwin)
+MULTI_CPPFLAGS_POSIX = -pthread
+MULTI_LDFLAGS_POSIX  = -pthread
+  endif
 endif
   endif
else

[PATCH] GNU assembler on Mac OS X 10.4.6 Tiger (Darwin) does not understand .type directive.

[Eric Lemings]

http://issues.apache.org/jira/browse/STDCXX-192

===
--- etc/config/gcc.config   (revision 410400)
+++ etc/config/gcc.config   (working copy)
@@ -157,8 +157,11 @@
   MULTI_CPPFLAGS_POSIX = -D_REENTRANT
   MULTI_LDFLAGS_POSIX   = -lpthread
 else
-  MULTI_CPPFLAGS_POSIX = -pthread
-  MULTI_LDFLAGS_POSIX  = -pthread
+  # option doesn't exist in Darwin gcc
+  ifneq ($(OSNAME),Darwin)
+MULTI_CPPFLAGS_POSIX = -pthread
+MULTI_LDFLAGS_POSIX  = -pthread
+  endif
 endif
   endif
else

Re: [PATCH] GNU assembler on Mac OS X 10.4.6 Tiger (Darwin) does not understand .type directive.

[Eric Lemings]

On May 31, 2006, at 1:35 PM, Eric Lemings wrote:



http://issues.apache.org/jira/browse/STDCXX-192



The correct patch:

Index: src/i86/atomic.s
===
--- src/i86/atomic.s(revision 410704)
+++ src/i86/atomic.s(working copy)
@@ -30,7 +30,9 @@
   
 
**/

 .globl __rw_atomic_xchg8
+#ifndef __APPLE__
 .type __rw_atomic_xchg8, @function
+#endif
__rw_atomic_xchg8: /* ; char (char *x, char y)*/
 mov   4(%esp), %ecx/* ; %ecx =  
x  */
 movb  8(%esp), %al /* ; %al =  
y   */

@@ -46,7 +48,9 @@
   
 
**/

 .globl __rw_atomic_xchg16
+#ifndef __APPLE__
 .type __rw_atomic_xchg16, @function
+#endif
__rw_atomic_xchg16:/* ; short (short *x, short y) */
 mov   4(%esp), %ecx/* ; %ecx =  
x  */
 mov   8(%esp), %eax/* ; %eax =  
y  */

@@ -62,7 +66,9 @@
   
 
**/

 .globl __rw_atomic_xchg32
+#ifndef __APPLE__
 .type __rw_atomic_xchg32, @function
+#endif
__rw_atomic_xchg32:/* ; int (int *x, int y)   */
 movl  4(%esp), %ecx/* ; %ecx =  
x  */
 movl  8(%esp), %eax/* ; %eax =  
y  */

@@ -78,7 +84,9 @@
   
 
**/

 .globl __rw_atomic_add8
+#ifndef __APPLE__
 .type __rw_atomic_add8, @function
+#endif
__rw_atomic_add8:  /* ; char (char *dst, int inc) */
 mov4(%esp), %ecx   /* ; %ecx =  
dst*/
 mov8(%esp), %eax   /* ; %eax =  
inc*/

@@ -101,7 +109,9 @@
   
 
**/

  .globl __rw_atomic_add16
+#ifndef __APPLE__
 .type __rw_atomic_add16, @function
+#endif
__rw_atomic_add16: /* ; long (long *dst, long inc)*/
 mov4(%esp), %ecx   /* ; %ecx =  
dst*/
 mov8(%esp), %eax   /* ; %eax =  
inc*/

@@ -124,7 +134,9 @@
   
 
**/

 .globl __rw_atomic_add32
+#ifndef __APPLE__
 .type __rw_atomic_add32, @function
+#endif
__rw_atomic_add32: /* ; long (long *dst, long inc)*/
 movl   4(%esp), %ecx   /* ; %ecx =  
dst*/
 movl   8(%esp), %edx   /* ; %edx =  
inc*/

RE: [PATCH] GNU assembler on Mac OS X 10.4.6 Tiger (Darwin) does not understand .type directive.

[Eric Lemings]

I just tried building from a fresh checkout from Subversion copy.
The patch I sent out for

 http://issues.apache.org/jira/browse/STDCXX-191

still needs to be applied to etc/config/gcc.config but the other
two fixes are working fine.

Now I'm encountering some link errors but I'll file separate bug
reports after more investigation...


> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, June 01, 2006 12:10 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [PATCH] GNU assembler on Mac OS X 10.4.6 Tiger 
> (Darwin) does not understand .type directive.
> 
> Martin Sebor wrote:
> > Eric Lemings wrote:
> > 
> >>
> >> On May 31, 2006, at 1:35 PM, Eric Lemings wrote:
> >>
> >>>
> >>> http://issues.apache.org/jira/browse/STDCXX-192
> > 
> > 
> > I wonder if the .type is directive necessary at all. I'm 
> testing it on 
> > i86/Linux to see how things go and if the results are good I'm 
> > inclined to simply remove it.
> 
> It looks like the directive is not essential and removing it 
> doesn't cause any problems so I made this (only slightly :) 
> broader change:
> 
> http://svn.apache.org/viewvc?rev=410902&view=rev
> 
> Martin
> 

FW: Mac OS X Link Errors

[Eric Lemings]

-Original Message-
From: Martin Sebor 
Sent: Monday, June 05, 2006 10:44 AM
To: Eric Lemings
Subject: Re: Mac OS X Link Errors

Interesting. Could you forward this to the list for the record?

Thanks
Martin

Eric Lemings wrote:
>  
>
http://gcc.gnu.org/onlinedocs/gcc-4.0.3/gcc/Vague-Linkage.html#Vague-Lin
kage
> 
> "When used with GNU ld version 2.8 or later on an ELF system such as 
> GNU/Linux or Solaris 2, or on Microsoft Windows, duplicate copies of 
> these constructs will be discarded at link time. This is known as 
> COMDAT support.
> 
> On targets that don't support COMDAT, but do support weak symbols, GCC

> will use them. This way one copy will override all the others, but the

> unused copies will still take up space in the executable.
> 
> For targets which do not support either COMDAT or weak symbols, most 
> entities with vague linkage will be emitted as local symbols to avoid 
> duplicate definition errors from the linker. This will not happen for 
> local statics in inlines, however, as having multiple copies will 
> almost certainly break things."
> 
> It appears that the linker on Mac OS X is the BSD version, not the GNU

> version which is why the first option happens on other GCC 4.0 
> platforms with STDCXX.  I'll have to take a closer look at the other
two options.
> 
> Brad.
>  
> 
>
----
> *From:* Eric Lemings
> *Sent:* Friday, June 02, 2006 11:43 AM
> *To:* Martin Sebor
> *Subject:* Mac OS X Link Errors
> 
>  
> What do you make of this?
>  
> gcc -c -I/Users/elemings/Work/stdcxx/include/ansi -D_RWSTDDEBUG   
> -D_RWSTD_USE_CONFIG -I/Users/elemings/Work/stdcxx/include
> -I/Users/elemings/Build/stdcxx/include  -pedantic -nostdinc++ -g
-W
> -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long
> -Wcast-align  -fPIC /Users/elemings/Work/stdcxx/src/wctype.cpp
> gcc  assert.o atomic-cxx.o bitset.o catalog.o codecvt.o
> collate.o ctype.o ctype_bits.o exception.o export.o facet.o file.o
> instance.o ios.o ios_bits.o iostore.o iostream.o iso2022.o
limits.o
> limits_bits.o locale_bits.o locale_body.o locale_classic.o
> locale_combine.o locale_core.o locale_eq.o locale_global.o
> locale_name.o memattr.o memory.o messages.o num_get.o num_put.o
> punct.o random.o setlocale.o string.o strstream.o strtol.o
> ti_collate.o ti_filebuf.o ti_insert_dbl.o ti_insert_int.o
> ti_insert_ptr.o ti_ios.o ti_istream.o ti_messages.o ti_money_get.o
> ti_money_put.o ti_moneypunct.o ti_num_get.o ti_num_put.o
> ti_numpunct.o ti_ostream.o ti_streambuf.o ti_string.o
ti_stringbuf.o
> ti_time_get.o ti_time_put.o ti_wcollate.o ti_wfilebuf.o
> ti_winsert_dbl.o ti_winsert_int.o ti_winsert_ptr.o ti_wios.o
> ti_wistream.o ti_wmessages.o ti_wmoney_get.o ti_wmoney_put.o
> ti_wmoneypunct.o ti_wnum_get.o ti_wnum_put.o ti_wnumpunct.o
> ti_wostream.o ti_wstreambuf.o ti_wstring.o ti_wstringbuf.o
> ti_wtime_get.o ti_wtime_put.o time_get.o time_put.o tmpbuf.o
> typeinfo.o valarray.o vecbool.o version.o wcodecvt.o wctype.o
> -lsupc++ -lgcc_eh -o
/Users/elemings/Build/stdcxx/lib/libstd.so.4.2.0
> /usr/bin/ld: multiple definitions of symbol vtable for
> std::bad_exception
> exception.o definition of vtable for std::bad_exceptionin section
> (__DATA,__const)
>
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libsupc++.a(eh_exception.
o)
> private external definition of vtable for std::bad_exceptionin
> section (__DATA,__const)
> /usr/bin/ld: multiple definitions of symbol vtable for
std::bad_alloc
> memory.o definition of vtable for std::bad_allocin section
> (__DATA,__const)
>
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libsupc++.a(new_handler.o
)
> private external definition of vtable for std::bad_allocin section
> (__DATA,__const)
> collect2: ld returned 1 exit status
> make[2]: *** [/Users/elemings/Build/stdcxx/lib/libstd.so] Error 1
> make[1]: *** [lib] Error 2
> make: *** [libstd] Error 2
> I've tried without -lsupc++, without -lgcc_eh, without both of
> them...  Nothing works.
>  
> Brad.
>  
>  

[PATCH] for STDCXX-262 "Multiple vtable definitions on Darwin platforms"

[Eric Lemings]

"[gcc/Mac OS X 10.4.6 Tiger] Multiple vtable definitions for
bad_exception and bad_alloc"

$ svn diff etc/config/GNUmakefile.lib
Index: etc/config/GNUmakefile.lib
===
--- etc/config/GNUmakefile.lib  (revision 517771)
+++ etc/config/GNUmakefile.lib  (working copy)
@@ -39,6 +39,10 @@
 ONE_REPOSITORY = 1
 include ../makefile.common
 
+ifeq ($(findstring darwin,$(PLATFORM)),darwin)
+LDSOFLAGS   += -dynamiclib
+endif
+
 CXXFLAGS+= $(PICFLAGS)
 LDFLAGS += $(LDSOFLAGS) $(MAPFLAGS) $(MAPFILE)
 

Tested with gcc-4.2-20070307 snapshot on Mac OS X 10.4.8.
 
Eric.

RE: [PATCH] for STDCXX-262 "Multiple vtable definitions on Darwin platforms"

[Eric Lemings]

If LDSOFLAGS is only used when linking the library then I don't see
a problem with that since -dynamiclib is only need when linking the
library.  I'm not sure what will happen if that flag is given when
linking executables.

Now that I think about it, the -dynamiclib flag probably needs to be
within the build mode conditionals that check see if a shared
library is being built.  Not sure what will happen if that flag is
specified when building a static library.

I guess you could define yet another platform-specific variable in
gcc.config that gets added to LDFLAGS only when linking the library
(if one doesn't already exist of course).

Brad.

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, March 13, 2007 2:34 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [PATCH] for STDCXX-262 "Multiple vtable 
> definitions on Darwin platforms"
> 
> Eric Lemings wrote:
> > "[gcc/Mac OS X 10.4.6 Tiger] Multiple vtable definitions for 
> > bad_exception and bad_alloc"
> 
> Thanks Brad! Good to know there is an easy solution for this.
> 
> As for the patch, my comment is the same as what I just said 
> to Farid, i.e., that (like stdcxx C++ sources) the makefiles 
> are intended to be platform-agnostic and free of platform 
> specific ifs (and ifdefs).
> 
> Fortunately, unlike in Farid's case, the solution here should 
> be straightforward: add the -dynamiclib option to LDSOFLAGS 
> in gcc.config instead of GNUmakefile.lib.
> 
> If you post a (tested) patch that does that I'll be happy to 
> commit it on trunk.
> 
> Thanks
> Martin
> 
> > 
> > $ svn diff etc/config/GNUmakefile.lib
> > Index: etc/config/GNUmakefile.lib
> > ===
> > --- etc/config/GNUmakefile.lib  (revision 517771)
> > +++ etc/config/GNUmakefile.lib  (working copy)
> > @@ -39,6 +39,10 @@
> >  ONE_REPOSITORY = 1
> >  include ../makefile.common
> >  
> > +ifeq ($(findstring darwin,$(PLATFORM)),darwin)
> > +LDSOFLAGS   += -dynamiclib
> > +endif
> > +
> >  CXXFLAGS+= $(PICFLAGS)
> >  LDFLAGS += $(LDSOFLAGS) $(MAPFLAGS) $(MAPFILE)
> >  
> > 
> > Tested with gcc-4.2-20070307 snapshot on Mac OS X 10.4.8.
> >  
> > Eric.
> 
> 

Next Darwin/Mac OS X Porting Problem...

[Eric Lemings]

 
The util/localedef.cpp source file fails to compile.

...
gcc runall.o cmdopt.o output.o util.o exec.o display.o -o exec
-L./stdcxx/lib -lstd -lsupc++ -lgcc_eh -lm  
gcc -c -I./stdcxx/include/ansi -D_RWSTDDEBUG-D_RWSTD_USE_CONFIG
-I./stdcxx/include -I./stdcxx/include -I./stdcxx/include/loc  -pedantic
-nostdinc++ -g  -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings
-Wno-long-long -Wcast-align   ./stdcxx/util/localedef.cpp
In file included from ./stdcxx/util/localedef.cpp:33:
./stdcxx/include/ansi/clocale:62: error: '::lconv' has not been declared
./stdcxx/include/ansi/clocale:64: error: '::localeconv' has not been
declared
./stdcxx/util/localedef.cpp: In function 'bool
process_command_line(ProgramOptions*, int, char**)':
./stdcxx/util/localedef.cpp:468: warning: unused variable 'errors'
make[2]: *** [localedef.o] Error 1
make[1]: *** [util] Error 2
make: *** [libstd] Error 2
 
On Darwin (Mac OS X) platforms, these symbols are defined in the
/usr/include/_locale.h file which is included by the
/usr/include/locale.h file.

$ more /usr/include/locale.h
/*
...
 */
 
#ifndef _LOCALE_H_
#define _LOCALE_H_
 
#include <_locale.h>
 
#define LC_ALL  0
#define LC_COLLATE  1
#define LC_CTYPE2
#define LC_MONETARY 3
#define LC_NUMERIC  4
#define LC_TIME 5
#define LC_MESSAGES 6
 
#define _LC_LAST7   /* marks end */
 
__BEGIN_DECLS
char*setlocale(int, const char *);
__END_DECLS
 
#endif /* _LOCALE_H_ */
$ more /usr/include/_locale.h
/*
...
 */
 
#ifndef __LOCALE_H_
#define __LOCALE_H_
 
#include 
#include <_types.h>
 
struct lconv {
...
};
 
#ifndef NULL
#define NULL__DARWIN_NULL
#endif /* ! NULL */
 
__BEGIN_DECLS
struct lconv*localeconv(void);
__END_DECLS
 
#endif /* __LOCALE_H_ */
 
The reason why the localedef.cpp source file fails to compile is the
order of search paths for include files.  The include directive for
_locale.h finds STDCXX's _locale.h header file before it finds the
system's _locale.h header file.  The preprocessed localedef.cpp file
looks like this.
 
# 1 "./stdcxx/include/ansi/clocale" 1
# 54 "./stdcxx/include/ansi/clocale"
# 1 "/usr/include/../include/locale.h" 1 3 4
# 40 "/usr/include/../include/locale.h" 3 4
# 1 "./stdcxx/include/loc/_locale.h" 1 3 4
# 41 "/usr/include/../include/locale.h" 2 3 4
# 52 "/usr/include/../include/locale.h" 3 4
extern "C" {
char *setlocale(int, const char *);
}
# 55 "./stdcxx/include/ansi/clocale" 2
 

namespace std {
 

using ::lconv;
 
using ::localeconv;
using ::setlocale;
 
}
 
What to do about this problem?  Not sure.  Just reporting it.  ;)
 
Eric.
 

RE: [PATCH] for STDCXX-262 "Multiple vtable definitions on Darwin platforms"

[Eric Lemings]

Okay, this patch seems to work just as well.

Index: etc/config/gcc.config
===
--- etc/config/gcc.config   (revision 517771)
+++ etc/config/gcc.config   (working copy)
@@ -74,6 +74,9 @@
 ifneq ($(OSNAME),Darwin)
   # no -shared option for GCC on Mac OS X (Darwin)
   LDSOFLAGS = -shared
+else
+  # -dynamiclib is needed when linking the library
+  LDSOFLAGS = -dynamiclib
 endif 

RE: Next Darwin/Mac OS X Porting Problem...

[Eric Lemings]

Yep that fixed it.  Opened up STDCXX-356 so you can track it.

Brad.

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, March 13, 2007 8:34 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: Next Darwin/Mac OS X Porting Problem...
> 
> Eric Lemings wrote:
> >  
> > The util/localedef.cpp source file fails to compile.
> > 
> > ...
> > gcc runall.o cmdopt.o output.o util.o exec.o display.o -o exec 
> > -L./stdcxx/lib -lstd -lsupc++ -lgcc_eh -lm
> > gcc -c -I./stdcxx/include/ansi -D_RWSTDDEBUG-D_RWSTD_USE_CONFIG
> > -I./stdcxx/include -I./stdcxx/include -I./stdcxx/include/loc
>  ^^
> 
> This is the problem. You don't want ./stdcxx/include/loc
> in the search path.
> 
> I was going to continue with: "Look at one of our build
> logs for an example of the correct command line:
> http://people.apache.org/~sebor/stdcxx/results/redhat_as-5.0-e
> m64t-gcc-32b-4.1.1-11s-log.gz.txt"
> but I see we have -I$(TOPDIR)/include/loc there for the
> utilities as well, and always have! It should be just
> a matter of taking it out. Can you open a new issue for
> this?
> 
> Martin
> 
> 

TR1 Development Plan

[Eric Lemings]

Hello all,
 
I was wondering if there was a TR1 development plan in place, informal
or otherwise, for TR1 development.  I noticed that there is some
existing TR1 classes but the headers are rather old and they reside in
the transitional std::tr1 namespace.
 
I was thinking perhaps integrate the TR1 extensions directly into their
eventual namespace and headers and enable or disable the TR1 extensions
with a compile-time macro.  If the _RWSTD_ENABLE_TR1 or some such macro
is defined (initially undefined by default), then the TR1 classes will
be defined.
 
If anyone has thoughts on the issue, please post them.  Also if there
are docs somewhere that outline the plan for TR1, please point them out.
 
Thanks,
Eric.
 

RE: EASTL

[Eric Lemings]

 

> -Original Message-
> From: Mark Brown [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, May 10, 2007 11:11 PM
> To: [EMAIL PROTECTED]; stdcxx-dev@incubator.apache.org
> Cc: [EMAIL PROTECTED]
> Subject: Re: EASTL
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > Sent: Thu, 10 May 2007 13:56:11 -0600
> > To: stdcxx-dev@incubator.apache.org
> > Subject: Re: EASTL
> > 
> > Eric Lemings wrote:
> >> 
> >> Since Apache STDCXX is touted as one of, if not the, best 
> standard C++
> >> library in terms of performance, I thought the following 
> document would
> >> be especially interesting read for performance-minded 
> STDCXX maintainers
> >> and users.
> >> 
> >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
> > 
> > I barely just skimmed it but it does look interesting. We started
> > a benchmarking project some time ago but, unfortunately, it never
> > got finished. It would be *really* helpful to resurrect and complete
> > it. My very informal results I run every now and then with gcc on
> > Linux and Solaris indicate that in the area of iostreams stdcxx is
> > up to 25% faster than GNU libstdc++ and on par with stdio. I would
> > very much like to see a comprehensive comparison of other heavily
> > used components, including string and the other containers. Any
> > volunteers? ;-)
> 
> I would be happy to do some light benchmarking and post my 
> results here if you think it would be useful. Unfortunately, 
> I don't think I can commit to a comprehensive project to 
> cover the whole library.

It would be very useful, I believe in fact necessary in order to garner
the interest of like-minded people who are currently unaware of current
and potential performance advantages in STDCXX.

What sort of light benchmarking did you have in mind?  I've been
scouring
the net for benchmarking suites for C++ standard libraries.  I'm really
surprised to find very little...so far at least.  Vendors must prefer to
keep their benchmarks under wraps, not to mention their results.

Anyone have pointers/links to C++ benchmarking software?

Eric.

RE: EASTL

[Eric Lemings]

> -Original Message-
> From: Eric Lemings [mailto:[EMAIL PROTECTED] 
> Sent: Friday, May 11, 2007 10:07 AM
> To: stdcxx-dev@incubator.apache.org; [EMAIL PROTECTED]
> Subject: RE: EASTL
> 
>  
> 
...
> Anyone have pointers/links to C++ benchmarking software?

This should be a good benchmark:

http://www.stepanovpapers.com/container_benchmark.cpp 

Eric.

Intel Thread Checker Support

[Eric Lemings]

 
Questions for STDCXX users and maintainers regarding Intel Thread
Checker (ITC):
 
1. Would STDCXX benefit from ITC support?
 
2. Should ITC support be added to STDCXX?
 
For more info,
 
http://www3.intel.com/cd/software/products/asmo-na/eng/threading/219785.
htm
 
Thanks,
Eric.
 

Re: [jira] Commented: (STDCXX-358) [gcc/Mac OS X 10.4.8 Tiger] The unsetenv() function may be defined without a return value.

[Eric Lemings]

On May 18, 2007, at 6:17 PM, Martin Sebor (JIRA) wrote:



[ https://issues.apache.org/jira/browse/STDCXX-358? 
page=com.atlassian.jira.plugin.system.issuetabpanels:comment- 
tabpanel#action_12497092 ]


Martin Sebor commented on STDCXX-358:
-

I've committed your patch, thanks!

It would be nice to get stdcxx to work with the system compiler.  
Can you post the problems you see?


Not possible due to a bug in the 10.4 (Tiger) compiler.  Apple would  
have to fix the problem of external symbols not being marked  
correctly with weak linkage.


Once Leopard is released, that system compiler will most likely work.

Eric.

RE: [jira] Commented: (STDCXX-358) [gcc/Mac OS X 10.4.8 Tiger] The unsetenv() function may be defined without a return value.

[Eric Lemings]

I'm not sure if Apple has a bug report open on the problem but the GCC
bug report is documented here:
 

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Saturday, May 19, 2007 3:04 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [jira] Commented: (STDCXX-358) [gcc/Mac OS X 
> 10.4.8 Tiger] The unsetenv() function may be defined without 
> a return value.
> 
> Eric Lemings wrote:
> > 
> > On May 18, 2007, at 6:17 PM, Martin Sebor (JIRA) wrote:
> > 
> >>
> >> [ 
> >> 
> https://issues.apache.org/jira/browse/STDCXX-358?page=com.atla
> ssian.jira.plugin.system.issuetabpanels:comment-tabpanel#actio
> n_12497092 
> >> ]
> >>
> >> Martin Sebor commented on STDCXX-358:
> >> -
> >>
> >> I've committed your patch, thanks!
> >>
> >> It would be nice to get stdcxx to work with the system 
> compiler. Can 
> >> you post the problems you see?
> > 
> > Not possible due to a bug in the 10.4 (Tiger) compiler.  
> Apple would 
> > have to fix the problem of external symbols not being 
> marked correctly 
> > with weak linkage.
> 
> What exactly is the problem and Apple bug number? (It would be
> useful to know when someone asks why stdcxx doesn't work with it).
> 
> Martin
> 
> > 
> > Once Leopard is released, that system compiler will most 
> likely work.
> > 
> > Eric.
> > 
> > 
> 
> 

RE: [jira] Commented: (STDCXX-358) [gcc/Mac OS X 10.4.8 Tiger] The unsetenv() function may be defined without a return value.

[Eric Lemings]

> -Original Message-
> From: Eric Lemings 
> Sent: Monday, May 21, 2007 9:32 AM
> To: 'stdcxx-dev@incubator.apache.org'
> Subject: RE: [jira] Commented: (STDCXX-358) [gcc/Mac OS X 
> 10.4.8 Tiger] The unsetenv() function may be defined without 
> a return value.
> 
> 
> I'm not sure if Apple has a bug report open on the problem but the GCC
> bug report is documented here:

https://issues.apache.org/jira/browse/STDCXX-262

Perennial

[Eric Lemings]

 
Does anyone know of this company or ever had experience with its tools
(esp. validation suites)?
 
http://www.peren.com/
 
Thanks,
Eric.
 

RE: status of thread safety tests

[Eric Lemings]

Could you add a brief note on how the tests were built and executed?
Specifically, were they built and executed with gcc using binary
instrumentation or with icc using dynamic instrumentation?

Thanks.
 

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Monday, June 18, 2007 9:20 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: status of thread safety tests
> 
> I've been working on a document listing the thread safety tests
> in stdcxx/trunk and their current status:
> 
>http://people.apache.org/~sebor/thread_safety_tests.html
> 
> The goal is to have a full understanding of all the problems
> and address them (or at least the most important ones) in the
> final 4.2.0 release.
> 
> The document is still a work in progress, as is the test suite.
> Not all tests have been migrated from the Rogue Wave test suite
> in Perforce over to ASF Subversion. For those tests the links
> that point to the Perforce source repository won't work.
> 

RE: [VOTE] ready to graduate

[Eric Lemings]

-1!

Nah, I'm just kidding.  +1.

Seriously though, did you really expect to get any dissenting votes from
anyone on the stdcxx-dev mailing list?  :P

Eric.

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, July 05, 2007 3:14 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: [VOTE] ready to graduate
> 
> Our mentors as well as a number of IPMC members recently expressed
> confidence in stdcxx being ready to graduate out of the incubator
> (see the thread starting with msg14476 below).
> 
> In order to propose graduation to the Incubator PMC we all need to
> formally agree that we are ready. This is a vote to ascertain this
> agreement.
> 
> [ ] Check here (or use +1) to indicate you agree that stdcxx is
>  ready to graduate.
> 
> [ ] Check here (or use -1) to indicate that stdcxx is not ready
>  to graduate at this point. If you check this please provide
>  comments explaining what you feel needs to change in order
>  for it to become ready.
> 
> Martin
> 
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg14476.html
> 

FW: Built STDCXX On Mac Lately?

[Eric Lemings]

For everyone else's viewing pleasure:



From: Eric Lemings 
Sent: Thursday, July 12, 2007 6:30 PM
To: Andrew Black
Cc: Martin Sebor
Subject: Built STDCXX On Mac Lately?


 
Has anyone built STDCXX on Mac lately?  I just tried and got some
compile errors in util/localedef.cpp.  At first glance, it looks like
the change that conditionally includes  is the culprit.  There
are still symbols from that header file still being used in the source
file even when the header is not included.
 
Here's the error:
 
gcc runall.o cmdopt.o output.o util.o exec.o display.o -o exec
-L/Users/elemings/Developer/Build/stdcxx/lib -lstd -lsupc++ -lgcc_eh -lm

gcc -c -I/Users/elemings/Developer/Work/stdcxx/include/ansi
-D_RWSTDDEBUG-I/Users/elemings/Developer/Work/stdcxx/include
-I/Users/elemings/Developer/Build/stdcxx/include  -pedantic -nostdinc++
-g  -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings
-Wno-long-long -Wcast-align
/Users/elemings/Developer/Work/stdcxx/util/localedef.cpp
In file included from
/Users/elemings/Developer/Work/stdcxx/util/def.h:45,
 from
/Users/elemings/Developer/Work/stdcxx/util/localedef.cpp:30:
/Users/elemings/Developer/Work/stdcxx/util/charmap.h:167: error:
'iconv_t' does not name a type
/Users/elemings/Developer/Work/stdcxx/util/charmap.h:230: error:
'iconv_t' does not name a type
/Users/elemings/Developer/Work/stdcxx/util/charmap.h:233: error:
'iconv_t' does not name a type
/Users/elemings/Developer/Work/stdcxx/util/localedef.cpp: In function
'bool process_command_line(ProgramOptions*, int, char**)':
/Users/elemings/Developer/Work/stdcxx/util/localedef.cpp:475: warning:
unused variable 'errors'
make[2]: *** [localedef.o] Error 1
make[1]: *** [util] Error 2
make: *** [libstd] Error 2
 
I was about to file a Jira issue but thought I'd make sure this is
really an error and not my environment.
 
Brad.
 

Just a crazy idea but...

[Eric Lemings]

 
Rename the project when STDCXX graduates from the incubator.  The new
name and slogan?
 
"Use ASCXXL (Apache Standard C++ Library) to drive your C++
development."
 

RE: Just a crazy idea but...

[Eric Lemings]

 
AFAICT there are no other software projects out there that use the name
or homonyms of "axle".




From: Eric Lemings 
Sent: Monday, July 23, 2007 10:48 AM
To: 'stdcxx-dev@incubator.apache.org'
Subject: Just a crazy idea but...


 
Rename the project when STDCXX graduates from the incubator.
The new name and slogan?
 
"Use ASCXXL (Apache Standard C++ Library) to drive your C++
development."
 

RE: [RFC] draft stdcxx resolution for the Board

[Eric Lemings]

 

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] 
> Sent: Monday, August 27, 2007 2:59 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: [RFC] draft stdcxx resolution for the Board
> 
> I'm working on the Board resolution based on the following page:
> 
> http://incubator.apache.org/guides/graduation.html#tlp-resolution
> 
> and I have a few issues I need help with. I'm hoping that our
> mentors can give us guidance here, although I certainly encourage
> everyone else, most of all committers, to read through this and
> provide feedback.
> 
> 
> 1. Official project name: Apache C++ Standard Library
> 
> I have always assumed that the official name of our project is
> the Apache C++ Standard Library, and that STDCXX is an "acronym"
> or "keyword" (e.g., the same way APR is to the Apache Portable
> Runtime Project). I'm not 100% sure that everyone shares the
> same view so I'm looking for a confirmation that "Apache C++
> Standard Library" is an acceptable name to use in the resolution.
> (The attached proposed resolution assumes the answer is
> affirmative.)

I agree with the canonical name.  As for the acronym, I'd like to
propose "ASL".

EBL.

RE: [RFC] draft stdcxx resolution for the Board

[Eric Lemings]

 

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] 
> Sent: Monday, August 27, 2007 7:29 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [RFC] draft stdcxx resolution for the Board
> 
> Eric Lemings wrote:
> >  
> > 
> >> -Original Message-
> >> From: Martin Sebor [mailto:[EMAIL PROTECTED] 
> >> Sent: Monday, August 27, 2007 2:59 PM
> >> To: stdcxx-dev@incubator.apache.org
> >> Subject: [RFC] draft stdcxx resolution for the Board
> >>
> >> I'm working on the Board resolution based on the following page:
> >>
> >> http://incubator.apache.org/guides/graduation.html#tlp-resolution
> >>
> >> and I have a few issues I need help with. I'm hoping that our
> >> mentors can give us guidance here, although I certainly encourage
> >> everyone else, most of all committers, to read through this and
> >> provide feedback.
> >>
> >>
> >> 1. Official project name: Apache C++ Standard Library
> >>
> >> I have always assumed that the official name of our project is
> >> the Apache C++ Standard Library, and that STDCXX is an "acronym"
> >> or "keyword" (e.g., the same way APR is to the Apache Portable
> >> Runtime Project). I'm not 100% sure that everyone shares the
> >> same view so I'm looking for a confirmation that "Apache C++
> >> Standard Library" is an acceptable name to use in the resolution.
> >> (The attached proposed resolution assumes the answer is
> >> affirmative.)
> > 
> > I agree with the canonical name.  As for the acronym, I'd like to
> > propose "ASL".
> 
> Not ASCXXL? ;-)

Too clever I guess, some may say obfuscated.  :-P

> I'm not sure if we can easily change this or even that we should
> try. What would happen to Jira or mailing lists? I suppose lists
> could have aliases, but it might be additional work for the infra
> team.
> 
> But if you're serious about it go ahead and make a formal proposal
> to change it. Far be if for me to discourage you but I expect you
> will need to have a really compelling rationale to convince
> everyone, especially the rest of the Incubator, that it's a good
> idea.

Good idea?  Not sure.  Better acronym?  I think so.

Hypothetical scenario: another acronym is proposed, be it "ASL" or
whatever, and it is well received.  Unanimously in fact.

Would all this required work still be worth the change?  If the answer
is yes, then it's a good idea.

I just have the feeling that people will associate "STDCXX" more with
Rogue Wave Software rather than the Apache Foundation.  So in that
respect, ANY new acronym will be a better choice.

EBL.

Config Tests Comparison Questions

[Eric Lemings]

Notice the #if 2 == __GNUG__ directive in the following config source
file:
 
http://svn.apache.org/viewvc/incubator/stdcxx/trunk/etc/config/src/NEW_T
HROWS.cpp?view=markup
 
The other config tests, such as the following source file, do not have
the outer #if 2 == __GNUG__ directive.
 
http://svn.apache.org/viewvc/incubator/stdcxx/trunk/etc/config/src/STD_B
AD_CAST.cpp?view=markup
 
I believe the intent/purpose of this outer directive is already covered
by the susequent _RWSTD_NO_HONOR_STD config check.  So is the outer #if
directive really needed?
 
Also the terminate() function in the first config test is defined
slightly different from the definition used in all other config tests.
Is this definition really equivalent to (i.e. substitutable with) the
other definitions?
 
Thanks.
 

RE: want to replace rogue wave stl with apache stl

[Eric Lemings]

 

> -Original Message-
> From: Alok Shrivastava [mailto:[EMAIL PROTECTED] 
> Sent: Monday, September 10, 2007 1:43 AM
> To: stdcxx-dev@incubator.apache.org
> Subject: want to replace rogue wave stl with apache stl
> 
> Hi,
> Thanks for adding my name in the list.
> 
> I have one question-I have some c++ code which uses rogue 
> wave STL,I want to
> replace the rogue wave stl with apache stl,can it be possible 
> ?Please help
> me in this regards.

If you are building in a supported environment, then it is indeed
possible.

Can you furnish some more details?  Your operating system?  Your
compiler?  etc.

Eric.

RE: [jira] Closed: (STDCXX-517) No required options for generate.bat script

[Eric Lemings]

Typo in README file:

+specified a the suitable config file will be selected 

> -Original Message-
> From: Farid Zaripov (JIRA) [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, September 11, 2007 8:31 AM
> To: stdcxx-dev@incubator.apache.org
> Subject: [jira] Closed: (STDCXX-517) No required options for 
> generate.bat script
> 
> 
>  [ 
> https://issues.apache.org/jira/browse/STDCXX-517?page=com.atla
> ssian.jira.plugin.system.issuetabpanels:all-tabpanel ]
> 
> Farid Zaripov closed STDCXX-517.
> 
> 
> 
> > No required options for generate.bat script
> > ---
> >
> > Key: STDCXX-517
> > URL: 
> https://issues.apache.org/jira/browse/STDCXX-517
> > Project: C++ Standard Library
> >  Issue Type: Improvement
> >  Components: Configuration
> >Affects Versions: 4.1.3
> > Environment: All Windows platforms
> >Reporter: Eric Lemings
> >Assignee: Farid Zaripov
> > Fix For: 4.2
> >
> >
> > The generate.bat script currently requires two options: 
> /BUILDDIR and /CONFIG.  Unless there's a valid reason NOT to 
> do so, the generate.bat script should preset or determine the 
> following values for these options when the user does not 
> specify their own value.  /BUILDDIR should default to the 
> source directory; that is, the same directory containing the 
> generate.bat script.  For the /CONFIG option, the script 
> should probe the build environment for all possible/supported 
> Windows compilers currently installed and then sanity check 
> each one that is found.  If it finds no sane compilers, the 
> script should probably issue a warning and just exit.  If 
> only one compiler is found, configure all distribution files 
> to build with that compiler.  If more than one compiler is 
> found, set the target compiler to the first one found in 
> predefined order of preference.  (This order could be for 
> instance, MSVC 8, 7, ..., Intel C++ 10, 9, 8, etc, Cygwin 
> GCC, Mingw, Borland, etc.)
> 
> -- 
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
> 
> 

RE: svn commit: r574618 - in /incubator/stdcxx/trunk: README configure.bat generate.bat

[Eric Lemings]

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, September 11, 2007 4:21 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r574618 - in 
> /incubator/stdcxx/trunk: README configure.bat generate.bat
> 
> Since this change affects a user interface to the library I think
> we should provide a migration path for the transition to the new
> interface. I suggest we keep generate.bat but make it a symbolic
> link to configure.bat and deprecate it so that it can be removed
> in 4.3.
> 
> Martin

Migration paths are almost always A Good Thing and I agree: a link is a
good idea.  However, I just want to point out that these Windows files
were only present in one whole release of STDCXX.  I doubt backward
compatibility is a serious hurdle in this particular case.  :-P

EBL

etc/config/src/FPOS_T.cpp

[Eric Lemings]

Why does this config test check for C++ namespaces and define the std
namespace?  Do some systems defined the fpos_t type only within the std
namespace even though  is supposed to define this type at
global scope?
 
Thanks,
Eric.
 

Build tag really optional?

[Eric Lemings]

 
On line 570, the README file in RC6 says the following:
 
"  The   argument  is optional.  When  not
  specified a build type of 11s is assumed."
 
I tried that but it doesn't appear to build anything.
 
Also, the Makefiles on Unix-like platorms supported a BUILDMODE notation
(e.g. BUILDMODE=debug,pthreads,shared) in addition to the coded build
tags (e.g. 11s, 15d, etc.).  Do the Windows build scripts also support a
build mode notation or something similar?
 
Brad.
 

Problems building stdcxx-4.2.0-rc7

[Eric Lemings]

 
RC7 built fine on Windows XP ia32 and RHAP 5 em64t.  Had problems
building it on other platforms though.
 
Solaris 10 AMD64, Sun Studio 12
...
CC -c -D_RWSTDDEBUG   -mt -I/amd/devco/lemings/work/stdcxx-4.2.0/include
-I/build/lemings/stdcxx-4.2.0/include
-I/amd/devco/lemings/work/stdcxx-4.2.0/tests/include  -library=%none -g
+w -errtags -erroff=hidef
/amd/devco/lemings/work/stdcxx-4.2.0/tests/regress/26.valarray.binary.st
dcxx-237.cpp
"/amd/devco/lemings/work/stdcxx-4.2.0/tests/regress/26.valarray.binary.s
tdcxx-237.cpp", line 37: Error, nomatchoverin: Could not find a match
for std::operator%(std::gslice_array,
std::gslice_array) needed in main().
1 Error(s) detected.
gmake[2]: *** [26.valarray.binary.stdcxx-237.o] Error 1
gmake[2]: Leaving directory `/build/lemings/stdcxx-4.2.0/tests'
gmake[1]: [tests] Error 2 (ignored)
gmake[1]: Leaving directory `/build/lemings/stdcxx-4.2.0'
[1]+  Donegmake BUILDDIR=$BUILD/stdcxx-4.2.0
BUILDMODE=debug,pthreads,shared >&gmake-rhumba.out.2

HP/UX 11.23 PA-RISC, aCC 373
...
aCC -c  -D_RWSTDDEBUG   -mt
-I/amd/devco/lemings/work/stdcxx-4.2.0/include
-I/build/lemings/stdcxx-4.2.0/include
-I/amd/devco/lemings/work/stdcxx-4.2.0/tests/include  -AA  -g +d  +w
+W392 +W655 +W684 +W818 +W819 +W849
/amd/devco/lemings/work/stdcxx-4.2.0/tests/tr1.util/2.smartptr.shared.cp
p
Error 440:
"/amd/devco/lemings/work/stdcxx-4.2.0/include/tr1/_smartptr.h", line 215
# Cannot initialize 'volatile Base_0 *' with 'volatile Derived
*const'.
: _C_pbody (__rhs._C_pbody), _C_ptr (__rhs._C_ptr) {
 
Error 445:
"/amd/devco/lemings/work/stdcxx-4.2.0/tests/tr1.util/2.smartptr.shared.c
pp", line 270 # Cannot recover from earlier errors.
static void
^^^
gmake[2]: *** [2.smartptr.shared.o] Error 2
gmake[2]: Leaving directory `/build/lemings/stdcxx-4.2.0/tests'
gmake[1]: [tests] Error 2 (ignored)
gmake[1]: Leaving directory `/build/lemings/stdcxx-4.2.0'

AIX 5.3 PowerPC, vacpp 9.0
...
xlCcore_r -c -I/amd/devco/lemings/work/stdcxx-4.2.0/include/ansi
-D_RWSTDDEBUG-I/amd/devco/lemings/work/stdcxx-4.2.0/include
-I/build/lemings/stdcxx-4.2.0/include
-I/amd/devco/lemings/work/stdcxx-4.2.0/tests/include  -g
-qtemplateregistry=23.bitset.cons.ti
/amd/devco/lemings/work/stdcxx-4.2.0/tests/containers/23.bitset.cons.cpp
xlCcore_r 23.bitset.cons.o -o 23.bitset.cons
-L/build/lemings/stdcxx-4.2.0/rwtest -lrwtest
-I/amd/devco/lemings/work/stdcxx-4.2.0/include/ansi -D_RWSTDDEBUG
-liconv -brtl   -L/build/lemings/stdcxx-4.2.0/lib
-Wl,-bsvr4,-R/build/lemings/stdcxx-4.2.0/lib:/build/lemings/stdcxx-4.2.0
/rwtest -lstd  -lm -qtemplateregistry=23.bitset.cons.ti
xlCcore_r -c -I/amd/devco/lemings/work/stdcxx-4.2.0/include/ansi
-D_RWSTDDEBUG-I/amd/devco/lemings/work/stdcxx-4.2.0/include
-I/build/lemings/stdcxx-4.2.0/include
-I/amd/devco/lemings/work/stdcxx-4.2.0/tests/include  -g
-qtemplateregistry=23.bitset.cons.stdcxx-297.ti
/amd/devco/lemings/work/stdcxx-4.2.0/tests/regress/23.bitset.cons.stdcxx
-297.cpp
/nfs/packages/mdx/aix/compilers/5.2.0/va90/root/usr/vacpp/bin/.orig/xlCc
ore_r: 1501-230 (S) Internal compiler error; please contact your Service
Representative
gmake[2]: *** [23.bitset.cons.stdcxx-297.o] Error 41
gmake[2]: Leaving directory `/build/lemings/stdcxx-4.2.0/tests'
gmake[1]: [tests] Error 2 (ignored)
gmake[1]: Leaving directory `/build/lemings/stdcxx-4.2.0'

I tried building twice just to make sure.
 
Brad.
 
 

Problem configuring stdcxx-rc7 on Windows XP x64

[Eric Lemings]

 
I tried running the configure.bat script on Windows XP x64 and got the
following...error I assume:
 
P:\work\lemings_windows_ed10\3rdparty\stdcxx-4.2.0>type configure.out.1
Solution generation script
Checking arguments...
CONFIG parameter not specified, trying to detect it...
Trying msvc-8.0...
P:\work\lemings_windows_ed10\3rdparty\stdcxx-4.2.0\etc\config\windows\ge
nerate.wsf(117, 10) (null): Call was rejected by callee.
 
I have no clue what that's about...
 
Brad.
 

RE: Problem configuring stdcxx-rc7 on Windows XP x64

[Eric Lemings]

 
This error was produced from a 64-bit Visual C++ 8.0 command line.  The
configure script works as expected in a 32-bit setup.
 
Brad.




From: Eric Lemings 
Sent: Tuesday, October 23, 2007 2:45 PM
To: 'stdcxx-dev@incubator.apache.org'
Subject: Problem configuring stdcxx-rc7 on Windows XP x64


 
I tried running the configure.bat script on Windows XP x64 and
got the following...error I assume:
 
P:\work\lemings_windows_ed10\3rdparty\stdcxx-4.2.0>type
configure.out.1
Solution generation script
Checking arguments...
CONFIG parameter not specified, trying to detect it...
Trying msvc-8.0...

P:\work\lemings_windows_ed10\3rdparty\stdcxx-4.2.0\etc\config\windows\ge
nerate.wsf(117, 10) (null): Call was rejected by callee.
 
I have no clue what that's about...
 
Brad.
 

RE: Problem configuring stdcxx-rc7 on Windows XP x64

[Eric Lemings]

 

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, October 23, 2007 4:40 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: RE: Problem configuring stdcxx-rc7 on Windows XP x64
> 
> 
> 
> Eric Lemings-2 wrote:
> > 
> >  
> > This error was produced from a 64-bit Visual C++ 8.0 
> command line.  The
> > configure script works as expected in a 32-bit setup.
> > 
> > 
> 
> You mean Windows/IA64? I don't see it on our test matrix, either for
> 4.2.0-rc-7 or trunk:
> http://people.apache.org/~sebor/stdcxx-4.2.0-rc-7/results/
> http://people.apache.org/~sebor/stdcxx/results/
> 
> Martin

Oh, well nevermind then.  :P

I assumed it was a supported platform, Windows XP x64 Professional
(w/Intel Xeon).

RE: [RFC] stdcxx release process, second draft

[Eric Lemings]

Overall, I'd say it's a pretty good start.  All of the major elements
are
there: goals/objectives, tasks/procedures, definitions/roles, etc.  As
it
evolves though, you'll probably want to break the process definitions
into
two separate documents: one for the development process and one for the
release process.

Also, the versioning policy is currently intwined with the release
process.
They're closely related of course but they should be more easily
distinguished.
Were they separate documents at one time?  Just my personal preference,
but
I like to see each policy statement in a separate document since a
process is
usually defined to enact one or more policies.

I also noticed the Version Policy and Definitions are listed in the
opposite
order in the Index at the top from that given in the content.

Brad. 

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] 
> Sent: Monday, November 12, 2007 9:06 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: [RFC] stdcxx release process, second draft
> 
> 
> I've incorporated everyone's feedback and committed an updated
> version with a number of enhancements of my own. Among the most
> important are the new Goals section with suggested frequencies of
> releases, and the integration of the Version Policy (I plan to delete
> versions.html). Let me know what you think.
> 
> http://incubator.apache.org/stdcxx/releases.html
> 
> 
> Martin Sebor wrote:
> > 
> > I've checked in the first draft of a document outlining our release
> > process. It should be read along with the versioning policy that was
> > circulated earlier. I would like to integrate both into one coherent
> > policy in the near future and put it in place for 4.2.1.
> > 
> >  http://incubator.apache.org/stdcxx/releases.html
> >  http://incubator.apache.org/stdcxx/versions.html
> > 
> > Please respond with suggestions for changes, additions, corrections,
> > comments, and/or questions.
> > 
> > Thanks
> > Martin
> > 
> > 
> 
> -- 
> View this message in context: 
> http://www.nabble.com/-RFC--stdcxx-release-process-tf4729351.h
> tml#a13719498
> Sent from the stdcxx-dev mailing list archive at Nabble.com.
> 
> 

Division of STDCXX into smaller distributions?

[Eric Lemings]

 
Would it be a good idea to divide the STDCXX distribution into two
separate distributions, one distribution containing the primary source,
tools, and examples, and the second distribution containing the test
driver and test suite?
 
Would this make the test suite more robust, the test driver more
reusable, while at the same time making the library itself more
maintainable?
 
Thanks,
Eric.
 

RE: [RFC] stdcxx release process, second draft

[Eric Lemings]

 
The scope of this issue is rather large for a minor release...IMHO.

Brad.

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Tuesday, November 27, 2007 9:59 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [RFC] stdcxx release process, second draft
> 
> So here's a question: do we think STDCXX-336 doable for 4.2.1?
> 
> Martin
> 
> Farid Zaripov wrote:
> >> Martin Sebor wrote:
> >>> I've incorporated everyone's feedback and committed an 
> >> updated version 
> >>> with a number of enhancements of my own. Among the most 
> >> important are 
> >>> the new Goals section with suggested frequencies of 
> >> releases, and the 
> >>> integration of the Version Policy (I plan to delete 
> versions.html). 
> >>> Let me know what you think.
> >>>
> >>> http://incubator.apache.org/stdcxx/releases.html
> >>>
> >   
> >   I have no objections on this document.
> > 
> > 
> >   Here the some examples (the only source incompatible changes):
> > 
> > 1. Source incompatible changes
> > 
> > 1.1. Merging two or more overloaded functions/methods in one using
> > default parameters:
> >   I.e. replacing void std::vector::resize (size_type) and void
> > std::vector::resize (size_type, value_type)
> > with void std::vector::resize (size_type, value_type = 
> value_type()).
> > 
> > 1.2. Implementing the additional overloads (extensions) of 
> the standard
> > functions/methods:
> >   I.e. adding std::ostream& std::ostream::operator<< 
> (std::ostream&,
> > const wchar*).
> > 
> > 1.3. Adding some function/class in global namespace, that 
> may interfere
> > with user-defined function/class
> >   (i.e without using '__; prefix):
> >   I.e. adding function void print (const char* str) { 
> std::cout <<
> > str << std::endl; } may conflict with user defined
> >   void print (const char* str) { std::printf ("%s", 
> str); } due to
> > multiple function definition.
> > 
> > 1.4. Adding some public/protected methods not specified by standard,
> > that may interfere with user-defined
> >   methods in classes, inherited from the library class.
> > 
> > 1.5. Adding some macros that may accidentally modify the 
> user code: i.e.
> > #define new(p) malloc (p).
> > 
> > 1.6. Moving some declarations from one header file to 
> another without
> > #including the second one in the first
> >   may cause "unknown identifier" compiler error.
> > 
> > 
> > Farid.
> > 
> 
> 

GNU "Autotools" Branch?

[Eric Lemings]

I have some code that I'd like to contribute to the Apache STDCXX
repository.  It adds support for the GNU "Autotools" suite of tools
(i.e.
Autoconf, Automake, and Libtool).
 
Would a branch in the Subversion stdcxx/branches directory be the
appropriate place to check in this code?
 
Thanks.

Test Dependencies

[Eric Lemings]

It seems that most of the tests depend on nothing more than the
C++ standard library and the RWTest library.  Others have some
dependencies that are not so obvious.  Some require the TOPDIR
environment variable defined, some locale tests require the
locales database files, etc.  Can someone outlines these
dependencies in greater detail?  Or is this info documented in
a file somewhere in the distribution?
 
Thanks,
Brad.

RE: GNU "Autotools" Branch?

[Eric Lemings]

I haven't tested it on any platform other than Mac OS X; not all config
tests have been translated yet into M4 macros (especially tests related
to linking); and those that have been written need a thorough review as
well as some polishing.  So it's safe to say it's still very much in
development.

Once I get a successful 'distcheck', I'll create this branch in the
stdcxx/branches/autotools directory.  The baseline for this branch will
only contain a scant few config macros initially along with plenty of
guidance on writing the rest.  :)

Brad.

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Saturday, January 05, 2008 4:01 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: GNU "Autotools" Branch?
> 
> Eric Lemings wrote:
> > I have some code that I'd like to contribute to the Apache STDCXX
> > repository.  It adds support for the GNU "Autotools" suite of tools
> > (i.e.
> > Autoconf, Automake, and Libtool).
> >  
> > Would a branch in the Subversion stdcxx/branches directory be the
> > appropriate place to check in this code?
> 
> If you're still developing the code we can create a branches/autotools
> branch for this work. But if it's already finished and tested on all
> platforms we might want to think about rolling it into 4.3 instead
> (once it has been created).
> 
> Martin
> 
> >  
> > Thanks.
> > 
> 
> 

RE: GNU "Autotools" Branch?

[Eric Lemings]

 
This branch is now in the Apache STDCXX Subversion repository.  Read the
TODO file for some help getting started using the branch.

Note, this is just a baseline for further development.  Many of the
necessary config macros are not yet included in the branch.

Eric.

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
> Sent: Monday, January 07, 2008 5:39 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: GNU "Autotools" Branch?
> 
> Eric Lemings wrote:
> > I haven't tested it on any platform other than Mac OS X; 
> not all config
> > tests have been translated yet into M4 macros (especially 
> tests related
> > to linking); and those that have been written need a 
> thorough review as
> > well as some polishing.  So it's safe to say it's still very much in
> > development.
> > 
> > Once I get a successful 'distcheck', I'll create this branch in the
> > stdcxx/branches/autotools directory.  The baseline for this 
> branch will
> > only contain a scant few config macros initially along with 
> plenty of
> > guidance on writing the rest.  :)
> 
> Sounds good to me. Unless someone objects in the next, say, 48 hours
> go ahead and create the branch at your leisure. I assume you'll be
> branching off of trunk (as opposed to an existing branch).
> 
> Martin
> 
> > 
> > Brad.
> > 
> >> -Original Message-
> >> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of 
> Martin Sebor
> >> Sent: Saturday, January 05, 2008 4:01 PM
> >> To: stdcxx-dev@incubator.apache.org
> >> Subject: Re: GNU "Autotools" Branch?
> >>
> >> Eric Lemings wrote:
> >>> I have some code that I'd like to contribute to the Apache STDCXX
> >>> repository.  It adds support for the GNU "Autotools" 
> suite of tools
> >>> (i.e.
> >>> Autoconf, Automake, and Libtool).
> >>>  
> >>> Would a branch in the Subversion stdcxx/branches directory be the
> >>> appropriate place to check in this code?
> >> If you're still developing the code we can create a 
> branches/autotools
> >> branch for this work. But if it's already finished and 
> tested on all
> >> platforms we might want to think about rolling it into 4.3 instead
> >> (once it has been created).
> >>
> >> Martin
> >>
> >>>  
> >>> Thanks.
> >>>
> >>
> > 
> 
> 

RE: GNU "Autotools" Branch?

[Eric Lemings]

 

Duly noted.  I also reformatted the log properties for the first two
commits into the correct ChangeLog format.

Brad.

> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, January 10, 2008 1:12 PM
> To: stdcxx-dev@incubator.apache.org; Eric Lemings
> Subject: Re: GNU "Autotools" Branch?
> 
> Eric Lemings wrote:
> >  
> > This branch is now in the Apache STDCXX Subversion 
> repository.  Read the
> > TODO file for some help getting started using the branch.
> 
> Thanks for the heads up. We saw both of your commits. There was
> a flurry of helpful comments on the format of your ChangeLog that
> you might have missed:
> http://www.nabble.com/RE%3A-svn-commit%3A-r610849incubator
-stdcxx-branches-autotools--td14741375.html
> 
> Martin
> 
> > 
> > Note, this is just a baseline for further development.  Many of the
> > necessary config macros are not yet included in the branch.
> > 
> > Eric.
> > 
> >> -Original Message-
> >> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of 
> Martin Sebor
> >> Sent: Monday, January 07, 2008 5:39 PM
> >> To: stdcxx-dev@incubator.apache.org
> >> Subject: Re: GNU "Autotools" Branch?
> >>
> >> Eric Lemings wrote:
> >>> I haven't tested it on any platform other than Mac OS X; 
> >> not all config
> >>> tests have been translated yet into M4 macros (especially 
> >> tests related
> >>> to linking); and those that have been written need a 
> >> thorough review as
> >>> well as some polishing.  So it's safe to say it's still 
> very much in
> >>> development.
> >>>
> >>> Once I get a successful 'distcheck', I'll create this 
> branch in the
> >>> stdcxx/branches/autotools directory.  The baseline for this 
> >> branch will
> >>> only contain a scant few config macros initially along with 
> >> plenty of
> >>> guidance on writing the rest.  :)
> >> Sounds good to me. Unless someone objects in the next, 
> say, 48 hours
> >> go ahead and create the branch at your leisure. I assume you'll be
> >> branching off of trunk (as opposed to an existing branch).
> >>
> >> Martin
> >>
> >>> Brad.
> >>>
> >>>> -Original Message-
> >>>> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of 
> >> Martin Sebor
> >>>> Sent: Saturday, January 05, 2008 4:01 PM
> >>>> To: stdcxx-dev@incubator.apache.org
> >>>> Subject: Re: GNU "Autotools" Branch?
> >>>>
> >>>> Eric Lemings wrote:
> >>>>> I have some code that I'd like to contribute to the 
> Apache STDCXX
> >>>>> repository.  It adds support for the GNU "Autotools" 
> >> suite of tools
> >>>>> (i.e.
> >>>>> Autoconf, Automake, and Libtool).
> >>>>>  
> >>>>> Would a branch in the Subversion stdcxx/branches 
> directory be the
> >>>>> appropriate place to check in this code?
> >>>> If you're still developing the code we can create a 
> >> branches/autotools
> >>>> branch for this work. But if it's already finished and 
> >> tested on all
> >>>> platforms we might want to think about rolling it into 
> 4.3 instead
> >>>> (once it has been created).
> >>>>
> >>>> Martin
> >>>>
> >>>>>  
> >>>>> Thanks.
> >>>>>
> >>
> 
> 

[jira] Created: (STDCXX-191) GCC compiler on Mac OS X 10.4.6 Tiger (Darwin) does not have -pthread or -pthreads options.

[Eric Lemings (JIRA)]

GCC compiler on Mac OS X 10.4.6 Tiger (Darwin) does not have -pthread or 
-pthreads options.
---

 Key: STDCXX-191
 URL: http://issues.apache.org/jira/browse/STDCXX-191
 Project: C++ Standard Library
Type: Bug

  Components: Build  
Versions: 4.1.3, 4.1.4
 Environment: Darwin machine.local 8.6.1 Darwin Kernel Version 8.6.1: Tue Mar  
7 16:55:45 PST 2006; root:xnu-792.9.22.obj~1/RELEASE_I386 i386 i386
Reporter: Eric Lemings


machine:~/Work user$ svn co 
http://svn.apache.org/repos/asf/incubator/stdcxx/trunk stdcxx
Astdcxx/generate.bat
Astdcxx/LICENSE.txt
Astdcxx/tests
Astdcxx/tests/tr1.util
...
Astdcxx/examples/manual/memfunc.cpp
Astdcxx/examples/manual/io_iter.cpp
Astdcxx/examples/manual/partsum.cpp
Checked out revision 410614.
machine:~/Work user$ cd stdcxx
machine:~/Work/stdcxx user$ make BUILDMODE="debug,shared,pthreads" 
CONFIG=gcc.config
creating BUILDDIR=/Users/user/Work/stdcxx/build
generating /Users/user/Work/stdcxx/build/makefile.in from 
/Users/user/Work/stdcxx/etc/config/gcc.config
make config

configuring for gcc-4.0.1 on darwin-8.6.1-i386

checking if the compiler is sane   ok (invoked with gcc)
checking if the linker is sane ok (invoked with gcc)
checking system architecture   ILP32 little endian
...
touch config.h
generating dependencies for $(TOPDIR)/src/atomic-cxx.S
i686-apple-darwin8-gcc-4.0.1: unrecognized option '-pthread'
generating dependencies for $(TOPDIR)/src/wctype.cpp
i686-apple-darwin8-gcc-4.0.1: unrecognized option '-pthread'
generating dependencies for $(TOPDIR)/src/wcodecvt.cpp
i686-apple-darwin8-gcc-4.0.1: unrecognized option '-pthread'
...


-- 
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-192) GNU assembler on Mac OS X 10.4.6 Tiger (Darwin) does not understand .type directive.

[Eric Lemings (JIRA)]

GNU assembler on Mac OS X 10.4.6 Tiger (Darwin) does not understand .type 
directive.


 Key: STDCXX-192
 URL: http://issues.apache.org/jira/browse/STDCXX-192
 Project: C++ Standard Library
Type: Bug

  Components: Build  
Versions: 4.1.3, 4.1.4
 Environment: Darwin machine.local 8.6.1 Darwin Kernel Version 8.6.1: Tue Mar  
7 16:55:45 PST 2006; root:xnu-792.9.22.obj~1/RELEASE_I386 i386 i386
Reporter: Eric Lemings


machine:~/Work user$ svn co 
http://svn.apache.org/repos/asf/incubator/stdcxx/trunk stdcxx
A stdcxx/generate.bat
A stdcxx/LICENSE.txt
A stdcxx/tests
A stdcxx/tests/tr1.util
...
A stdcxx/examples/manual/memfunc.cpp
A stdcxx/examples/manual/io_iter.cpp
A stdcxx/examples/manual/partsum.cpp
Checked out revision 410614.
machine:~/Work user$ cd stdcxx
machine:~/Work/stdcxx user$ make BUILDMODE="debug,shared,pthreads" 
CONFIG=gcc.config
creating BUILDDIR=/Users/user/Work/stdcxx/build
generating /Users/user/Work/stdcxx/build/makefile.in from 
/Users/user/Work/stdcxx/etc/config/gcc.config
make config

configuring for gcc-4.0.1 on darwin-8.6.1-i386

checking if the compiler is sane ok (invoked with gcc)
checking if the linker is sane ok (invoked with gcc)
checking system architecture ILP32 little endian
...
gcc -c -I/Users/user/Work/stdcxx/include/ansi -D_RWSTDDEBUG   -pthread 
-D_RWSTD_USE_CONFIG -I/Users/user/Work/stdcxx/build/include 
-I/Users/user/Work/stdcxx/include  -pedantic -nostdinc++ -g  -W -Wall 
-Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align  
-fPIC /Users/user/Work/stdcxx/src/atomic-cxx.S
i686-apple-darwin8-gcc-4.0.1: unrecognized option '-pthread'
/Users/user/Work/stdcxx/src/i86/atomic.s:33:Unknown pseudo-op: .type
/Users/user/Work/stdcxx/src/i86/atomic.s:33:Rest of line ignored. 1st junk 
character valued 95 (_).
/Users/user/Work/stdcxx/src/i86/atomic.s:49:Unknown pseudo-op: .type
/Users/user/Work/stdcxx/src/i86/atomic.s:49:Rest of line ignored. 1st junk 
character valued 95 (_).
/Users/user/Work/stdcxx/src/i86/atomic.s:65:Unknown pseudo-op: .type
/Users/user/Work/stdcxx/src/i86/atomic.s:65:Rest of line ignored. 1st junk 
character valued 95 (_).
/Users/user/Work/stdcxx/src/i86/atomic.s:81:Unknown pseudo-op: .type
/Users/user/Work/stdcxx/src/i86/atomic.s:81:Rest of line ignored. 1st junk 
character valued 95 (_).
/Users/user/Work/stdcxx/src/i86/atomic.s:104:Unknown pseudo-op: .type
/Users/user/Work/stdcxx/src/i86/atomic.s:104:Rest of line ignored. 1st junk 
character valued 95 (_).
/Users/user/Work/stdcxx/src/i86/atomic.s:127:Unknown pseudo-op: .type
/Users/user/Work/stdcxx/src/i86/atomic.s:127:Rest of line ignored. 1st junk 
character valued 95 (_).
make[2]: *** [atomic-cxx.o] Error 1
make[1]: *** [lib] Error 2
make: *** [libstd] Error 2


-- 
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-193) On Mac OS X 10.4.6 Tiger (Darwin), executables in $(BUILDDIR)/include are included before $(TOPDIR)/include

[Eric Lemings (JIRA)]

On Mac OS X 10.4.6 Tiger (Darwin), executables in $(BUILDDIR)/include are 
included before $(TOPDIR)/include
---

 Key: STDCXX-193
 URL: http://issues.apache.org/jira/browse/STDCXX-193
 Project: C++ Standard Library
Type: Bug

  Components: Build  
Versions: 4.1.3, 4.1.4
 Environment: Darwin machine.local 8.6.1 Darwin Kernel Version 8.6.1: Tue Mar  
7 16:55:45 PST 2006; root:xnu-792.9.22.obj~1/RELEASE_I386 i386 i386
Reporter: Eric Lemings


That may sound weird but that's what's happening.

On Mac OS X, the HFS file system is case-insensitive.  Because of this and the 
order of include paths defined by $(INCLUDES) in etc/config/makefile.common, 
one or more of the executables for the configuration checks which have the same 
filename as standard header files (e.g. LIMITS) are found first and included in 
the source files by the compiler.

Output from an example build:

machine:~/Build/stdcxx user$ make BUILDDIR=~/Build/stdcxx 
BUILDMODE=debug,shared,pthreads
GNUmakefile:283: "CONFIG not specified, using gcc.config"
creating BUILDDIR=/Users/user/Build/stdcxx
generating /Users/user/Build/stdcxx/makefile.in from 
/Users/user/Work/stdcxx/etc/config/gcc.config
make config

configuring for gcc-4.0.1 on darwin-8.6.1-i386

checking if the compiler is sane   ok (invoked with gcc)
checking if the linker is sane ok (invoked with gcc)
...
gcc -c -I/Users/user/Work/stdcxx/include/ansi -D_RWSTDDEBUG
-D_RWSTD_USE_CONFIG -I/Users/user/Build/stdcxx/include 
-I/Users/user/Work/stdcxx/include  -pedantic -nostdinc++ -g  -W -Wall 
-Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align   
/Users/user/Work/stdcxx/src/codecvt.cpp
gcc -c -I/Users/user/Work/stdcxx/include/ansi -D_RWSTDDEBUG
-D_RWSTD_USE_CONFIG -I/Users/user/Build/stdcxx/include 
-I/Users/user/Work/stdcxx/include  -pedantic -nostdinc++ -g  -W -Wall 
-Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align   
/Users/user/Work/stdcxx/src/collate.cpp
In file included from /Users/user/Work/stdcxx/src/collate.cpp:38:
/Users/user/Build/stdcxx/include/limits:1: error: stray '\206' in program
/Users/user/Build/stdcxx/include/limits:1: error: stray '\250' in program
/Users/user/Build/stdcxx/include/limits:1: error: stray '\237' in program
/Users/user/Build/stdcxx/include/limits:1: error: stray '\254' in program
/Users/user/Build/stdcxx/include/limits:1: error: stray '\7' in program
...


-- 
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-194) GCC compiler on Mac OS X 10.4.6 Tiger (Darwin) does not understand -shared option.

[Eric Lemings (JIRA)]

GCC compiler on Mac OS X 10.4.6 Tiger (Darwin) does not understand -shared 
option.
--

 Key: STDCXX-194
 URL: http://issues.apache.org/jira/browse/STDCXX-194
 Project: C++ Standard Library
Type: Bug

  Components: Build  
Versions: 4.1.3, 4.1.4
 Environment: Darwin machine.local 8.6.1 Darwin Kernel Version 8.6.1: Tue Mar  
7 16:55:45 PST 2006; root:xnu-792.9.22.obj~1/RELEASE_I386 i386 i386
Reporter: Eric Lemings



Sample build:

machine:~/Work/stdcxx user$ make BUILDDIR=~/Build/stdcxx 
BUILDMODE=debug,shared,pthreads
machine:~/Work/stdcxx user$ cd ~/Build/stdcxx
machine:~/Build/stdcxx user$ find . -exec grep -H -- -shared {} \;
./GNUmakefile:# not applicable to non-shared builds
./include/config.log:gcc collapse_static_locals.lib.so.o   -lm -lsupc++ 
-lgcc_eh -shared -o collapse_static_locals.lib.so
./include/config.log:i686-apple-darwin8-gcc-4.0.1: unrecognized option '-shared'
./include/config.log:gcc collapse_template_locals.lib.so.o   -lm -lsupc++ 
-lgcc_eh -shared -o collapse_template_locals.lib.so
./include/config.log:i686-apple-darwin8-gcc-4.0.1: unrecognized option '-shared'
./include/config.log:gcc collapse_template_statics.lib.so.o   -lm -lsupc++ 
-lgcc_eh -shared -o collapse_template_statics.lib.so
./include/config.log:i686-apple-darwin8-gcc-4.0.1: unrecognized option '-shared'
./include/config.log:gcc extern_inline.lib.so.o   -lm -lsupc++ -lgcc_eh -shared 
-o extern_inline.lib.so
./include/config.log:i686-apple-darwin8-gcc-4.0.1: unrecognized option '-shared'
./include/config.log:gcc lib_exceptions.lib.so.o   -lm -lsupc++ -lgcc_eh 
-shared -o lib_exceptions.lib.so
./include/config.log:i686-apple-darwin8-gcc-4.0.1: unrecognized option '-shared'
./include/config.log:gcc collapse_static_locals.lib.so.o   -lm -lsupc++ 
-lgcc_eh -shared -o collapse_static_locals.lib.so
./include/config.log:i686-apple-darwin8-gcc-4.0.1: unrecognized option '-shared'
./include/config.log:gcc collapse_template_locals.lib.so.o   -lm -lsupc++ 
-lgcc_eh -shared -o collapse_template_locals.lib.so
./include/config.log:i686-apple-darwin8-gcc-4.0.1: unrecognized option '-shared'
./include/config.log:gcc collapse_template_statics.lib.so.o   -lm -lsupc++ 
-lgcc_eh -shared -o collapse_template_statics.lib.so
./include/config.log:i686-apple-darwin8-gcc-4.0.1: unrecognized option '-shared'
./include/config.log:gcc extern_inline.lib.so.o   -lm -lsupc++ -lgcc_eh -shared 
-o extern_inline.lib.so
./include/config.log:i686-apple-darwin8-gcc-4.0.1: unrecognized option '-shared'
./include/config.log:gcc lib_exceptions.lib.so.o   -lm -lsupc++ -lgcc_eh 
-shared -o lib_exceptions.lib.so
./include/config.log:i686-apple-darwin8-gcc-4.0.1: unrecognized option '-shared'
./include/vars.sh:LDSOFLAGS=-shared ; export LDSOFLAGS
./makefile.in:LDSOFLAGS  = -shared


Here's a patch for it:

*** gcc.config.2Fri Jun  2 10:26:53 2006
--- gcc.config  Fri Jun  2 11:04:19 2006
***
*** 62,68 
--- 62,71 
endif
  endif
  
+ # No -shared option for GCC on Mac OS X (Darwin).
+ ifneq ($(OSNAME),Darwin)
  LDSOFLAGS   = -shared
+ endif
  
  # -fPIC needed both to compile and link shared libs on HP-UX 11
  ifeq ($(OSNAME),HP-UX)


-- 
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] Commented: (STDCXX-194) GCC compiler on Mac OS X 10.4.6 Tiger (Darwin) does not understand -shared option.

[Eric Lemings (JIRA)]

[ 
http://issues.apache.org/jira/browse/STDCXX-194?page=comments#action_12414849 ] 

Eric Lemings commented on STDCXX-194:
-

See also 
http://developer.apple.com/documentation/DeveloperTools/gcc-4.0.1/gcc/Link-Options.html#Link-Options

> GCC compiler on Mac OS X 10.4.6 Tiger (Darwin) does not understand -shared 
> option.
> --
>
>  Key: STDCXX-194
>  URL: http://issues.apache.org/jira/browse/STDCXX-194
>  Project: C++ Standard Library
> Type: Bug

>   Components: Build
> Versions: 4.1.3, 4.1.4
>  Environment: Darwin machine.local 8.6.1 Darwin Kernel Version 8.6.1: Tue Mar 
>  7 16:55:45 PST 2006; root:xnu-792.9.22.obj~1/RELEASE_I386 i386 i386
> Reporter: Eric Lemings

>
> Sample build:
> machine:~/Work/stdcxx user$ make BUILDDIR=~/Build/stdcxx 
> BUILDMODE=debug,shared,pthreads
> machine:~/Work/stdcxx user$ cd ~/Build/stdcxx
> machine:~/Build/stdcxx user$ find . -exec grep -H -- -shared {} \;
> ./GNUmakefile:# not applicable to non-shared builds
> ./include/config.log:gcc collapse_static_locals.lib.so.o   -lm -lsupc++ 
> -lgcc_eh -shared -o collapse_static_locals.lib.so
> ./include/config.log:i686-apple-darwin8-gcc-4.0.1: unrecognized option 
> '-shared'
> ./include/config.log:gcc collapse_template_locals.lib.so.o   -lm -lsupc++ 
> -lgcc_eh -shared -o collapse_template_locals.lib.so
> ./include/config.log:i686-apple-darwin8-gcc-4.0.1: unrecognized option 
> '-shared'
> ./include/config.log:gcc collapse_template_statics.lib.so.o   -lm -lsupc++ 
> -lgcc_eh -shared -o collapse_template_statics.lib.so
> ./include/config.log:i686-apple-darwin8-gcc-4.0.1: unrecognized option 
> '-shared'
> ./include/config.log:gcc extern_inline.lib.so.o   -lm -lsupc++ -lgcc_eh 
> -shared -o extern_inline.lib.so
> ./include/config.log:i686-apple-darwin8-gcc-4.0.1: unrecognized option 
> '-shared'
> ./include/config.log:gcc lib_exceptions.lib.so.o   -lm -lsupc++ -lgcc_eh 
> -shared -o lib_exceptions.lib.so
> ./include/config.log:i686-apple-darwin8-gcc-4.0.1: unrecognized option 
> '-shared'
> ./include/config.log:gcc collapse_static_locals.lib.so.o   -lm -lsupc++ 
> -lgcc_eh -shared -o collapse_static_locals.lib.so
> ./include/config.log:i686-apple-darwin8-gcc-4.0.1: unrecognized option 
> '-shared'
> ./include/config.log:gcc collapse_template_locals.lib.so.o   -lm -lsupc++ 
> -lgcc_eh -shared -o collapse_template_locals.lib.so
> ./include/config.log:i686-apple-darwin8-gcc-4.0.1: unrecognized option 
> '-shared'
> ./include/config.log:gcc collapse_template_statics.lib.so.o   -lm -lsupc++ 
> -lgcc_eh -shared -o collapse_template_statics.lib.so
> ./include/config.log:i686-apple-darwin8-gcc-4.0.1: unrecognized option 
> '-shared'
> ./include/config.log:gcc extern_inline.lib.so.o   -lm -lsupc++ -lgcc_eh 
> -shared -o extern_inline.lib.so
> ./include/config.log:i686-apple-darwin8-gcc-4.0.1: unrecognized option 
> '-shared'
> ./include/config.log:gcc lib_exceptions.lib.so.o   -lm -lsupc++ -lgcc_eh 
> -shared -o lib_exceptions.lib.so
> ./include/config.log:i686-apple-darwin8-gcc-4.0.1: unrecognized option 
> '-shared'
> ./include/vars.sh:LDSOFLAGS=-shared ; export LDSOFLAGS
> ./makefile.in:LDSOFLAGS  = -shared
> Here's a patch for it:
> *** gcc.config.2Fri Jun  2 10:26:53 2006
> --- gcc.config  Fri Jun  2 11:04:19 2006
> ***
> *** 62,68 
> --- 62,71 
> endif
>   endif
>   
> + # No -shared option for GCC on Mac OS X (Darwin).
> + ifneq ($(OSNAME),Darwin)
>   LDSOFLAGS   = -shared
> + endif
>   
>   # -fPIC needed both to compile and link shared libs on HP-UX 11
>   ifeq ($(OSNAME),HP-UX)

-- 
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-197) Shared libraries on Mac OS X (Darwin) use '.dylib' suffix.

[Eric Lemings (JIRA)]

Shared libraries on Mac OS X (Darwin) use '.dylib' suffix.
--

 Key: STDCXX-197
 URL: http://issues.apache.org/jira/browse/STDCXX-197
 Project: C++ Standard Library
Type: Bug

Versions: 4.1.3, 4.1.4, 4.2
 Environment: Darwin cyphrus.local 8.6.1 Darwin Kernel Version 8.6.1: Tue Mar  
7 16:55:45 PST 2006; root:xnu-792.9.22.obj~1/RELEASE_I386 i386 i386
Reporter: Eric Lemings


Shared libraries on Mac OS X (Darwin) use '.dylib' suffix instead of the 
traditional '.so' suffix on most Unix systems.

Proposed patch:

Index: etc/config/gcc.config
===
--- etc/config/gcc.config   (revision 411913)
+++ etc/config/gcc.config   (working copy)
@@ -138,6 +138,10 @@
   SHARED_SUFFIX   = .sl
 endif
 
+ifeq ($(OSNAME),Darwin)
+  SHARED_SUFFIX   = .dylib
+endif
+
 STATIC_CXXFLAGS =
 STATIC_CPPFLAGS =
 STATIC_LDFLAGS  =


-- 
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-262) [gcc/Mac OS X 10.4.6 Tiger] Multiple vtable definitions for bad_exception and bad_alloc.

[Eric Lemings (JIRA)]

[gcc/Mac OS X 10.4.6 Tiger] Multiple vtable definitions for bad_exception and 
bad_alloc.


 Key: STDCXX-262
 URL: http://issues.apache.org/jira/browse/STDCXX-262
 Project: C++ Standard Library
  Issue Type: Bug
  Components: Build
Affects Versions: 4.1.3
 Environment: Darwin cyphrus.local 8.7.1 Darwin Kernel Version 8.7.1: 
Wed Jun  7 16:19:56 PDT 2006; root:xnu-792.9.72.obj~2/RELEASE_I386 i386 i386
Reporter: Eric Lemings


machine:~/Work user$ svn co 
http://svn.apache.org/repos/asf/incubator/stdcxx/trunk stdcxx
Astdcxx/generate.bat
Astdcxx/LICENSE.txt
Astdcxx/tests
Astdcxx/tests/tr1.util
...
Astdcxx/examples/manual/time_put.cpp
Astdcxx/examples/manual/moneyget.cpp
Astdcxx/examples/manual/except.cpp
Astdcxx/examples/manual/memfunc.cpp
Checked out revision 423638.
machine:~/Work user$ cd stdcxx
machine:~/Work/stdcxx user$ make BUILDDIR="~/Build" 
BUILDMODE="debug,shared,pthreads"
creating BUILDDIR=/Users/user/Build/stdcxx
generating /Users/user/Build/stdcxx/makefile.in from 
/Users/user/Work/stdcxx/etc/config/gcc.config
make config

configuring for gcc-4.0.1 on darwin-8.7.1-i386

checking if the compiler is sane   ok (invoked with gcc)
checking if the linker is sane ok (invoked with gcc)
checking system architecture   ILP32 little endian
...
gcc -c -I/Users/user/Work/stdcxx/include/ansi -D_RWSTDDEBUG
-D_RWSTD_USE_CONFIG -I/Users/user/Work/stdcxx/include 
-I/Users/user/Build/stdcxx/include  -pedantic -nostdinc++ -g  -W -Wall 
-Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align  
-fPIC /Users/user/Work/stdcxx/src/wctype.cpp
gcc  assert.o atomic-cxx.o bitset.o catalog.o codecvt.o collate.o ctype.o 
ctype_bits.o exception.o export.o facet.o file.o instance.o ios.o ios_bits.o 
iostore.o iostream.o iso2022.o limits.o limits_bits.o locale_bits.o 
locale_body.o locale_classic.o locale_combine.o locale_core.o locale_eq.o 
locale_global.o locale_name.o memattr.o memory.o messages.o num_get.o num_put.o 
punct.o random.o setlocale.o string.o strstream.o strtol.o ti_collate.o 
ti_filebuf.o ti_insert_dbl.o ti_insert_int.o ti_insert_ptr.o ti_ios.o 
ti_istream.o ti_messages.o ti_money_get.o ti_money_put.o ti_moneypunct.o 
ti_num_get.o ti_num_put.o ti_numpunct.o ti_ostream.o ti_streambuf.o ti_string.o 
ti_stringbuf.o ti_time_get.o ti_time_put.o ti_wcollate.o ti_wfilebuf.o 
ti_winsert_dbl.o ti_winsert_int.o ti_winsert_ptr.o ti_wios.o ti_wistream.o 
ti_wmessages.o ti_wmoney_get.o ti_wmoney_put.o ti_wmoneypunct.o ti_wnum_get.o 
ti_wnum_put.o ti_wnumpunct.o ti_wostream.o ti_wstreambuf.o ti_wstring.o 
ti_wstringbuf.o ti_wtime_get.o ti_wtime_put.o time_get.o time_put.o tmpbuf.o 
typeinfo.o valarray.o vecbool.o version.o wcodecvt.o wctype.o -lsupc++ -lgcc_eh 
-o /Users/user/Build/stdcxx/lib/libstd.dylib.4.2.0 
/usr/bin/ld: multiple definitions of symbol vtable for std::bad_exception
exception.o definition of vtable for std::bad_exceptionin section 
(__DATA,__const)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libsupc++.a(eh_exception.o) 
private external definition of vtable for std::bad_exceptionin section 
(__DATA,__const)
/usr/bin/ld: multiple definitions of symbol vtable for std::bad_alloc
memory.o definition of vtable for std::bad_allocin section (__DATA,__const)
/usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libsupc++.a(new_handler.o) 
private external definition of vtable for std::bad_allocin section 
(__DATA,__const)
collect2: ld returned 1 exit status
make[2]: *** [/Users/user/Build/stdcxx/lib/libstd.dylib] Error 1
make[1]: *** [lib] Error 2
make: *** [libstd] Error 2


-- 
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] Updated: (STDCXX-262) [gcc/Mac OS X 10.4.6 Tiger] Multiple vtable definitions for bad_exception and bad_alloc.

[Eric Lemings (JIRA)]

 [ http://issues.apache.org/jira/browse/STDCXX-262?page=all ]

Eric Lemings updated STDCXX-262:


Environment: Darwin machine.local 8.7.1 Darwin Kernel Version 8.7.1: Wed 
Jun  7 16:19:56 PDT 2006; root:xnu-792.9.72.obj~2/RELEASE_I386 i386 i386  (was: 
Darwin cyphrus.local 8.7.1 Darwin Kernel Version 8.7.1: Wed Jun  7 16:19:56 PDT 
2006; root:xnu-792.9.72.obj~2/RELEASE_I386 i386 i386)

> [gcc/Mac OS X 10.4.6 Tiger] Multiple vtable definitions for bad_exception and 
> bad_alloc.
> 
>
> Key: STDCXX-262
> URL: http://issues.apache.org/jira/browse/STDCXX-262
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 4.1.3
> Environment: Darwin machine.local 8.7.1 Darwin Kernel Version 8.7.1: 
> Wed Jun  7 16:19:56 PDT 2006; root:xnu-792.9.72.obj~2/RELEASE_I386 i386 i386
>Reporter: Eric Lemings
>
> machine:~/Work user$ svn co 
> http://svn.apache.org/repos/asf/incubator/stdcxx/trunk stdcxx
> Astdcxx/generate.bat
> Astdcxx/LICENSE.txt
> Astdcxx/tests
> Astdcxx/tests/tr1.util
> ...
> Astdcxx/examples/manual/time_put.cpp
> Astdcxx/examples/manual/moneyget.cpp
> Astdcxx/examples/manual/except.cpp
> Astdcxx/examples/manual/memfunc.cpp
> Checked out revision 423638.
> machine:~/Work user$ cd stdcxx
> machine:~/Work/stdcxx user$ make BUILDDIR="~/Build" 
> BUILDMODE="debug,shared,pthreads"
> creating BUILDDIR=/Users/user/Build/stdcxx
> generating /Users/user/Build/stdcxx/makefile.in from 
> /Users/user/Work/stdcxx/etc/config/gcc.config
> make config
> configuring for gcc-4.0.1 on darwin-8.7.1-i386
> checking if the compiler is sane   ok (invoked with gcc)
> checking if the linker is sane ok (invoked with gcc)
> checking system architecture   ILP32 little endian
> ...
> gcc -c -I/Users/user/Work/stdcxx/include/ansi -D_RWSTDDEBUG
> -D_RWSTD_USE_CONFIG -I/Users/user/Work/stdcxx/include 
> -I/Users/user/Build/stdcxx/include  -pedantic -nostdinc++ -g  -W -Wall 
> -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align  
> -fPIC /Users/user/Work/stdcxx/src/wctype.cpp
> gcc  assert.o atomic-cxx.o bitset.o catalog.o codecvt.o collate.o ctype.o 
> ctype_bits.o exception.o export.o facet.o file.o instance.o ios.o ios_bits.o 
> iostore.o iostream.o iso2022.o limits.o limits_bits.o locale_bits.o 
> locale_body.o locale_classic.o locale_combine.o locale_core.o locale_eq.o 
> locale_global.o locale_name.o memattr.o memory.o messages.o num_get.o 
> num_put.o punct.o random.o setlocale.o string.o strstream.o strtol.o 
> ti_collate.o ti_filebuf.o ti_insert_dbl.o ti_insert_int.o ti_insert_ptr.o 
> ti_ios.o ti_istream.o ti_messages.o ti_money_get.o ti_money_put.o 
> ti_moneypunct.o ti_num_get.o ti_num_put.o ti_numpunct.o ti_ostream.o 
> ti_streambuf.o ti_string.o ti_stringbuf.o ti_time_get.o ti_time_put.o 
> ti_wcollate.o ti_wfilebuf.o ti_winsert_dbl.o ti_winsert_int.o 
> ti_winsert_ptr.o ti_wios.o ti_wistream.o ti_wmessages.o ti_wmoney_get.o 
> ti_wmoney_put.o ti_wmoneypunct.o ti_wnum_get.o ti_wnum_put.o ti_wnumpunct.o 
> ti_wostream.o ti_wstreambuf.o ti_wstring.o ti_wstringbuf.o ti_wtime_get.o 
> ti_wtime_put.o time_get.o time_put.o tmpbuf.o typeinfo.o valarray.o vecbool.o 
> version.o wcodecvt.o wctype.o -lsupc++ -lgcc_eh -o 
> /Users/user/Build/stdcxx/lib/libstd.dylib.4.2.0 
> /usr/bin/ld: multiple definitions of symbol vtable for std::bad_exception
> exception.o definition of vtable for std::bad_exceptionin section 
> (__DATA,__const)
> /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libsupc++.a(eh_exception.o) 
> private external definition of vtable for std::bad_exceptionin section 
> (__DATA,__const)
> /usr/bin/ld: multiple definitions of symbol vtable for std::bad_alloc
> memory.o definition of vtable for std::bad_allocin section (__DATA,__const)
> /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libsupc++.a(new_handler.o) 
> private external definition of vtable for std::bad_allocin section 
> (__DATA,__const)
> collect2: ld returned 1 exit status
> make[2]: *** [/Users/user/Build/stdcxx/lib/libstd.dylib] Error 1
> make[1]: *** [lib] Error 2
> make: *** [libstd] Error 2

-- 
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-299) Create new Subversion branch and move existing TR1-related files to this new branch.

[Eric Lemings (JIRA)]

Create new Subversion branch and move existing TR1-related files to this new 
branch.


 Key: STDCXX-299
 URL: http://issues.apache.org/jira/browse/STDCXX-299
 Project: C++ Standard Library
  Issue Type: Task
  Components: TR1 - Technical Report on C++ Library Extensions, TR1.1 - 
General, TR1.2 - General Utilities, TR1.3 - Function Objects, TR1.4 - 
Metaprogramming and Type Traits, TR1.5 - Numerical Facilities, TR1.6 - 
Containers, TR1.7 - Regular Expressions, TR1.8 - C Compatibility
Affects Versions: 4.2
 Environment: All environments.
Reporter: Eric Lemings
Priority: Minor


To mitigate risks involved with TR1 development, a new Subversion branch needs 
to be created off the main trunk exclusively for TR1 development.  All existing 
files related to TR1 development need to be moved into this new branch.

This task is related to bugs STDCXX-27 through STDCXX-34.


-- 
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] Updated: (STDCXX-299) Create new Subversion branch and move existing TR1-related files to this new branch.

[Eric Lemings (JIRA)]

 [ http://issues.apache.org/jira/browse/STDCXX-299?page=all ]

Eric Lemings updated STDCXX-299:


Description: 
To mitigate risks involved with TR1 development, a new Subversion branch needs 
to be created off the main trunk exclusively for TR1 development.  All existing 
files related to TR1 development need to be moved into this new branch.

This task is a requisite for bugs STDCXX-27 through STDCXX-34.


  was:
To mitigate risks involved with TR1 development, a new Subversion branch needs 
to be created off the main trunk exclusively for TR1 development.  All existing 
files related to TR1 development need to be moved into this new branch.

This task is related to bugs STDCXX-27 through STDCXX-34.



> Create new Subversion branch and move existing TR1-related files to this new 
> branch.
> 
>
> Key: STDCXX-299
> URL: http://issues.apache.org/jira/browse/STDCXX-299
> Project: C++ Standard Library
>  Issue Type: Task
>  Components: TR1 - Technical Report on C++ Library Extensions, TR1.1 
> - General, TR1.2 - General Utilities, TR1.3 - Function Objects, TR1.4 - 
> Metaprogramming and Type Traits, TR1.5 - Numerical Facilities, TR1.6 - 
> Containers, TR1.7 - Regular Expressions, TR1.8 - C Compatibility
>Affects Versions: 4.2
> Environment: All environments.
>Reporter: Eric Lemings
>Priority: Minor
>
> To mitigate risks involved with TR1 development, a new Subversion branch 
> needs to be created off the main trunk exclusively for TR1 development.  All 
> existing files related to TR1 development need to be moved into this new 
> branch.
> This task is a requisite for bugs STDCXX-27 through STDCXX-34.

-- 
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-312) Create Subversion branch off of 4.2 baseline.

[Eric Lemings (JIRA)]

Create Subversion branch off of 4.2 baseline.
-

 Key: STDCXX-312
 URL: http://issues.apache.org/jira/browse/STDCXX-312
 Project: C++ Standard Library
  Issue Type: Sub-task
Affects Versions: 4.2
Reporter: Eric Lemings


Once the 4.2 baseline is complete, create the Subversion branch for TR1 
development.


-- 
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] Updated: (STDCXX-312) Create Subversion branch off of 4.2 baseline.

[Eric Lemings (JIRA)]

 [ http://issues.apache.org/jira/browse/STDCXX-312?page=all ]

Eric Lemings updated STDCXX-312:


Component/s: TR1 - Technical Report on C++ Library Extensions
 TR1.1 - General
 TR1.2 - General Utilities
 TR1.3 - Function Objects
 TR1.4 - Metaprogramming and Type Traits
 TR1.5 - Numerical Facilities
 TR1.6 - Containers
 TR1.7 - Regular Expressions
 TR1.8 - C Compatibility

> Create Subversion branch off of 4.2 baseline.
> -
>
> Key: STDCXX-312
> URL: http://issues.apache.org/jira/browse/STDCXX-312
> Project: C++ Standard Library
>  Issue Type: Sub-task
>  Components: TR1 - Technical Report on C++ Library Extensions, TR1.1 
> - General, TR1.2 - General Utilities, TR1.3 - Function Objects, TR1.4 - 
> Metaprogramming and Type Traits, TR1.5 - Numerical Facilities, TR1.6 - 
> Containers, TR1.7 - Regular Expressions, TR1.8 - C Compatibility
>Affects Versions: 4.2
>Reporter: Eric Lemings
>
> Once the 4.2 baseline is complete, create the Subversion branch for TR1 
> development.

-- 
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] Commented: (STDCXX-262) [gcc/Mac OS X 10.4.6 Tiger] Multiple vtable definitions for bad_exception and bad_alloc.

[Eric Lemings (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476648
 ] 

Eric Lemings commented on STDCXX-262:
-

This problem is apparently due to a bug in the G++ ABI implementation on Darwin 
and is supposedly fixed in the GCC 4.2 release series.  Hopefully, Apple will 
pick this regression fix up in a future release.  (Leopard/Xcode 3.0 maybe?)

See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25908 for more details.

> [gcc/Mac OS X 10.4.6 Tiger] Multiple vtable definitions for bad_exception and 
> bad_alloc.
> 
>
> Key: STDCXX-262
> URL: https://issues.apache.org/jira/browse/STDCXX-262
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 4.1.3
> Environment: Darwin machine.local 8.7.1 Darwin Kernel Version 8.7.1: 
> Wed Jun  7 16:19:56 PDT 2006; root:xnu-792.9.72.obj~2/RELEASE_I386 i386 i386
>Reporter: Eric Lemings
>
> machine:~/Work user$ svn co 
> http://svn.apache.org/repos/asf/incubator/stdcxx/trunk stdcxx
> Astdcxx/generate.bat
> Astdcxx/LICENSE.txt
> Astdcxx/tests
> Astdcxx/tests/tr1.util
> ...
> Astdcxx/examples/manual/time_put.cpp
> Astdcxx/examples/manual/moneyget.cpp
> Astdcxx/examples/manual/except.cpp
> Astdcxx/examples/manual/memfunc.cpp
> Checked out revision 423638.
> machine:~/Work user$ cd stdcxx
> machine:~/Work/stdcxx user$ make BUILDDIR="~/Build" 
> BUILDMODE="debug,shared,pthreads"
> creating BUILDDIR=/Users/user/Build/stdcxx
> generating /Users/user/Build/stdcxx/makefile.in from 
> /Users/user/Work/stdcxx/etc/config/gcc.config
> make config
> configuring for gcc-4.0.1 on darwin-8.7.1-i386
> checking if the compiler is sane   ok (invoked with gcc)
> checking if the linker is sane ok (invoked with gcc)
> checking system architecture   ILP32 little endian
> ...
> gcc -c -I/Users/user/Work/stdcxx/include/ansi -D_RWSTDDEBUG
> -D_RWSTD_USE_CONFIG -I/Users/user/Work/stdcxx/include 
> -I/Users/user/Build/stdcxx/include  -pedantic -nostdinc++ -g  -W -Wall 
> -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align  
> -fPIC /Users/user/Work/stdcxx/src/wctype.cpp
> gcc  assert.o atomic-cxx.o bitset.o catalog.o codecvt.o collate.o ctype.o 
> ctype_bits.o exception.o export.o facet.o file.o instance.o ios.o ios_bits.o 
> iostore.o iostream.o iso2022.o limits.o limits_bits.o locale_bits.o 
> locale_body.o locale_classic.o locale_combine.o locale_core.o locale_eq.o 
> locale_global.o locale_name.o memattr.o memory.o messages.o num_get.o 
> num_put.o punct.o random.o setlocale.o string.o strstream.o strtol.o 
> ti_collate.o ti_filebuf.o ti_insert_dbl.o ti_insert_int.o ti_insert_ptr.o 
> ti_ios.o ti_istream.o ti_messages.o ti_money_get.o ti_money_put.o 
> ti_moneypunct.o ti_num_get.o ti_num_put.o ti_numpunct.o ti_ostream.o 
> ti_streambuf.o ti_string.o ti_stringbuf.o ti_time_get.o ti_time_put.o 
> ti_wcollate.o ti_wfilebuf.o ti_winsert_dbl.o ti_winsert_int.o 
> ti_winsert_ptr.o ti_wios.o ti_wistream.o ti_wmessages.o ti_wmoney_get.o 
> ti_wmoney_put.o ti_wmoneypunct.o ti_wnum_get.o ti_wnum_put.o ti_wnumpunct.o 
> ti_wostream.o ti_wstreambuf.o ti_wstring.o ti_wstringbuf.o ti_wtime_get.o 
> ti_wtime_put.o time_get.o time_put.o tmpbuf.o typeinfo.o valarray.o vecbool.o 
> version.o wcodecvt.o wctype.o -lsupc++ -lgcc_eh -o 
> /Users/user/Build/stdcxx/lib/libstd.dylib.4.2.0 
> /usr/bin/ld: multiple definitions of symbol vtable for std::bad_exception
> exception.o definition of vtable for std::bad_exceptionin section 
> (__DATA,__const)
> /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libsupc++.a(eh_exception.o) 
> private external definition of vtable for std::bad_exceptionin section 
> (__DATA,__const)
> /usr/bin/ld: multiple definitions of symbol vtable for std::bad_alloc
> memory.o definition of vtable for std::bad_allocin section (__DATA,__const)
> /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libsupc++.a(new_handler.o) 
> private external definition of vtable for std::bad_allocin section 
> (__DATA,__const)
> collect2: ld returned 1 exit status
> make[2]: *** [/Users/user/Build/stdcxx/lib/libstd.dylib] Error 1
> make[1]: *** [lib] Error 2
> make: *** [libstd] Error 2

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-356) Remove include path from INCLUDES in GNUmakefile.bin

[Eric Lemings (JIRA)]

Remove include path from INCLUDES in GNUmakefile.bin


 Key: STDCXX-356
 URL: https://issues.apache.org/jira/browse/STDCXX-356
 Project: C++ Standard Library
  Issue Type: Bug
  Components: Build
Affects Versions: 4.1.2, 4.1.3
 Environment: Darwin host.local 8.8.1 Darwin Kernel Version 8.8.1: Mon 
Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386
Reporter: Eric Lemings
 Fix For: 4.2, 4.1.4


The compile flag '-I$(TOPDIR)/include/loc' needs to be removed from INCLUDES in 
the GNUmakefile.bin makefile.  Patch listed below.

Index: etc/config/GNUmakefile.bin
===
--- etc/config/GNUmakefile.bin  (revision 517771)
+++ etc/config/GNUmakefile.bin  (working copy)
@@ -14,7 +14,6 @@
 ONE_REPOSITORY = 1
 include ../makefile.common
 
-INCLUDES += -I$(TOPDIR)/include/loc
 TARGET= exec localedef locale
 
 # locale sources and related 


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-357) [gcc/Mac OS X 10.4.8 Tiger] Some executables need to link with the iconv library.

[Eric Lemings (JIRA)]

[gcc/Mac OS X 10.4.8 Tiger] Some executables need to link with the iconv 
library.
-

 Key: STDCXX-357
 URL: https://issues.apache.org/jira/browse/STDCXX-357
 Project: C++ Standard Library
  Issue Type: Bug
  Components: Build
Affects Versions: 4.1.2, 4.1.3
 Environment: Darwin host.local 8.8.1 Darwin Kernel Version 8.8.1: Mon 
Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386
Reporter: Eric Lemings
 Fix For: 4.2


Some executables (esp. locale-specific utilities) need to link with the iconv 
library.  Patch listed below.  (Don't think it will matter that the link flag 
is given for all link commands.)

Index: etc/config/gcc.config
===
--- etc/config/gcc.config   (revision 517771)
+++ etc/config/gcc.config   (working copy)
@@ -127,7 +129,7 @@
   ifeq ($(OSNAME),Darwin)
 # link with gcc_eh to resolve the _Unwind_xxx functions
 # (shouldn't we link with it on all platforms?)
-LDLIBS += -lgcc_eh
+LDLIBS += -liconv -lgcc_eh
   endif
 endif   # gcc > 2



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-358) [gcc/Mac OS X 10.4.8 Tiger] The unsetenv() function may be defined without a return value.

[Eric Lemings (JIRA)]

[gcc/Mac OS X 10.4.8 Tiger] The unsetenv() function may be defined without a 
return value.
--

 Key: STDCXX-358
 URL: https://issues.apache.org/jira/browse/STDCXX-358
 Project: C++ Standard Library
  Issue Type: Bug
 Environment: Darwin host.local 8.8.1 Darwin Kernel Version 8.8.1: Mon 
Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386
Reporter: Eric Lemings


On Mac OS X/Darwin platforms, the unsetenv() function may be defined without a 
return value depending on the value of the __DARWIN_UNIX03 macro.  Here's the 
declaration of unsetenv() from /usr/include/stdlib.h:

240 #if __DARWIN_UNIX03
241 int  unsetenv(const char *) __DARWIN_ALIAS(unsetenv);
242 #else /* !__DARWIN_UNIX03 */
243 void unsetenv(const char *);
244 #endif /* __DARWIN_UNIX03 */

The __DARWIN_UNIX03 macro is defined in the /usr/include/sys/cdefs.h header 
file.  It may be defined as 1 or 0.  This causes compilation of the 
tests/src/environ.cpp source file to fail.  Here's a patch for it.

Index: tests/src/environ.cpp
===
--- tests/src/environ.cpp   (revision 517771)
+++ tests/src/environ.cpp   (working copy)
@@ -134,7 +134,10 @@
 // try to remove variable from the environment
 
 #ifndef _RWSTD_NO_UNSETENV
-ret = unsetenv (envvar);
+#  if  !defined __DARWIN_UNIX03 || __DARWIN_UNIX03
+ret = 
+#  endif
+unsetenv (envvar);
 #else
 ret = putenv (envvar);
 #endif



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-358) [gcc/Mac OS X 10.4.8 Tiger] The unsetenv() function may be defined without a return value.

[Eric Lemings (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Lemings updated STDCXX-358:


  Component/s: Build
Fix Version/s: 4.2
Affects Version/s: 4.1.3
   4.1.2

Forgot to specify component and versions.

> [gcc/Mac OS X 10.4.8 Tiger] The unsetenv() function may be defined without a 
> return value.
> --
>
> Key: STDCXX-358
> URL: https://issues.apache.org/jira/browse/STDCXX-358
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 4.1.3, 4.1.2
> Environment: Darwin host.local 8.8.1 Darwin Kernel Version 8.8.1: Mon 
> Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386
>Reporter: Eric Lemings
> Fix For: 4.2
>
>
> On Mac OS X/Darwin platforms, the unsetenv() function may be defined without 
> a return value depending on the value of the __DARWIN_UNIX03 macro.  Here's 
> the declaration of unsetenv() from /usr/include/stdlib.h:
> 240 #if __DARWIN_UNIX03
> 241 int  unsetenv(const char *) __DARWIN_ALIAS(unsetenv);
> 242 #else /* !__DARWIN_UNIX03 */
> 243 void unsetenv(const char *);
> 244 #endif /* __DARWIN_UNIX03 */
> The __DARWIN_UNIX03 macro is defined in the /usr/include/sys/cdefs.h header 
> file.  It may be defined as 1 or 0.  This causes compilation of the 
> tests/src/environ.cpp source file to fail.  Here's a patch for it.
> Index: tests/src/environ.cpp
> ===
> --- tests/src/environ.cpp   (revision 517771)
> +++ tests/src/environ.cpp   (working copy)
> @@ -134,7 +134,10 @@
>  // try to remove variable from the environment
>  
>  #ifndef _RWSTD_NO_UNSETENV
> -ret = unsetenv (envvar);
> +#  if  !defined __DARWIN_UNIX03 || __DARWIN_UNIX03
> +ret = 
> +#  endif
> +unsetenv (envvar);
>  #else
>  ret = putenv (envvar);
>  #endif

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-359) [gcc/Mac OS X 10.4.8 Tiger] Can't convert FmtSpec::mod to bool.

[Eric Lemings (JIRA)]

[gcc/Mac OS X 10.4.8 Tiger] Can't convert FmtSpec::mod to bool.
---

 Key: STDCXX-359
 URL: https://issues.apache.org/jira/browse/STDCXX-359
 Project: C++ Standard Library
  Issue Type: Bug
  Components: Build, Tests
Affects Versions: 4.1.2, 4.1.3
Reporter: Eric Lemings
 Fix For: 4.2


The mod data member of the FmtSpec structure is defined in the 
tests/src/fmt_defs.h header file as shown below.

 65 struct FmtSpec
 66 {
 67 // optional flags
 68 unsigned fl_minus  : 1;
...
 73 
 74 // optional length modifier
 75 enum Modifier {
 76 mod_none = 0,
 77 mod_h,   // short modifier
...
 86 mod_ext_I// extension: int as ios::iostate
 87 };
 88 
 89 Modifier mod : 5;

(That may be the first time I've ever seen a bitfield defined in terms of an 
enumeration.  But I digress...)  This member is checked in the 
tests/src/printf.cpp source file as shown here and fails to compile on Darwin 
platforms.

   2885 case 'S':   // %{S}, %{lS}, %{#*S}
   2886 if (   spec.mod == spec.mod_l
   2887 || !spec.mod && spec.fl_pound && sizeof (wchar_t) == 
spec.width) {
   2888 // std::wstring

This should probably be coded as an explicit equality/comparison to the 
Modifier enumerators.  (Also there should probably be parentheses for explicit 
grouping around the logical OR (||) operands and the logical AND (&&} operands. 
 IIRC, the logical AND operator has precedence over the logical OR operator but 
I'm not sure.)  A patch is shown below.

Index: tests/src/printf.cpp
===
--- tests/src/printf.cpp(revision 517771)
+++ tests/src/printf.cpp(working copy)
@@ -2883,8 +2883,8 @@
 break;
 
 case 'S':   // %{S}, %{lS}, %{#*S}
-if (   spec.mod == spec.mod_l
-|| !spec.mod && spec.fl_pound && sizeof (wchar_t) == spec.width) {
+if (   spec.mod == spec.mod_l || spec.mod != FmtSpec::mod_none
+&& spec.fl_pound && sizeof (wchar_t) == spec.width) {
 // std::wstring
 spec.param.ptr_ = PARAM (ptr_, pva);
 


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-359) [gcc/Mac OS X 10.4.8 Tiger] Can't convert FmtSpec::mod to bool.

[Eric Lemings (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Lemings updated STDCXX-359:


Environment: Darwin host.local 8.8.1 Darwin Kernel Version 8.8.1: Mon Sep 
25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386

Forgot to fill in the Environment field.

> [gcc/Mac OS X 10.4.8 Tiger] Can't convert FmtSpec::mod to bool.
> ---
>
> Key: STDCXX-359
> URL: https://issues.apache.org/jira/browse/STDCXX-359
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Build, Tests
>Affects Versions: 4.1.3, 4.1.2
> Environment: Darwin host.local 8.8.1 Darwin Kernel Version 8.8.1: Mon 
> Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386
>Reporter: Eric Lemings
> Fix For: 4.2
>
>
> The mod data member of the FmtSpec structure is defined in the 
> tests/src/fmt_defs.h header file as shown below.
>  65 struct FmtSpec
>  66 {
>  67 // optional flags
>  68 unsigned fl_minus  : 1;
> ...
>  73 
>  74 // optional length modifier
>  75 enum Modifier {
>  76 mod_none = 0,
>  77 mod_h,   // short modifier
> ...
>  86 mod_ext_I// extension: int as ios::iostate
>  87 };
>  88 
>  89 Modifier mod : 5;
> (That may be the first time I've ever seen a bitfield defined in terms of an 
> enumeration.  But I digress...)  This member is checked in the 
> tests/src/printf.cpp source file as shown here and fails to compile on Darwin 
> platforms.
>2885 case 'S':   // %{S}, %{lS}, %{#*S}
>2886 if (   spec.mod == spec.mod_l
>2887 || !spec.mod && spec.fl_pound && sizeof (wchar_t) == 
> spec.width) {
>2888 // std::wstring
> This should probably be coded as an explicit equality/comparison to the 
> Modifier enumerators.  (Also there should probably be parentheses for 
> explicit grouping around the logical OR (||) operands and the logical AND 
> (&&} operands.  IIRC, the logical AND operator has precedence over the 
> logical OR operator but I'm not sure.)  A patch is shown below.
> Index: tests/src/printf.cpp
> ===
> --- tests/src/printf.cpp(revision 517771)
> +++ tests/src/printf.cpp(working copy)
> @@ -2883,8 +2883,8 @@
>  break;
>  
>  case 'S':   // %{S}, %{lS}, %{#*S}
> -if (   spec.mod == spec.mod_l
> -|| !spec.mod && spec.fl_pound && sizeof (wchar_t) == spec.width) 
> {
> +if (   spec.mod == spec.mod_l || spec.mod != FmtSpec::mod_none
> +&& spec.fl_pound && sizeof (wchar_t) == spec.width) {
>  // std::wstring
>  spec.param.ptr_ = PARAM (ptr_, pva);
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (STDCXX-359) [gcc/Mac OS X 10.4.8 Tiger] Can't convert FmtSpec::mod to bool.

[Eric Lemings (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481223
 ] 

Eric Lemings commented on STDCXX-359:
-

It's the gcc-4.2 20070307 snapshot.  It's quite possible GCC developers could 
have made bitfield/boolean/enumeration conversions/promotions more stringent in 
the 4.2 series.

> [gcc/Mac OS X 10.4.8 Tiger] Can't convert FmtSpec::mod to bool.
> ---
>
> Key: STDCXX-359
> URL: https://issues.apache.org/jira/browse/STDCXX-359
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Build, Tests
>Affects Versions: 4.1.3, 4.1.2
> Environment: Darwin host.local 8.8.1 Darwin Kernel Version 8.8.1: Mon 
> Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386
>Reporter: Eric Lemings
> Assigned To: Martin Sebor
> Fix For: 4.2
>
>
> The mod data member of the FmtSpec structure is defined in the 
> tests/src/fmt_defs.h header file as shown below.
>  65 struct FmtSpec
>  66 {
>  67 // optional flags
>  68 unsigned fl_minus  : 1;
> ...
>  73 
>  74 // optional length modifier
>  75 enum Modifier {
>  76 mod_none = 0,
>  77 mod_h,   // short modifier
> ...
>  86 mod_ext_I// extension: int as ios::iostate
>  87 };
>  88 
>  89 Modifier mod : 5;
> (That may be the first time I've ever seen a bitfield defined in terms of an 
> enumeration.  But I digress...)  This member is checked in the 
> tests/src/printf.cpp source file as shown here and fails to compile on Darwin 
> platforms.
>2885 case 'S':   // %{S}, %{lS}, %{#*S}
>2886 if (   spec.mod == spec.mod_l
>2887 || !spec.mod && spec.fl_pound && sizeof (wchar_t) == 
> spec.width) {
>2888 // std::wstring
> This should probably be coded as an explicit equality/comparison to the 
> Modifier enumerators.  (Also there should probably be parentheses for 
> explicit grouping around the logical OR (||) operands and the logical AND 
> (&&} operands.  IIRC, the logical AND operator has precedence over the 
> logical OR operator but I'm not sure.)  A patch is shown below.
> Index: tests/src/printf.cpp
> ===
> --- tests/src/printf.cpp(revision 517771)
> +++ tests/src/printf.cpp(working copy)
> @@ -2883,8 +2883,8 @@
>  break;
>  
>  case 'S':   // %{S}, %{lS}, %{#*S}
> -if (   spec.mod == spec.mod_l
> -|| !spec.mod && spec.fl_pound && sizeof (wchar_t) == spec.width) 
> {
> +if (   spec.mod == spec.mod_l || spec.mod != FmtSpec::mod_none
> +&& spec.fl_pound && sizeof (wchar_t) == spec.width) {
>  // std::wstring
>  spec.param.ptr_ = PARAM (ptr_, pva);
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (STDCXX-359) [gcc/Mac OS X 10.4.8 Tiger] Can't convert FmtSpec::mod to bool.

[Eric Lemings (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481313
 ] 

Eric Lemings commented on STDCXX-359:
-

Well, to be more accurate:

enum E { e };
E v:5;
int main () { if (!v) return 0; } 


> [gcc/Mac OS X 10.4.8 Tiger] Can't convert FmtSpec::mod to bool.
> ---
>
> Key: STDCXX-359
> URL: https://issues.apache.org/jira/browse/STDCXX-359
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Build, Tests
>Affects Versions: 4.1.3, 4.1.2
> Environment: Darwin host.local 8.8.1 Darwin Kernel Version 8.8.1: Mon 
> Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386
>Reporter: Eric Lemings
> Assigned To: Martin Sebor
> Fix For: 4.2
>
>
> The mod data member of the FmtSpec structure is defined in the 
> tests/src/fmt_defs.h header file as shown below.
>  65 struct FmtSpec
>  66 {
>  67 // optional flags
>  68 unsigned fl_minus  : 1;
> ...
>  73 
>  74 // optional length modifier
>  75 enum Modifier {
>  76 mod_none = 0,
>  77 mod_h,   // short modifier
> ...
>  86 mod_ext_I// extension: int as ios::iostate
>  87 };
>  88 
>  89 Modifier mod : 5;
> (That may be the first time I've ever seen a bitfield defined in terms of an 
> enumeration.  But I digress...)  This member is checked in the 
> tests/src/printf.cpp source file as shown here and fails to compile on Darwin 
> platforms.
>2885 case 'S':   // %{S}, %{lS}, %{#*S}
>2886 if (   spec.mod == spec.mod_l
>2887 || !spec.mod && spec.fl_pound && sizeof (wchar_t) == 
> spec.width) {
>2888 // std::wstring
> This should probably be coded as an explicit equality/comparison to the 
> Modifier enumerators.  (Also there should probably be parentheses for 
> explicit grouping around the logical OR (||) operands and the logical AND 
> (&&} operands.  IIRC, the logical AND operator has precedence over the 
> logical OR operator but I'm not sure.)  A patch is shown below.
> Index: tests/src/printf.cpp
> ===
> --- tests/src/printf.cpp(revision 517771)
> +++ tests/src/printf.cpp(working copy)
> @@ -2883,8 +2883,8 @@
>  break;
>  
>  case 'S':   // %{S}, %{lS}, %{#*S}
> -if (   spec.mod == spec.mod_l
> -|| !spec.mod && spec.fl_pound && sizeof (wchar_t) == spec.width) 
> {
> +if (   spec.mod == spec.mod_l || spec.mod != FmtSpec::mod_none
> +&& spec.fl_pound && sizeof (wchar_t) == spec.width) {
>  // std::wstring
>  spec.param.ptr_ = PARAM (ptr_, pva);
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (STDCXX-359) [gcc/Mac OS X 10.4.8 Tiger] Can't convert FmtSpec::mod to bool.

[Eric Lemings (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481315
 ] 

Eric Lemings commented on STDCXX-359:
-

Correction:

enum E { e };
struct S {
  E v:5;
};
S s;
int main() { if (!s.v) return 0; }


> [gcc/Mac OS X 10.4.8 Tiger] Can't convert FmtSpec::mod to bool.
> ---
>
> Key: STDCXX-359
> URL: https://issues.apache.org/jira/browse/STDCXX-359
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Build, Tests
>Affects Versions: 4.1.3, 4.1.2
> Environment: Darwin host.local 8.8.1 Darwin Kernel Version 8.8.1: Mon 
> Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386
>Reporter: Eric Lemings
> Assigned To: Martin Sebor
> Fix For: 4.2
>
>
> The mod data member of the FmtSpec structure is defined in the 
> tests/src/fmt_defs.h header file as shown below.
>  65 struct FmtSpec
>  66 {
>  67 // optional flags
>  68 unsigned fl_minus  : 1;
> ...
>  73 
>  74 // optional length modifier
>  75 enum Modifier {
>  76 mod_none = 0,
>  77 mod_h,   // short modifier
> ...
>  86 mod_ext_I// extension: int as ios::iostate
>  87 };
>  88 
>  89 Modifier mod : 5;
> (That may be the first time I've ever seen a bitfield defined in terms of an 
> enumeration.  But I digress...)  This member is checked in the 
> tests/src/printf.cpp source file as shown here and fails to compile on Darwin 
> platforms.
>2885 case 'S':   // %{S}, %{lS}, %{#*S}
>2886 if (   spec.mod == spec.mod_l
>2887 || !spec.mod && spec.fl_pound && sizeof (wchar_t) == 
> spec.width) {
>2888 // std::wstring
> This should probably be coded as an explicit equality/comparison to the 
> Modifier enumerators.  (Also there should probably be parentheses for 
> explicit grouping around the logical OR (||) operands and the logical AND 
> (&&} operands.  IIRC, the logical AND operator has precedence over the 
> logical OR operator but I'm not sure.)  A patch is shown below.
> Index: tests/src/printf.cpp
> ===
> --- tests/src/printf.cpp(revision 517771)
> +++ tests/src/printf.cpp(working copy)
> @@ -2883,8 +2883,8 @@
>  break;
>  
>  case 'S':   // %{S}, %{lS}, %{#*S}
> -if (   spec.mod == spec.mod_l
> -|| !spec.mod && spec.fl_pound && sizeof (wchar_t) == spec.width) 
> {
> +if (   spec.mod == spec.mod_l || spec.mod != FmtSpec::mod_none
> +&& spec.fl_pound && sizeof (wchar_t) == spec.width) {
>  // std::wstring
>  spec.param.ptr_ = PARAM (ptr_, pva);
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (STDCXX-359) [gcc/Mac OS X 10.4.8 Tiger] Can't convert FmtSpec::mod to bool.

[Eric Lemings (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12481316
 ] 

Eric Lemings commented on STDCXX-359:
-

Confirmed.  GCC 4.1.1 does not have a problem with the bitfield.  GCC 4.2 does.


> [gcc/Mac OS X 10.4.8 Tiger] Can't convert FmtSpec::mod to bool.
> ---
>
> Key: STDCXX-359
> URL: https://issues.apache.org/jira/browse/STDCXX-359
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Build, Tests
>Affects Versions: 4.1.3, 4.1.2
> Environment: Darwin host.local 8.8.1 Darwin Kernel Version 8.8.1: Mon 
> Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386
>Reporter: Eric Lemings
> Assigned To: Martin Sebor
> Fix For: 4.2
>
>
> The mod data member of the FmtSpec structure is defined in the 
> tests/src/fmt_defs.h header file as shown below.
>  65 struct FmtSpec
>  66 {
>  67 // optional flags
>  68 unsigned fl_minus  : 1;
> ...
>  73 
>  74 // optional length modifier
>  75 enum Modifier {
>  76 mod_none = 0,
>  77 mod_h,   // short modifier
> ...
>  86 mod_ext_I// extension: int as ios::iostate
>  87 };
>  88 
>  89 Modifier mod : 5;
> (That may be the first time I've ever seen a bitfield defined in terms of an 
> enumeration.  But I digress...)  This member is checked in the 
> tests/src/printf.cpp source file as shown here and fails to compile on Darwin 
> platforms.
>2885 case 'S':   // %{S}, %{lS}, %{#*S}
>2886 if (   spec.mod == spec.mod_l
>2887 || !spec.mod && spec.fl_pound && sizeof (wchar_t) == 
> spec.width) {
>2888 // std::wstring
> This should probably be coded as an explicit equality/comparison to the 
> Modifier enumerators.  (Also there should probably be parentheses for 
> explicit grouping around the logical OR (||) operands and the logical AND 
> (&&} operands.  IIRC, the logical AND operator has precedence over the 
> logical OR operator but I'm not sure.)  A patch is shown below.
> Index: tests/src/printf.cpp
> ===
> --- tests/src/printf.cpp(revision 517771)
> +++ tests/src/printf.cpp(working copy)
> @@ -2883,8 +2883,8 @@
>  break;
>  
>  case 'S':   // %{S}, %{lS}, %{#*S}
> -if (   spec.mod == spec.mod_l
> -|| !spec.mod && spec.fl_pound && sizeof (wchar_t) == spec.width) 
> {
> +if (   spec.mod == spec.mod_l || spec.mod != FmtSpec::mod_none
> +&& spec.fl_pound && sizeof (wchar_t) == spec.width) {
>  // std::wstring
>  spec.param.ptr_ = PARAM (ptr_, pva);
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (STDCXX-359) [gcc/Mac OS X 10.4.8 Tiger] Can't convert FmtSpec::mod to bool.

[Eric Lemings (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483629
 ] 

Eric Lemings commented on STDCXX-359:
-

FYI.  GCC bug #31273 was opened for this issue.  The GCC maintainers have fixed 
it and are in the process of testing it for 4.2 release.


> [gcc/Mac OS X 10.4.8 Tiger] Can't convert FmtSpec::mod to bool.
> ---
>
> Key: STDCXX-359
> URL: https://issues.apache.org/jira/browse/STDCXX-359
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Build, Tests
>Affects Versions: 4.1.3, 4.1.2
> Environment: Darwin host.local 8.8.1 Darwin Kernel Version 8.8.1: Mon 
> Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386
>Reporter: Eric Lemings
> Assigned To: Martin Sebor
> Fix For: 4.2
>
>
> The mod data member of the FmtSpec structure is defined in the 
> tests/src/fmt_defs.h header file as shown below.
>  65 struct FmtSpec
>  66 {
>  67 // optional flags
>  68 unsigned fl_minus  : 1;
> ...
>  73 
>  74 // optional length modifier
>  75 enum Modifier {
>  76 mod_none = 0,
>  77 mod_h,   // short modifier
> ...
>  86 mod_ext_I// extension: int as ios::iostate
>  87 };
>  88 
>  89 Modifier mod : 5;
> (That may be the first time I've ever seen a bitfield defined in terms of an 
> enumeration.  But I digress...)  This member is checked in the 
> tests/src/printf.cpp source file as shown here and fails to compile on Darwin 
> platforms.
>2885 case 'S':   // %{S}, %{lS}, %{#*S}
>2886 if (   spec.mod == spec.mod_l
>2887 || !spec.mod && spec.fl_pound && sizeof (wchar_t) == 
> spec.width) {
>2888 // std::wstring
> This should probably be coded as an explicit equality/comparison to the 
> Modifier enumerators.  (Also there should probably be parentheses for 
> explicit grouping around the logical OR (||) operands and the logical AND 
> (&&} operands.  IIRC, the logical AND operator has precedence over the 
> logical OR operator but I'm not sure.)  A patch is shown below.
> Index: tests/src/printf.cpp
> ===
> --- tests/src/printf.cpp(revision 517771)
> +++ tests/src/printf.cpp(working copy)
> @@ -2883,8 +2883,8 @@
>  break;
>  
>  case 'S':   // %{S}, %{lS}, %{#*S}
> -if (   spec.mod == spec.mod_l
> -|| !spec.mod && spec.fl_pound && sizeof (wchar_t) == spec.width) 
> {
> +if (   spec.mod == spec.mod_l || spec.mod != FmtSpec::mod_none
> +&& spec.fl_pound && sizeof (wchar_t) == spec.width) {
>  // std::wstring
>  spec.param.ptr_ = PARAM (ptr_, pva);
>  

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-395) Make _RWSTD_WCHAR_T_MIN/MAX names consistent with other *_MIN/MAX names.

[Eric Lemings (JIRA)]

Make _RWSTD_WCHAR_T_MIN/MAX names consistent with other *_MIN/MAX names.


 Key: STDCXX-395
 URL: https://issues.apache.org/jira/browse/STDCXX-395
 Project: C++ Standard Library
  Issue Type: Improvement
  Components: Configuration
Affects Versions: 4.1.3
Reporter: Eric Lemings
Priority: Minor
 Fix For: 4.1.4


There are numerous MIN/MAX variables defined during configuration.

#define _RWSTD_DBL_MAX  1.7976931348623157e+308
#define _RWSTD_FLT_MAX  3.40282347e+38F
#define _RWSTD_LDBL_MAX 1.18973149535723176502e+4932L
#define _RWSTD_BOOL_MAX!0
#define _RWSTD_CHAR_MAX'\x7f'
#define _RWSTD_CHAR_MIN(-_RWSTD_CHAR_MAX - 1)
#define _RWSTD_SCHAR_MAX   0x7f
#define _RWSTD_SCHAR_MIN   (-_RWSTD_SCHAR_MAX - 1)
#define _RWSTD_UCHAR_MAX   0xffU
#define _RWSTD_SHRT_MAX0x7fff
#define _RWSTD_SHRT_MIN(-_RWSTD_SHRT_MAX - 1)
#define _RWSTD_USHRT_MAX   0xU
#define _RWSTD_INT_MAX 0x7fff
#define _RWSTD_INT_MIN (-_RWSTD_INT_MAX - 1)
#define _RWSTD_UINT_MAX0xU
#define _RWSTD_LONG_MAX0x7fffL
#define _RWSTD_LONG_MIN(-_RWSTD_LONG_MAX - 1L)
#define _RWSTD_ULONG_MAX   0xUL
#define _RWSTD_LLONG_MAX   0x7fffLL
#define _RWSTD_LLONG_MIN   (-_RWSTD_LLONG_MAX - 1LL)
#define _RWSTD_ULLONG_MAX  0xULL
#define _RWSTD_WCHAR_T_MAX 0x7fff
#define _RWSTD_WCHAR_T_MIN  (-_RWSTD_WCHAR_T_MAX - 1)
#define _RWSTD_MB_LEN_MAX16   /* libc value */
#define _RWSTD_LC_MAX   _RWSTD_LC_IDENTIFICATION
#define _RWSTD_SIZE_MAX   _RWSTD_ULONG_MAX
#define _RWSTD_PTRDIFF_MAX_RWSTD_LONG_MAX
#define _RWSTD_RAND_MAX   2147483647
#define _RWSTD_FOPEN_MAX  16
#define _RWSTD_FILENAME_MAX   4096
#define _RWSTD_TMP_MAX238328
#define _RWSTD_SIG_ATOMIC_MAX _RWSTD_INT_MAX
#define _RWSTD_WINT_MAX _RWSTD_UINT_MAX

Several of the types covered by these variables use the C naming convention by 
adding "_t" to the type name (e.g. sig_atomic_t, wint_t, ptrdiff_t) but only 
_RWSTD_WCHAR_T_MIN/MAX has this suffix in the variable name itself.  Request 
making this variable name consistent with the others.  (Why?  It makes GNU 
Automake build support that I'm working on much simpler.)


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-396) GNU Release Support

[Eric Lemings (JIRA)]

GNU Release Support
---

 Key: STDCXX-396
 URL: https://issues.apache.org/jira/browse/STDCXX-396
 Project: C++ Standard Library
  Issue Type: New Feature
  Components: Build, Configuration
Affects Versions: 4.1.3
Reporter: Eric Lemings
 Fix For: 4.2


This major feature adds support for GNU maintenance, distribution, and release 
standards <http://www.gnu.org/prep/standards/html_node/Managing-Releases.html> 
as implemented by the GNU Autoconf, Automake, and Libtool software packages.   
Note the operative word here: "adds".  This feature does not replace the 
current configure and build scripts: it only supplements them.  (That is not to 
say it may replace them in some future release however.)

Rogue Wave people can find the latest work on this feature in my "pet projects" 
directory under "stdcxx".  (You know where to look.)  Be aware though: it is 
only about 2/3 complete.  Other interested parties can contact me directly.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (STDCXX-396) GNU Release Support

[Eric Lemings (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497049
 ] 

Eric Lemings commented on STDCXX-396:
-

See also http://issues.apache.org/jira/browse/STDCXX-260.  This issue extends 
issue 260 with full GNU support.

> GNU Release Support
> ---
>
> Key: STDCXX-396
> URL: https://issues.apache.org/jira/browse/STDCXX-396
> Project: C++ Standard Library
>  Issue Type: New Feature
>  Components: Build, Configuration
>Affects Versions: 4.1.3
>Reporter: Eric Lemings
> Fix For: 4.2
>
>
> This major feature adds support for GNU maintenance, distribution, and 
> release standards 
> <http://www.gnu.org/prep/standards/html_node/Managing-Releases.html> as 
> implemented by the GNU Autoconf, Automake, and Libtool software packages.   
> Note the operative word here: "adds".  This feature does not replace the 
> current configure and build scripts: it only supplements them.  (That is not 
> to say it may replace them in some future release however.)
> Rogue Wave people can find the latest work on this feature in my "pet 
> projects" directory under "stdcxx".  (You know where to look.)  Be aware 
> though: it is only about 2/3 complete.  Other interested parties can contact 
> me directly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-420) Configuration scripts should check for standard C++ headers using g++ instead of gcc.

[Eric Lemings (JIRA)]

Configuration scripts should check for standard C++ headers using g++ instead 
of gcc.
-

 Key: STDCXX-420
 URL: https://issues.apache.org/jira/browse/STDCXX-420
 Project: C++ Standard Library
  Issue Type: Bug
  Components: Configuration
Affects Versions: 4.1.3
 Environment: All GCC supported platforms.
Reporter: Eric Lemings
 Fix For: 4.2


Configuration scripts will never find standard C++ headers using gcc.  g++ 
should be used instead.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (STDCXX-420) Configuration scripts should check for standard C++ headers using g++ instead of gcc.

[Eric Lemings (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497058
 ] 

Eric Lemings commented on STDCXX-420:
-

Then how come the headers are not found by the configuration scripts?

"...
checking for   
no (_RWSTD_NO_CASSERT)
..."


> Configuration scripts should check for standard C++ headers using g++ instead 
> of gcc.
> -
>
> Key: STDCXX-420
> URL: https://issues.apache.org/jira/browse/STDCXX-420
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 4.1.3
> Environment: All GCC supported platforms.
>Reporter: Eric Lemings
> Fix For: 4.2
>
>
> Configuration scripts will never find standard C++ headers using gcc.  g++ 
> should be used instead.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (STDCXX-358) [gcc/Mac OS X 10.4.8 Tiger] The unsetenv() function may be defined without a return value.

[Eric Lemings (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497071
 ] 

Eric Lemings commented on STDCXX-358:
-

There is an easier patch for this issue.

$ diff -c tests/src/environ.cpp.0 tests/src/environ.cpp
*** tests/src/environ.cpp.0 Fri May 18 10:53:45 2007
--- tests/src/environ.cpp   Fri May 18 16:29:50 2007
***
*** 134,140 
  // try to remove variable from the environment
  
  #ifndef _RWSTD_NO_UNSETENV
! #  ifdef _RWSTD_OS_FREEBSD
  // FreeBSD declares void unsetenv(const char*)
  // http://www.freebsd.org/cgi/man.cgi?query=unsetenv&sektion=3
  unsetenv (envvar);
--- 134,140 
  // try to remove variable from the environment
  
  #ifndef _RWSTD_NO_UNSETENV
! #  if defined _RWSTD_OS_FREEBSD || defined _RWSTD_OS_DARWIN
  // FreeBSD declares void unsetenv(const char*)
  // http://www.freebsd.org/cgi/man.cgi?query=unsetenv&sektion=3
  unsetenv (envvar);

Also this is the last issue for porting STDCXX to Mac OS X platforms.  Once 
resolved (along with issue 357), STDCXX builds and runs fine on Mac OS X.  It 
does however require GCC 4.2 or later version.  It will not build with the 
system GCC compiler (4.0.1).


> [gcc/Mac OS X 10.4.8 Tiger] The unsetenv() function may be defined without a 
> return value.
> --
>
> Key: STDCXX-358
> URL: https://issues.apache.org/jira/browse/STDCXX-358
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 4.1.3, 4.1.2
> Environment: Darwin host.local 8.8.1 Darwin Kernel Version 8.8.1: Mon 
> Sep 25 19:42:00 PDT 2006; root:xnu-792.13.8.obj~1/RELEASE_I386 i386 i386
>Reporter: Eric Lemings
> Fix For: 4.2
>
>
> On Mac OS X/Darwin platforms, the unsetenv() function may be defined without 
> a return value depending on the value of the __DARWIN_UNIX03 macro.  Here's 
> the declaration of unsetenv() from /usr/include/stdlib.h:
> 240 #if __DARWIN_UNIX03
> 241 int  unsetenv(const char *) __DARWIN_ALIAS(unsetenv);
> 242 #else /* !__DARWIN_UNIX03 */
> 243 void unsetenv(const char *);
> 244 #endif /* __DARWIN_UNIX03 */
> The __DARWIN_UNIX03 macro is defined in the /usr/include/sys/cdefs.h header 
> file.  It may be defined as 1 or 0.  This causes compilation of the 
> tests/src/environ.cpp source file to fail.  Here's a patch for it.
> Index: tests/src/environ.cpp
> ===
> --- tests/src/environ.cpp   (revision 517771)
> +++ tests/src/environ.cpp   (working copy)
> @@ -134,7 +134,10 @@
>  // try to remove variable from the environment
>  
>  #ifndef _RWSTD_NO_UNSETENV
> -ret = unsetenv (envvar);
> +#  if  !defined __DARWIN_UNIX03 || __DARWIN_UNIX03
> +ret = 
> +#  endif
> +unsetenv (envvar);
>  #else
>  ret = putenv (envvar);
>  #endif

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-440) 23_allocator test case can consume all system memory

[Eric Lemings (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Lemings updated STDCXX-440:


Attachment: sample-top.txt

This is the output of the 'top' command from the most recent instance where 
this behavior was observed.

> 23_allocator test case can consume all system memory
> 
>
> Key: STDCXX-440
> URL: https://issues.apache.org/jira/browse/STDCXX-440
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 4.2
> Environment: RHAP 5 (possibly others)
>Reporter: Eric Lemings
>Priority: Critical
> Fix For: 4.2
>
> Attachments: sample-top.txt
>
>
> The 22_allocator test case has been observed to consume all primary and 
> virtual memory bringing the unfortunate system to its knees.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-440) 23_allocator test case can consume all system memory

[Eric Lemings (JIRA)]

23_allocator test case can consume all system memory


 Key: STDCXX-440
 URL: https://issues.apache.org/jira/browse/STDCXX-440
 Project: C++ Standard Library
  Issue Type: Bug
  Components: Tests
Affects Versions: 4.2
 Environment: RHAP 5 (possibly others)
Reporter: Eric Lemings
Priority: Critical
 Fix For: 4.2


The 22_allocator test case has been observed to consume all primary and virtual 
memory bringing the unfortunate system to its knees.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (STDCXX-404) [FreeBSD 6.2] error on in locale utilities

[Eric Lemings (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512594
 ] 

Eric Lemings commented on STDCXX-404:
-

The same error occurs when building STDCXX on Mac OS X 10.4.10 (Tiger) with GCC 
4.2.

...
gcc runall.o cmdopt.o output.o util.o exec.o display.o -o exec -L/stdcxx/lib 
-lstd -lsupc++ -lgcc_eh -lm

gcc -c -I/stdcxx/include/ansi -D_RWSTDDEBUG-I/stdcxx/include 
-I/stdcxx/include  -pedantic -nostdinc++ -g  -W -Wall -Wcast-qual -Winline 
-Wshadow -Wwrite-strings -Wno-long-long -Wcast-align /stdcxx/util/localedef.cpp
In file included from
/stdcxx/util/def.h:45,
 from
/stdcxx/util/localedef.cpp:30:
/stdcxx/util/charmap.h:167: error: 'iconv_t' does not name a type
/stdcxx/util/charmap.h:230: error: 'iconv_t' does not name a type
/stdcxx/util/charmap.h:233: error: 'iconv_t' does not name a type
/stdcxx/util/localedef.cpp: In function 'bool 
process_command_line(ProgramOptions*, int, char**)':
/stdcxx/util/localedef.cpp:475: warning:
unused variable 'errors'
make[2]: *** [localedef.o] Error 1
make[1]: *** [util] Error 2
make: *** [libstd] Error 2


> [FreeBSD 6.2] error on  in locale utilities
> 
>
> Key: STDCXX-404
> URL: https://issues.apache.org/jira/browse/STDCXX-404
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 4.2
> Environment: gcc 3.4.6/FreeBSD/x86
>Reporter: Martin Sebor
>Priority: Critical
> Fix For: 4.2
>
>
> The locale utilities locale and localedef fail to build on FreeBSD due to 
> assumptions about the  header which apparently isn't provided on 
> this platform:
> gcc -c -I$(TOPDIR)/include/ansi -D_RWSTDDEBUG-I$(TOPDIR)/include 
> -I$(BUILDDIR)/include  -pedantic -nostdinc++ -g  -W -Wall -Wcast-qual 
> -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align   
> $(TOPDIR)/util/localedef.cpp
> In file included from $(TOPDIR)/util/def.h:45,
>  from $(TOPDIR)/util/localedef.cpp:30:
> $(TOPDIR)/util/charmap.h:39:21: iconv.h: No such file or directory
> In file included from $(TOPDIR)/util/def.h:45,
>  from $(TOPDIR)/util/localedef.cpp:30:
> $(TOPDIR)/util/charmap.h:165: error: `iconv_t' does not name a type
> $(TOPDIR)/util/charmap.h:165: error: extra semicolon
> $(TOPDIR)/util/charmap.h:228: error: `iconv_t' does not name a type
> $(TOPDIR)/util/charmap.h:228: error: extra semicolon
> $(TOPDIR)/util/charmap.h:231: error: `iconv_t' does not name a type
> $(TOPDIR)/util/charmap.h:231: error: extra semicolon
> $(TOPDIR)/util/localedef.cpp: In function `bool 
> process_command_line(ProgramOptions*, int, char**)':
> $(TOPDIR)/util/localedef.cpp:475: warning: unused variable 'errors'
> gmake: *** [localedef.o] Error 1

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-404) [FreeBSD 6.2] error on in locale utilities

[Eric Lemings (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Lemings updated STDCXX-404:


Environment: 
gcc 3.4.6/FreeBSD/x86
gcc 4.2/Mac OS X 10.4.10 (Tiger)

  was:gcc 3.4.6/FreeBSD/x86


> [FreeBSD 6.2] error on  in locale utilities
> 
>
> Key: STDCXX-404
> URL: https://issues.apache.org/jira/browse/STDCXX-404
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Utilities
>Affects Versions: 4.2
> Environment: gcc 3.4.6/FreeBSD/x86
> gcc 4.2/Mac OS X 10.4.10 (Tiger)
>Reporter: Martin Sebor
>Priority: Critical
> Fix For: 4.2
>
>
> The locale utilities locale and localedef fail to build on FreeBSD due to 
> assumptions about the  header which apparently isn't provided on 
> this platform:
> gcc -c -I$(TOPDIR)/include/ansi -D_RWSTDDEBUG-I$(TOPDIR)/include 
> -I$(BUILDDIR)/include  -pedantic -nostdinc++ -g  -W -Wall -Wcast-qual 
> -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align   
> $(TOPDIR)/util/localedef.cpp
> In file included from $(TOPDIR)/util/def.h:45,
>  from $(TOPDIR)/util/localedef.cpp:30:
> $(TOPDIR)/util/charmap.h:39:21: iconv.h: No such file or directory
> In file included from $(TOPDIR)/util/def.h:45,
>  from $(TOPDIR)/util/localedef.cpp:30:
> $(TOPDIR)/util/charmap.h:165: error: `iconv_t' does not name a type
> $(TOPDIR)/util/charmap.h:165: error: extra semicolon
> $(TOPDIR)/util/charmap.h:228: error: `iconv_t' does not name a type
> $(TOPDIR)/util/charmap.h:228: error: extra semicolon
> $(TOPDIR)/util/charmap.h:231: error: `iconv_t' does not name a type
> $(TOPDIR)/util/charmap.h:231: error: extra semicolon
> $(TOPDIR)/util/localedef.cpp: In function `bool 
> process_command_line(ProgramOptions*, int, char**)':
> $(TOPDIR)/util/localedef.cpp:475: warning: unused variable 'errors'
> gmake: *** [localedef.o] Error 1

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-516) Rename generate.bat as configure.bat.

[Eric Lemings (JIRA)]

Rename generate.bat as configure.bat.
-

 Key: STDCXX-516
 URL: https://issues.apache.org/jira/browse/STDCXX-516
 Project: C++ Standard Library
  Issue Type: Improvement
Affects Versions: 4.2
 Environment: All Microsoft Windows platforms
Reporter: Eric Lemings
Priority: Minor
 Fix For: 4.2


The generate.bat script does exactly the same thing that conventional 
'configure' scripts do on Unix platforms: it configures the build environment 
and generates the necessary build files.  Therefore, the filename 
'configure.bat' would more easily identify the purpose of this file to users 
accustomed to its Unix counterpart.  This filename will not interfere with a 
'configure' script if such a script is added later on.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-517) No required options for generate.bat script

[Eric Lemings (JIRA)]

No required options for generate.bat script
---

 Key: STDCXX-517
 URL: https://issues.apache.org/jira/browse/STDCXX-517
 Project: C++ Standard Library
  Issue Type: Improvement
Affects Versions: 4.2
 Environment: All Windows platforms
Reporter: Eric Lemings
 Fix For: 4.1.2


The generate.bat script currently requires two options: /BUILDDIR and /CONFIG.  
Unless there's a valid reason NOT to do so, the generate.bat script should 
preset or determine the following values for these options when the user does 
not specify their own value.  /BUILDDIR should default to the source directory; 
that is, the same directory containing the generate.bat script.  For the 
/CONFIG option, the script should probe the build environment for all 
possible/supported Windows compilers currently installed and then sanity check 
each one that is found.  If it finds no sane compilers, the script should 
probably issue a warning and just exit.  If only one compiler is found, 
configure all distribution files to build with that compiler.  If more than one 
compiler is found, set the target compiler to the first one found in predefined 
order of preference.  (This order could be for instance, MSVC 8, 7, ..., Intel 
C++ 10, 9, 8, etc, Cygwin GCC, Mingw, Borland, etc.)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (STDCXX-517) No required options for generate.bat script

[Eric Lemings (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518911
 ] 

Eric Lemings commented on STDCXX-517:
-

> BUILDDIR should default to the source directory; that is, the same directory 
> containing the generate.bat script.

...or the current directory if this directory is different from the directory 
where the generate.bat script is located.


> No required options for generate.bat script
> ---
>
> Key: STDCXX-517
> URL: https://issues.apache.org/jira/browse/STDCXX-517
> Project: C++ Standard Library
>  Issue Type: Improvement
>Affects Versions: 4.2
> Environment: All Windows platforms
>Reporter: Eric Lemings
> Fix For: 4.1.2
>
>
> The generate.bat script currently requires two options: /BUILDDIR and 
> /CONFIG.  Unless there's a valid reason NOT to do so, the generate.bat script 
> should preset or determine the following values for these options when the 
> user does not specify their own value.  /BUILDDIR should default to the 
> source directory; that is, the same directory containing the generate.bat 
> script.  For the /CONFIG option, the script should probe the build 
> environment for all possible/supported Windows compilers currently installed 
> and then sanity check each one that is found.  If it finds no sane compilers, 
> the script should probably issue a warning and just exit.  If only one 
> compiler is found, configure all distribution files to build with that 
> compiler.  If more than one compiler is found, set the target compiler to the 
> first one found in predefined order of preference.  (This order could be for 
> instance, MSVC 8, 7, ..., Intel C++ 10, 9, 8, etc, Cygwin GCC, Mingw, 
> Borland, etc.)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-260) configure-like script to configure library

[Eric Lemings (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Lemings updated STDCXX-260:


Attachment: configure.out

For ease of reference, the attached file contains the help/usage message 
produced by a simple configure script.

> configure-like script to configure library
> --
>
> Key: STDCXX-260
> URL: https://issues.apache.org/jira/browse/STDCXX-260
> Project: C++ Standard Library
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 4.1.3, 4.1.2
> Environment: UNIX
>Reporter: Martin Sebor
>Assignee: Martin Sebor
>Priority: Critical
> Attachments: configure.out
>
>
> To make the configuration and build process more user-friendly we should 
> provide a configure-like script (as a wrapper around the existing 
> GNUmakefiles) to let users familiar with autoconf-based projects more quickly 
> configure, build, and install the library (including its headers). The script 
> should recognize and interpret the most common options such as --prefix=,  
> --enable-shared, --enable-threads, etc. by translating them to the existing 
> infrastructure's equivalents (e.g., BUILDMODE or BUILDTYPE).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (STDCXX-505) Update the Acknowledgments page

[Eric Lemings (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521836
 ] 

Eric Lemings commented on STDCXX-505:
-

It might be worthwhile to convert this information into plain text and put it 
in a top-level distribution file named 'AUTHORS' just for compatibility with 
GNU release standards.  (I did not see anything that dictates otherwise in the 
Apache release policies <http://www.apache.org/dev/#releases>.)

> Update the Acknowledgments page
> ---
>
> Key: STDCXX-505
> URL: https://issues.apache.org/jira/browse/STDCXX-505
> Project: C++ Standard Library
>  Issue Type: Sub-task
>  Components: Documentation
>Affects Versions: 4.1.4, 4.1.3, 4.1.2
>Reporter: Marc Betz
> Fix For: 4.2
>
> Attachments: acknow.html
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (STDCXX-505) Update the Acknowledgments page

[Eric Lemings (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521836
 ] 

elemings edited comment on STDCXX-505 at 8/22/07 8:58 AM:
--

It might be worthwhile to convert this information into plain text and put it 
in a top-level distribution file named 'AUTHORS' just for compatibility with 
GNU release standards.  (I did not see anything that dictates otherwise in the 
Apache release policies < http://www.apache.org/dev/#releases >.)

  was (Author: elemings):
It might be worthwhile to convert this information into plain text and put 
it in a top-level distribution file named 'AUTHORS' just for compatibility with 
GNU release standards.  (I did not see anything that dictates otherwise in the 
Apache release policies .)
  
> Update the Acknowledgments page
> ---
>
> Key: STDCXX-505
> URL: https://issues.apache.org/jira/browse/STDCXX-505
> Project: C++ Standard Library
>  Issue Type: Sub-task
>  Components: Documentation
>Affects Versions: 4.1.4, 4.1.3, 4.1.2
>Reporter: Marc Betz
> Fix For: 4.2
>
> Attachments: acknow.html
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (STDCXX-505) Update the Acknowledgments page

[Eric Lemings (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521836
 ] 

elemings edited comment on STDCXX-505 at 8/22/07 8:59 AM:
--

It might be worthwhile to convert this information into plain text and put it 
in a top-level distribution file named 'AUTHORS' just for compatibility with 
GNU release standards.  (I did not see anything that dictates otherwise in the 
Apache release policies http://www.apache.org/dev/#releases.)

  was (Author: elemings):
It might be worthwhile to convert this information into plain text and put 
it in a top-level distribution file named 'AUTHORS' just for compatibility with 
GNU release standards.  (I did not see anything that dictates otherwise in the 
Apache release policies < http://www.apache.org/dev/#releases >.)
  
> Update the Acknowledgments page
> ---
>
> Key: STDCXX-505
> URL: https://issues.apache.org/jira/browse/STDCXX-505
> Project: C++ Standard Library
>  Issue Type: Sub-task
>  Components: Documentation
>Affects Versions: 4.1.4, 4.1.3, 4.1.2
>Reporter: Marc Betz
> Fix For: 4.2
>
> Attachments: acknow.html
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (STDCXX-505) Update the Acknowledgments page

[Eric Lemings (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12521836
 ] 

elemings edited comment on STDCXX-505 at 8/22/07 8:59 AM:
--

It might be worthwhile to convert this information into plain text and put it 
in a top-level distribution file named 'AUTHORS' just for compatibility with 
GNU release standards.  (I did not see anything that dictates otherwise in the 
Apache release policies http://www.apache.org/dev/#releases .)

  was (Author: elemings):
It might be worthwhile to convert this information into plain text and put 
it in a top-level distribution file named 'AUTHORS' just for compatibility with 
GNU release standards.  (I did not see anything that dictates otherwise in the 
Apache release policies http://www.apache.org/dev/#releases.)
  
> Update the Acknowledgments page
> ---
>
> Key: STDCXX-505
> URL: https://issues.apache.org/jira/browse/STDCXX-505
> Project: C++ Standard Library
>  Issue Type: Sub-task
>  Components: Documentation
>Affects Versions: 4.1.4, 4.1.3, 4.1.2
>Reporter: Marc Betz
> Fix For: 4.2
>
> Attachments: acknow.html
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-396) GNU Release Support

[Eric Lemings (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Lemings updated STDCXX-396:


Fix Version/s: 5.0
 Priority: Major  (was: Minor)

I'm going to finish this before 5.0 is released.

> GNU Release Support
> ---
>
> Key: STDCXX-396
> URL: https://issues.apache.org/jira/browse/STDCXX-396
> Project: C++ Standard Library
>  Issue Type: New Feature
>  Components: Build, Configuration
>Affects Versions: 4.1.3
>Reporter: Eric Lemings
> Fix For: 5.0
>
>
> This major feature adds support for GNU maintenance, distribution, and 
> release standards 
> <http://www.gnu.org/prep/standards/html_node/Managing-Releases.html> as 
> implemented by the GNU Autoconf, Automake, and Libtool software packages.   
> Note the operative word here: "adds".  This feature does not replace the 
> current configure and build scripts: it only supplements them.  (That is not 
> to say it may replace them in some future release however.)
> Rogue Wave people can find the latest work on this feature in my "pet 
> projects" directory under "stdcxx".  (You know where to look.)  Be aware 
> though: it is only about 2/3 complete.  Other interested parties can contact 
> me directly.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Issue Comment Edited: (STDCXX-260) configure-like script to configure library

[Eric Lemings (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519750
 ] 

elemings edited comment on STDCXX-260 at 8/28/07 11:27 AM:
---

For ease of reference, the attached file contains the help/usage message 
produced by a simple configure script.

Also, http://issues.apache.org/jira/browse/STDCXX-396 will resolve this issue.


  was (Author: elemings):
For ease of reference, the attached file contains the help/usage message 
produced by a simple configure script.
  
> configure-like script to configure library
> --
>
> Key: STDCXX-260
> URL: https://issues.apache.org/jira/browse/STDCXX-260
> Project: C++ Standard Library
>  Issue Type: New Feature
>  Components: Configuration
>Affects Versions: 4.1.2, 4.1.3
> Environment: UNIX
>Reporter: Martin Sebor
>Assignee: Martin Sebor
>Priority: Critical
> Attachments: configure.out
>
>
> To make the configuration and build process more user-friendly we should 
> provide a configure-like script (as a wrapper around the existing 
> GNUmakefiles) to let users familiar with autoconf-based projects more quickly 
> configure, build, and install the library (including its headers). The script 
> should recognize and interpret the most common options such as --prefix=,  
> --enable-shared, --enable-threads, etc. by translating them to the existing 
> infrastructure's equivalents (e.g., BUILDMODE or BUILDTYPE).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-516) Rename generate.bat as configure.bat.

[Eric Lemings (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Lemings updated STDCXX-516:


Component/s: Configuration

> Rename generate.bat as configure.bat.
> -
>
> Key: STDCXX-516
> URL: https://issues.apache.org/jira/browse/STDCXX-516
> Project: C++ Standard Library
>  Issue Type: Improvement
>  Components: Configuration
>Affects Versions: 4.1.3
> Environment: All Microsoft Windows platforms
>    Reporter: Eric Lemings
>Assignee: Farid Zaripov
>Priority: Minor
> Fix For: 4.2
>
>
> The generate.bat script does exactly the same thing that conventional 
> 'configure' scripts do on Unix platforms: it configures the build environment 
> and generates the necessary build files.  Therefore, the filename 
> 'configure.bat' would more easily identify the purpose of this file to users 
> accustomed to its Unix counterpart.  This filename will not interfere with a 
> 'configure' script if such a script is added later on.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-506) Improve the look and feel

[Eric Lemings (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Lemings updated STDCXX-506:


Component/s: Documentation

> Improve the look and feel
> -
>
> Key: STDCXX-506
> URL: https://issues.apache.org/jira/browse/STDCXX-506
> Project: C++ Standard Library
>  Issue Type: Sub-task
>  Components: Documentation
>Reporter: Marc Betz
> Attachments: apache-look-and-feel.zip
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-517) No required options for generate.bat script

[Eric Lemings (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Lemings updated STDCXX-517:


Component/s: Configuration

> No required options for generate.bat script
> ---
>
> Key: STDCXX-517
> URL: https://issues.apache.org/jira/browse/STDCXX-517
> Project: C++ Standard Library
>  Issue Type: Improvement
>  Components: Configuration
>Affects Versions: 4.1.3
> Environment: All Windows platforms
>    Reporter: Eric Lemings
>Assignee: Farid Zaripov
> Fix For: 4.2
>
>
> The generate.bat script currently requires two options: /BUILDDIR and 
> /CONFIG.  Unless there's a valid reason NOT to do so, the generate.bat script 
> should preset or determine the following values for these options when the 
> user does not specify their own value.  /BUILDDIR should default to the 
> source directory; that is, the same directory containing the generate.bat 
> script.  For the /CONFIG option, the script should probe the build 
> environment for all possible/supported Windows compilers currently installed 
> and then sanity check each one that is found.  If it finds no sane compilers, 
> the script should probably issue a warning and just exit.  If only one 
> compiler is found, configure all distribution files to build with that 
> compiler.  If more than one compiler is found, set the target compiler to the 
> first one found in predefined order of preference.  (This order could be for 
> instance, MSVC 8, 7, ..., Intel C++ 10, 9, 8, etc, Cygwin GCC, Mingw, 
> Borland, etc.)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-546) Create new mailing list specifically for JIRA change logs.

[Eric Lemings (JIRA)]

Create new mailing list specifically for JIRA change logs.
--

 Key: STDCXX-546
 URL: https://issues.apache.org/jira/browse/STDCXX-546
 Project: C++ Standard Library
  Issue Type: Improvement
  Components: Web
Reporter: Eric Lemings
Priority: Minor


Currently, change logs created by creating, editing, and updating JIRA issues 
are sent to the stdcxx-dev mailing list.  Suggest creating a new stdcxx-jira 
mailing list specifically for these messages.  (Not sure if Subversion change 
logs are automatically sent to a mailing list but, if they are, a separate 
stdcxx-svn mailing list should also be created for these messages.)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-557) Make definitions of std::terminate() consistent in all config test sources.

[Eric Lemings (JIRA)]

Make definitions of std::terminate() consistent in all config test sources.
---

 Key: STDCXX-557
 URL: https://issues.apache.org/jira/browse/STDCXX-557
 Project: C++ Standard Library
  Issue Type: Improvement
Reporter: Eric Lemings
Priority: Minor
 Fix For: 4.2.1


Many of the source files for the config tests (in etc/config/src directory) 
contain inconsistent definitions for the std::terminate() function.  Suggest 
making them all consistent, ideally by creating a new file with a single 
definition that is included where needed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-558) Remove unnecessary includes of "config.h" in source files for config tests

[Eric Lemings (JIRA)]

Remove unnecessary includes of "config.h" in source files for config tests
--

 Key: STDCXX-558
 URL: https://issues.apache.org/jira/browse/STDCXX-558
 Project: C++ Standard Library
  Issue Type: Improvement
  Components: Configuration
Reporter: Eric Lemings
 Fix For: 4.2.1


Several config tests in the etc/config/src directory unnecessarily include the 
"config.h" header.  Need to review each source file that includes this header 
and remove the directive if it is not really needed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-557) Make definitions of std::terminate() consistent in all config test sources.

[Eric Lemings (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Lemings updated STDCXX-557:


Component/s: Configuration

> Make definitions of std::terminate() consistent in all config test sources.
> ---
>
> Key: STDCXX-557
> URL: https://issues.apache.org/jira/browse/STDCXX-557
> Project: C++ Standard Library
>  Issue Type: Improvement
>  Components: Configuration
>    Reporter: Eric Lemings
>Priority: Minor
> Fix For: 4.2.1
>
>
> Many of the source files for the config tests (in etc/config/src directory) 
> contain inconsistent definitions for the std::terminate() function.  Suggest 
> making them all consistent, ideally by creating a new file with a single 
> definition that is included where needed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-558) Remove unnecessary includes of "config.h" in source files for config tests

[Eric Lemings (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Eric Lemings updated STDCXX-558:


Priority: Minor  (was: Major)

> Remove unnecessary includes of "config.h" in source files for config tests
> --
>
> Key: STDCXX-558
> URL: https://issues.apache.org/jira/browse/STDCXX-558
> Project: C++ Standard Library
>  Issue Type: Improvement
>  Components: Configuration
>Reporter: Eric Lemings
>Priority: Minor
> Fix For: 4.2.1
>
>
> Several config tests in the etc/config/src directory unnecessarily include 
> the "config.h" header.  Need to review each source file that includes this 
> header and remove the directive if it is not really needed.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (STDCXX-505) Update the Acknowledgments page

[Eric Lemings (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532520
 ] 

Eric Lemings commented on STDCXX-505:
-

The AUTHORS file is dictated by the --gnu option in GNU Automake.

http://sources.redhat.com/automake/automake.html#Gnits

GNU Automake extends the GNU Coding Standards with release, distribution, and 
maintenance conventions.


> Update the Acknowledgments page
> ---
>
> Key: STDCXX-505
> URL: https://issues.apache.org/jira/browse/STDCXX-505
> Project: C++ Standard Library
>  Issue Type: Sub-task
>  Components: Documentation
>Affects Versions: 4.1.2, 4.1.3, 4.1.4
>Reporter: Marc Betz
>Assignee: Marc Betz
> Fix For: 4.2
>
> Attachments: stdlibref-acknow.txt, stdlibug-acknow.txt
>
>


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (STDCXX-262) [gcc 4.0.1/Mac OS X 10.4.6 Tiger] multiple vtable definitions for bad_exception and bad_alloc

[Eric Lemings (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12534366
 ] 

Eric Lemings commented on STDCXX-262:
-

I just did a build on the latest snapshot of trunk.  Looks okay.

> [gcc 4.0.1/Mac OS X 10.4.6 Tiger] multiple vtable definitions for 
> bad_exception and bad_alloc
> -
>
> Key: STDCXX-262
> URL: https://issues.apache.org/jira/browse/STDCXX-262
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 4.1.3
> Environment: Darwin machine.local 8.7.1 Darwin Kernel Version 8.7.1: 
> Wed Jun  7 16:19:56 PDT 2006; root:xnu-792.9.72.obj~2/RELEASE_I386 i386 i386
>Reporter: Eric Lemings
>Assignee: Martin Sebor
>Priority: Critical
> Fix For: 4.2
>
> Attachments: stdcxx-262.patch
>
>
> machine:~/Work user$ svn co 
> http://svn.apache.org/repos/asf/incubator/stdcxx/trunk stdcxx
> Astdcxx/generate.bat
> Astdcxx/LICENSE.txt
> Astdcxx/tests
> Astdcxx/tests/tr1.util
> ...
> Astdcxx/examples/manual/time_put.cpp
> Astdcxx/examples/manual/moneyget.cpp
> Astdcxx/examples/manual/except.cpp
> Astdcxx/examples/manual/memfunc.cpp
> Checked out revision 423638.
> machine:~/Work user$ cd stdcxx
> machine:~/Work/stdcxx user$ make BUILDDIR="~/Build" 
> BUILDMODE="debug,shared,pthreads"
> creating BUILDDIR=/Users/user/Build/stdcxx
> generating /Users/user/Build/stdcxx/makefile.in from 
> /Users/user/Work/stdcxx/etc/config/gcc.config
> make config
> configuring for gcc-4.0.1 on darwin-8.7.1-i386
> checking if the compiler is sane   ok (invoked with gcc)
> checking if the linker is sane ok (invoked with gcc)
> checking system architecture   ILP32 little endian
> ...
> gcc -c -I/Users/user/Work/stdcxx/include/ansi -D_RWSTDDEBUG
> -D_RWSTD_USE_CONFIG -I/Users/user/Work/stdcxx/include 
> -I/Users/user/Build/stdcxx/include  -pedantic -nostdinc++ -g  -W -Wall 
> -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align  
> -fPIC /Users/user/Work/stdcxx/src/wctype.cpp
> gcc  assert.o atomic-cxx.o bitset.o catalog.o codecvt.o collate.o ctype.o 
> ctype_bits.o exception.o export.o facet.o file.o instance.o ios.o ios_bits.o 
> iostore.o iostream.o iso2022.o limits.o limits_bits.o locale_bits.o 
> locale_body.o locale_classic.o locale_combine.o locale_core.o locale_eq.o 
> locale_global.o locale_name.o memattr.o memory.o messages.o num_get.o 
> num_put.o punct.o random.o setlocale.o string.o strstream.o strtol.o 
> ti_collate.o ti_filebuf.o ti_insert_dbl.o ti_insert_int.o ti_insert_ptr.o 
> ti_ios.o ti_istream.o ti_messages.o ti_money_get.o ti_money_put.o 
> ti_moneypunct.o ti_num_get.o ti_num_put.o ti_numpunct.o ti_ostream.o 
> ti_streambuf.o ti_string.o ti_stringbuf.o ti_time_get.o ti_time_put.o 
> ti_wcollate.o ti_wfilebuf.o ti_winsert_dbl.o ti_winsert_int.o 
> ti_winsert_ptr.o ti_wios.o ti_wistream.o ti_wmessages.o ti_wmoney_get.o 
> ti_wmoney_put.o ti_wmoneypunct.o ti_wnum_get.o ti_wnum_put.o ti_wnumpunct.o 
> ti_wostream.o ti_wstreambuf.o ti_wstring.o ti_wstringbuf.o ti_wtime_get.o 
> ti_wtime_put.o time_get.o time_put.o tmpbuf.o typeinfo.o valarray.o vecbool.o 
> version.o wcodecvt.o wctype.o -lsupc++ -lgcc_eh -o 
> /Users/user/Build/stdcxx/lib/libstd.dylib.4.2.0 
> /usr/bin/ld: multiple definitions of symbol vtable for std::bad_exception
> exception.o definition of vtable for std::bad_exceptionin section 
> (__DATA,__const)
> /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libsupc++.a(eh_exception.o) 
> private external definition of vtable for std::bad_exceptionin section 
> (__DATA,__const)
> /usr/bin/ld: multiple definitions of symbol vtable for std::bad_alloc
> memory.o definition of vtable for std::bad_allocin section (__DATA,__const)
> /usr/lib/gcc/i686-apple-darwin8/4.0.1/../../../libsupc++.a(new_handler.o) 
> private external definition of vtable for std::bad_allocin section 
> (__DATA,__const)
> collect2: ld returned 1 exit status
> make[2]: *** [/Users/user/Build/stdcxx/lib/libstd.dylib] Error 1
> make[1]: *** [lib] Error 2
> make: *** [libstd] Error 2

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.