Re: svn commit: r638382 - in /stdcxx/trunk: include/fstream include/istream src/podarray.h
[EMAIL PROTECTED] wrote:
Author: faridz
Date: Tue Mar 18 07:22:15 2008
New Revision: 638382
Just out of curiosity: are these warnings new in MSVC 9? (I don't
think they show up in MSVC 8 builds.)
Martin
URL: http://svn.apache.org/viewvc?rev=638382view=rev
Log:
2008-03-18 Farid Zaripov [EMAIL PROTECTED]
STDCXX-648
* include/fstream: Change 'class' keyword to 'struct' to hide MSVC
warning C4099:
'std::ios_base::Init' : type name first seen using 'struct' now seen
using 'class'.
* include/istream [_RWSTD_NO_EXT_NUM_GET] (__rw_extract(istream, short
)):
New overload, implemented thus__rw_extractlong.
[_RWSTD_NO_EXT_NUM_GET] (__rw_extract(istream, int )):
New overload, implemented thus__rw_extractlong.
* src/podarray.h (_C_length): Use inplace algorithm instead of
char_traits::length when _RWSTD_NO_EXT_CHAR_TRAITS_PRIMARY macro is
#defined.
Modified:
stdcxx/trunk/include/fstream
stdcxx/trunk/include/istream
stdcxx/trunk/src/podarray.h
Modified: stdcxx/trunk/include/fstream
URL:
http://svn.apache.org/viewvc/stdcxx/trunk/include/fstream?rev=638382r1=638381r2=638382view=diff
==
--- stdcxx/trunk/include/fstream (original)
+++ stdcxx/trunk/include/fstream Tue Mar 18 07:22:15 2008
@@ -121,7 +121,7 @@
private:
// g++ 2.95 error: `std::ios_base::Init' does not declare a template type
-friend class ios_base::Init;
+friend struct ios_base::Init;
#endif // _RWSTD_NO_EXT_FILEBUF !_RWSTD_NO_STATIC_IOSTREAM_INIT
Modified: stdcxx/trunk/include/istream
URL:
http://svn.apache.org/viewvc/stdcxx/trunk/include/istream?rev=638382r1=638381r2=638382view=diff
==
--- stdcxx/trunk/include/istream (original)
+++ stdcxx/trunk/include/istream Tue Mar 18 07:22:15 2008
@@ -55,6 +55,45 @@
_STD::basic_istream_CharT, _Traits
__rw_extract (_STD::basic_istream_CharT, _Traits, _NativeType);
+
+#ifdef _RWSTD_NO_EXT_NUM_GET
+
+template class _CharT, class _Traits
+inline _STD::basic_istream_CharT, _Traits
+__rw_extract (_STD::basic_istream_CharT, _Traits __strm,
+ short__val)
+{
+long __tmp = __val;
+__rw_extract (__strm, __tmp);
+
+_STD::ios_base::iostate __err = _STD::ios_base::goodbit;
+__val = __rw_check_overflow_short (__tmp, __strm.flags (), __err);
+
+if (_STD::ios_base::goodbit != __err)
+__strm.setstate (__err);
+
+return __strm;
+}
+
+template class _CharT, class _Traits
+inline _STD::basic_istream_CharT, _Traits
+__rw_extract (_STD::basic_istream_CharT, _Traits __strm,
+ int __val)
+{
+long __tmp = __val;
+__rw_extract (__strm, __tmp);
+
+_STD::ios_base::iostate __err = _STD::ios_base::goodbit;
+__val = __rw_check_overflow_int (__tmp, __strm.flags (), __err);
+
+if (_STD::ios_base::goodbit != __err)
+__strm.setstate (__err);
+
+return __strm;
+}
+
+#endif // _RWSTD_NO_EXT_NUM_GET
+
} // namespace __rw
Modified: stdcxx/trunk/src/podarray.h
URL:
http://svn.apache.org/viewvc/stdcxx/trunk/src/podarray.h?rev=638382r1=638381r2=638382view=diff
==
--- stdcxx/trunk/src/podarray.h (original)
+++ stdcxx/trunk/src/podarray.h Tue Mar 18 07:22:15 2008
@@ -198,7 +198,13 @@
private:
static _RWSTD_SIZE_T _C_length (const _TypeT *__a) {
+#ifndef _RWSTD_NO_EXT_CHAR_TRAITS_PRIMARY
return _STD::char_traits_TypeT::length (__a);
+#else// #ifdef _RWSTD_NO_EXT_CHAR_TRAITS_PRIMARY
+_RWSTD_SIZE_T __len = 0;
+for (; _TypeT () != *__a; ++__a, ++__len) ;
+return __len;
+#endif // _RWSTD_NO_EXT_CHAR_TRAITS_PRIMARY
}
};
RE: STDCXX-488
After reproducing and observing the problem for this issue yesterday afternoon, I thought the fix would be a simple matter of adding an -rpath option to the link flags as Andrew suggested. Naturally though, it's not that simple. Basically, -rpath does not work on Mac OS X like it does on most other Unix platforms. This is because the library path is actually embeded in the dynamic library rather than executables via the -install_name link flag. Furthermore, the MacOS X dynamic loader assumes that dynamic libraries are installed in the customary directories (e.g. /usr/lib, /usr/local/lib, current working directory) or find them using customary environment variables. Does the current STDCXX build process even contain an install stage (e.g `make install`)? Most of the gory details are contained in the following reference guide: http://developer.apple.com/documentation/DeveloperTools/Conceptual/Dynam icLibraries/Introduction.html I also took a look at how dynamic libraries and executables are linked in other distributions on MacOS X such as the Apache Portable Runtime. It's written in C but the link process and flags are practically the same. All in all, this issue is going to take a little longer to resolve than originally planned. In fact, I'm not sure we shouldn't just postpone this issue until I complete the GNU Autotools [sup]port since all linking (and installation) is already handled by GNU Libtool, even on MacOS X. Brad. -Original Message- From: Andrew Black [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2008 8:29 AM To: dev@stdcxx.apache.org Subject: Re: STDCXX-488 The failure currently observed is an inability to load the libstd library in dynamic builds. When the RPATH makefile variable was introduced, it was decided that it was a cleaner way to provide the executables with a location for the library than the alternative. That alternative is to have some complex logic to determine whether the path should be prepended to LD_LIBRARY_PATH, LD_LIBRARY_PATH_64, SHLIBPATH, DYLDPATH, or some other platform-dependent environment variable. --Andrew Black Eric Lemings wrote: Could someone give an example of the failures described by this issue? In particular, I'm not sure the path should be embedded in the executables and the Makefiles should invoke the executables with the appropriate runtime library search paths. Thanks, Brad.
RE: svn commit: r638382 - in /stdcxx/trunk: include/fstream include/istream src/podarray.h
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Tuesday, March 18, 2008 5:31 PM To: dev@stdcxx.apache.org Subject: Re: svn commit: r638382 - in /stdcxx/trunk: include/fstream include/istream src/podarray.h [EMAIL PROTECTED] wrote: Author: faridz Date: Tue Mar 18 07:22:15 2008 New Revision: 638382 Just out of curiosity: are these warnings new in MSVC 9? (I don't think they show up in MSVC 8 builds.) I saw this warning when compiled the library with MSVC 7.1. Just now compiled with MSVC 8.0 and 9.0 and this warning still present in both compilers. Note: this warning issued on MSVC in strict mode only (when _RWSTD_STRICT_ANSI macro defined). Farid.
Re: svn commit: r638382 - in /stdcxx/trunk: include/fstream include/istream src/podarray.h
Farid Zaripov wrote: -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Tuesday, March 18, 2008 5:31 PM To: dev@stdcxx.apache.org Subject: Re: svn commit: r638382 - in /stdcxx/trunk: include/fstream include/istream src/podarray.h [EMAIL PROTECTED] wrote: Author: faridz Date: Tue Mar 18 07:22:15 2008 New Revision: 638382 Just out of curiosity: are these warnings new in MSVC 9? (I don't think they show up in MSVC 8 builds.) I saw this warning when compiled the library with MSVC 7.1. Just now compiled with MSVC 8.0 and 9.0 and this warning still present in both compilers. Note: this warning issued on MSVC in strict mode only (when _RWSTD_STRICT_ANSI macro defined). Ah! That's why it's not showing up in our nightly builds. Do you think it would be useful to schedule some strict mode builds? Martin
Re: svn commit: r638369 - in /stdcxx/trunk/include: loc/_num_get.cc loc/_num_get.h rw/_iosfwd.h
[EMAIL PROTECTED] wrote:
Author: faridz
Date: Tue Mar 18 07:09:17 2008
New Revision: 638369
[...]
Modified: stdcxx/trunk/include/loc/_num_get.h
URL:
http://svn.apache.org/viewvc/stdcxx/trunk/include/loc/_num_get.h?rev=638369r1=638368r2=638369view=diff
==
--- stdcxx/trunk/include/loc/_num_get.h (original)
+++ stdcxx/trunk/include/loc/_num_get.h Tue Mar 18 07:09:17 2008
@@ -259,6 +259,87 @@
[...]
+else if (__lval __int_max) {
+__err |= _RW::__rw_failbit;
+return = int (_RWSTD_INT_MAX);
This looks like a typo (I'm getting a build error).
Martin
RE: svn commit: r638382 - in /stdcxx/trunk: include/fstream include/istream src/podarray.h
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Tuesday, March 18, 2008 6:08 PM To: dev@stdcxx.apache.org Subject: Re: svn commit: r638382 - in /stdcxx/trunk: include/fstream include/istream src/podarray.h Note: this warning issued on MSVC in strict mode only (when _RWSTD_STRICT_ANSI macro defined). Ah! That's why it's not showing up in our nightly builds. Do you think it would be useful to schedule some strict mode builds? Perhaps testing once per week would be useful and enough. By the way there 3 examples along with rwtest library fails to compile in strict mode. Farid.
RE: svn commit: r638369 - in /stdcxx/trunk/include: loc/_num_get.cc loc/_num_get.h rw/_iosfwd.h
-Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Tuesday, March 18, 2008 6:12 PM To: dev@stdcxx.apache.org Subject: Re: svn commit: r638369 - in /stdcxx/trunk/include: loc/_num_get.cc loc/_num_get.h rw/_iosfwd.h +return = int (_RWSTD_INT_MAX); This looks like a typo (I'm getting a build error). I've tested the patched sources on MSVC and gcc/linux and didn't found this bug due to _RWSTD_INT_MAX == _RWSTD_LONG_MAX on these compilers. Fixed: http://svn.apache.org/viewvc?rev=638433view=rev Farid.
RE: STDCXX-488
Possible, but I believe it would require substantial changes to the srcdir/etc/config/makefile.rules file and any other file that executes an example or test. Brad. -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Tuesday, March 18, 2008 12:16 PM To: dev@stdcxx.apache.org Subject: Re: STDCXX-488 How about the workaround that Andrew suggested: defining DYLD_LIBRARY_PATH in the makefile? Martin Eric Lemings wrote: After reproducing and observing the problem for this issue yesterday afternoon, I thought the fix would be a simple matter of adding an -rpath option to the link flags as Andrew suggested. Naturally though, it's not that simple. Basically, -rpath does not work on Mac OS X like it does on most other Unix platforms. This is because the library path is actually embeded in the dynamic library rather than executables via the -install_name link flag. Furthermore, the MacOS X dynamic loader assumes that dynamic libraries are installed in the customary directories (e.g. /usr/lib, /usr/local/lib, current working directory) or find them using customary environment variables. Does the current STDCXX build process even contain an install stage (e.g `make install`)? Most of the gory details are contained in the following reference guide: http://developer.apple.com/documentation/DeveloperTools/Concep tual/Dynam icLibraries/Introduction.html I also took a look at how dynamic libraries and executables are linked in other distributions on MacOS X such as the Apache Portable Runtime. It's written in C but the link process and flags are practically the same. All in all, this issue is going to take a little longer to resolve than originally planned. In fact, I'm not sure we shouldn't just postpone this issue until I complete the GNU Autotools [sup]port since all linking (and installation) is already handled by GNU Libtool, even on MacOS X. Brad. -Original Message- From: Andrew Black [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2008 8:29 AM To: dev@stdcxx.apache.org Subject: Re: STDCXX-488 The failure currently observed is an inability to load the libstd library in dynamic builds. When the RPATH makefile variable was introduced, it was decided that it was a cleaner way to provide the executables with a location for the library than the alternative. That alternative is to have some complex logic to determine whether the path should be prepended to LD_LIBRARY_PATH, LD_LIBRARY_PATH_64, SHLIBPATH, DYLDPATH, or some other platform-dependent environment variable. --Andrew Black Eric Lemings wrote: Could someone give an example of the failures described by this issue? In particular, I'm not sure the path should be embedded in the executables and the Makefiles should invoke the executables with the appropriate runtime library search paths. Thanks, Brad.
[PATCH] atomic ops on _PA_RISC2_0
Why if _PA_RISC2_0 macro is defined the atimic functions are named
__rw_string_atomic_xxx() but no __rw_atomic_xxx() as on other platforms?
And also why the __rw_string_atomic_pre{in|de}crement(unsigned __x,
bool)
are calling the (possibly undefined?)
__rw_atomic_pre{in|de}crement(int, bool) ?
The proposed patch below:
ChangeLog:
* include/rw/_mutex.h [_PA_RISC2_0]: Rename __rw_string_atomic_xxx()
to __rw_atmic_xxx() respectively.
* include/rw/_defs.h [_PA_RISC2_0]: #define _RWSTD_STRING_ATOMIC_XXX
macros as _RWSTD_ATOMIC_XXX
instead of __rw_string_atomic_xxx().
Index: include/rw/_defs.h
===
--- include/rw/_defs.h (revision 638458)
+++ include/rw/_defs.h (working copy)
@@ -667,26 +667,13 @@
_RWSTD_ATOMIC_SWAP(x, y, mutex)
# endif// _RWSTD_NO_EXT_REENTRANT_IO
-# if defined (_PA_RISC2_0)
+# define _RWSTD_STRING_ATOMIC_PREINCREMENT(x, mutex)\
+ _RWSTD_ATOMIC_PREINCREMENT (x, mutex)
+# define _RWSTD_STRING_ATOMIC_PREDECREMENT(x, mutex)\
+ _RWSTD_ATOMIC_PREDECREMENT (x, mutex)
+# define _RWSTD_STRING_ATOMIC_SWAP(x, y, mutex) \
+ _RWSTD_ATOMIC_SWAP (x, y, mutex)
-#define _RWSTD_STRING_ATOMIC_PREINCREMENT(x, mutex) \
-_RW::__rw_string_atomic_preincrement (x, mutex)
-
-#define _RWSTD_STRING_ATOMIC_PREDECREMENT(x, mutex) \
-_RW::__rw_string_atomic_predecrement (x, mutex)
-
-#define _RWSTD_STRING_ATOMIC_SWAP(x, y, mutex) \
-_RW::__rw_string_atomic_exchange (x, y, mutex)
-
-# else // if !_PA_RISC2_0
-#define _RWSTD_STRING_ATOMIC_PREINCREMENT(x, mutex) \
-_RWSTD_ATOMIC_PREINCREMENT (x, mutex)
-#define _RWSTD_STRING_ATOMIC_PREDECREMENT(x, mutex) \
-_RWSTD_ATOMIC_PREDECREMENT (x, mutex)
-#define _RWSTD_STRING_ATOMIC_SWAP(x, y, mutex) \
-_RWSTD_ATOMIC_SWAP (x, y, mutex)
-# endif // !_PA_RISC2_0
-
// thread-local storage
# ifndef _RWSTD_NO_TLS
#ifndef _RWSTD_THREAD
Index: include/rw/_mutex.h
===
--- include/rw/_mutex.h (revision 638458)
+++ include/rw/_mutex.h (working copy)
@@ -1136,14 +1136,14 @@
inline int
-__rw_string_atomic_preincrement (int __x, bool)
+__rw_atomic_preincrement (int __x, bool)
{
return __rw_atomic_incr32 (__x);
}
inline unsigned
-__rw_string_atomic_preincrement (unsigned __x, bool)
+__rw_atomic_preincrement (unsigned __x, bool)
{
return __rw_atomic_preincrement (_RWSTD_REINTERPRET_CAST(int,
__x),
@@ -1152,14 +1152,14 @@
inline int
-__rw_string_atomic_predecrement (int __x, bool)
+__rw_atomic_predecrement (int __x, bool)
{
return __rw_atomic_decr32 (__x);
}
inline unsigned
-__rw_string_atomic_predecrement (unsigned __x, bool)
+__rw_atomic_predecrement (unsigned __x, bool)
{
return __rw_atomic_predecrement (_RWSTD_REINTERPRET_CAST(int,
__x),
@@ -1168,18 +1168,18 @@
inline int
-__rw_string_atomic_exchange (int __x, int __y, bool)
+__rw_atomic_exchange (int __x, int __y, bool)
{
return __rw_atomic_xchg32 (__x, __y);
}
inline unsigned
-__rw_string_atomic_exchange (unsigned __x, unsigned __y, bool)
+__rw_atomic_exchange (unsigned __x, unsigned __y, bool)
{
-return __rw_string_atomic_exchange (_RWSTD_REINTERPRET_CAST(int,
__x),
-_RWSTD_STATIC_CAST(int,__y),
-false);
+return __rw_atomic_exchange (_RWSTD_REINTERPRET_CAST(int, __x),
+ _RWSTD_STATIC_CAST(int,__y),
+ false);
}
/** i386/gcc || _M_IX86
*/
Farid.
[PATCH] RE: STDCXX-488
Either way, the following patch should be applied assuming there are no issues with it. --- etc/config/gcc.config.orig 2008-03-14 15:43:04.0 -0600 +++ etc/config/gcc.config 2008-03-18 12:54:12.0 -0600 @@ -97,8 +97,11 @@ # no -shared option for GCC on Mac OS X (Darwin) LDSOFLAGS = -shared else -# -dynamiclib is needed when linking the library -LDSOFLAGS = -dynamiclib +# Flags needed when linking the library +LDSOFLAGS = -dynamiclib \ +-install_name $(BUILDDIR)/$(LIBNAME) \ +-compatibility_version 4 \ +-current_version $(LIBVER) endif Brad. -Original Message- From: Eric Lemings [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 18, 2008 12:50 PM To: dev@stdcxx.apache.org Subject: RE: STDCXX-488 Possible, but I believe it would require substantial changes to the srcdir/etc/config/makefile.rules file and any other file that executes an example or test. Brad. -Original Message- From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor Sent: Tuesday, March 18, 2008 12:16 PM To: dev@stdcxx.apache.org Subject: Re: STDCXX-488 How about the workaround that Andrew suggested: defining DYLD_LIBRARY_PATH in the makefile? Martin Eric Lemings wrote: After reproducing and observing the problem for this issue yesterday afternoon, I thought the fix would be a simple matter of adding an -rpath option to the link flags as Andrew suggested. Naturally though, it's not that simple. Basically, -rpath does not work on Mac OS X like it does on most other Unix platforms. This is because the library path is actually embeded in the dynamic library rather than executables via the -install_name link flag. Furthermore, the MacOS X dynamic loader assumes that dynamic libraries are installed in the customary directories (e.g. /usr/lib, /usr/local/lib, current working directory) or find them using customary environment variables. Does the current STDCXX build process even contain an install stage (e.g `make install`)? Most of the gory details are contained in the following reference guide: http://developer.apple.com/documentation/DeveloperTools/Concep tual/Dynam icLibraries/Introduction.html I also took a look at how dynamic libraries and executables are linked in other distributions on MacOS X such as the Apache Portable Runtime. It's written in C but the link process and flags are practically the same. All in all, this issue is going to take a little longer to resolve than originally planned. In fact, I'm not sure we shouldn't just postpone this issue until I complete the GNU Autotools [sup]port since all linking (and installation) is already handled by GNU Libtool, even on MacOS X. Brad. -Original Message- From: Andrew Black [mailto:[EMAIL PROTECTED] Sent: Friday, March 14, 2008 8:29 AM To: dev@stdcxx.apache.org Subject: Re: STDCXX-488 The failure currently observed is an inability to load the libstd library in dynamic builds. When the RPATH makefile variable was introduced, it was decided that it was a cleaner way to provide the executables with a location for the library than the alternative. That alternative is to have some complex logic to determine whether the path should be prepended to LD_LIBRARY_PATH, LD_LIBRARY_PATH_64, SHLIBPATH, DYLDPATH, or some other platform-dependent environment variable. --Andrew Black Eric Lemings wrote: Could someone give an example of the failures described by this issue? In particular, I'm not sure the path should be embedded in the executables and the Makefiles should invoke the executables with the appropriate runtime library search paths. Thanks, Brad.
