Martin, Thanks for the reply. P On Sun, May 3, 2009 at 9:31 AM, Martin Sebor <msebor@gmail.com> wrote: > On Sun, Apr 26, 2009 at 11:28 PM, Peter Lee <peter.lee.cpp@gmail.com> > wrote: > > Hello guys, > > > > I would like to know where/how the information about, which projects are > > based on STDXX, can be gained. > > > > Regards > > > > P > > We don't have such a list. I would certainly be interested in finding out > what projects use stdcxx. > > Of the big projects, AFAIK, OpenSolaris either ships or plans to ship > stdcxx as an alternative to the library that comes with Sun C++. > > Martin >
On Sun, Apr 26, 2009 at 11:28 PM, Peter Lee <peter.lee.cpp@gmail.com> wrote: > Hello guys, > > I would like to know where/how the information about, which projects are > based on STDXX, can be gained. > > Regards > > P We don't have such a list. I would certainly be interested in finding out what projects use stdcxx. Of the big projects, AFAIK, OpenSolaris either ships or plans to ship stdcxx as an alternative to the library that comes with Sun C++. Martin
Hello guys, I would like to know where/how the information about, which projects are based on STDXX, can be gained. Regards P
Hey Keith, You're right, the documentation is confusing. In fact, I'd say the documentation is downright wrong: when ios::nolock is *set* the stream does not get locked and thus is *not thread safe*, while when it's *clear*, it does get locked and the stream is *thread safe*. I filed STDCXX-1030 to correct the docs: https://issues.apache.org/jira/browse/STDCXX-1030 Thanks! Martin khoaglin wrote: > Hello, > > This is a documentation issue in the multi-thread safe section of the users > guide for the stdcxx iostreams. > > In addition, I am posting the error we observed so others can search for > similar errors. > > The following is the error that was observed. However, the error only showed > up intermittently when the system was under sufficient load: > > stopped in __rw::__rw_sputn<char,std::char_traits<char> > at 0x84028 > 0x00084028: __rw_sputn+0x00e0: stb %l1, [%l0] > > We were able to solve the problem using the information in the users guide, > but the section was a little confusing in regards to applying the code > change. > > When it became obvious this was a multi-thread issue with the standard > stdcxx C++ library iostreams. Searching the documentation we found the > following in the Stdcxx Library User's Guide section 44.1 Multithread-Safe: > Level 2 > > > The part that is a little confusing is the following: > > Thread safety is controlled by two bits, ios_base::nolock and > ios_base::nolockbuf. These bits can be set on an iostream object (such as > std::cout) using the public member function std::ios_base::setf(). When the > bits are set, the object behaves in a thread-safe way as described above. > The public member function std::ios_base::unsetf() clears both bits. When > the bits are not set, the object is not thread-safe. It is also possible to > set the bits individually to allow the stream thread-unsafe access on the > stream data (nolock), or to prevent the stream from locking prior to > accessing the stream buffer (nolockbuf). > > > Particularly the part that reads as follows: > "These bits can be set on an iostream object (such as std::cout) using the > public member function std::ios_base::setf(). When the bits are set, the > object behaves in a thread-safe way as described above. " > > And in the following sentence as well: > > "When the bits are not set, the object is not thread-safe." > > If you want thread-safe iostreams you would do the following: > std::ios_base::unsetf( std::ios_base::nolock | std::ios_base::nolockbuf ) > > If you do not want a thread-safe iostreams you would do the following: > > std::ios_base::setf( std::ios_base::nolock | std::ios_base::nolockbuf ) > > The documentation is rather confusing on exactly how this needs to be set > for thread-safe or the default with no thread-safe behavior. > > -Keith
-------- Original Message -------- Subject: [Travel Assistance] Applications for ApacheCon EU 2009 - Now Open Date: Fri, 23 Jan 2009 13:28:19 +0000 From: Tony Stevenson <pctony@apache.org> To: travel-assistance@apache.org The Travel Assistance Committee is now accepting applications for those wanting to attend ApacheCon EU 2009 between the 23rd and 27th March 2009 in Amsterdam. The Travel Assistance Committee is looking for people who would like to be able to attend ApacheCon EU 2009 who need some financial support in order to get there. There are very few places available and the criteria is high, that aside applications are open to all open source developers who feel that their attendance would benefit themselves, their project(s), the ASF or open source in general. Financial assistance is available for travel, accommodation and entrance fees either in full or in part, depending on circumstances. It is intended that all our ApacheCon events are covered, so it may be prudent for those in the United States or Asia to wait until an event closer to them comes up - you are all welcome to apply for ApacheCon EU of course, but there must be compelling reasons for you to attend an event further away that your home location for your application to be considered above those closer to the event location. More information can be found on the main Apache website at http://www.apache.org/travel/index.html - where you will also find a link to the online application form. Time is very tight for this event, so applications are open now and will end on the 4th February 2009 - to give enough time for travel arrangements to be made. Good luck to all those that apply. Regards, The Travel Assistance Committee -- ------------------------------------------------------------------ Tony Stevenson tony@pc-tony.com // pctony@apache.org // pctony@freenode.net http://blog.pc-tony.com/ 1024D/51047D66 ECAF DC55 C608 5E82 0B5E 3359 C9C7 924E 5104 7D66 ------------------------------------------------------------------
Hello, This is a documentation issue in the multi-thread safe section of the users guide for the stdcxx iostreams. In addition, I am posting the error we observed so others can search for similar errors. The following is the error that was observed. However, the error only showed up intermittently when the system was under sufficient load: stopped in __rw::__rw_sputn<char,std::char_traits<char> > at 0x84028 0x00084028: __rw_sputn+0x00e0: stb %l1, [%l0] We were able to solve the problem using the information in the users guide, but the section was a little confusing in regards to applying the code change. When it became obvious this was a multi-thread issue with the standard stdcxx C++ library iostreams. Searching the documentation we found the following in the Stdcxx Library User's Guide section 44.1 Multithread-Safe: Level 2 The part that is a little confusing is the following: Thread safety is controlled by two bits, ios_base::nolock and ios_base::nolockbuf. These bits can be set on an iostream object (such as std::cout) using the public member function std::ios_base::setf(). When the bits are set, the object behaves in a thread-safe way as described above. The public member function std::ios_base::unsetf() clears both bits. When the bits are not set, the object is not thread-safe. It is also possible to set the bits individually to allow the stream thread-unsafe access on the stream data (nolock), or to prevent the stream from locking prior to accessing the stream buffer (nolockbuf). Particularly the part that reads as follows: "These bits can be set on an iostream object (such as std::cout) using the public member function std::ios_base::setf(). When the bits are set, the object behaves in a thread-safe way as described above. " And in the following sentence as well: "When the bits are not set, the object is not thread-safe." If you want thread-safe iostreams you would do the following: std::ios_base::unsetf( std::ios_base::nolock | std::ios_base::nolockbuf ) If you do not want a thread-safe iostreams you would do the following: std::ios_base::setf( std::ios_base::nolock | std::ios_base::nolockbuf ) The documentation is rather confusing on exactly how this needs to be set for thread-safe or the default with no thread-safe behavior. -Keith -- View this message in context: http://www.nabble.com/Documentation-User%27s-Guide%3A-44.1-Multithread-Safe%3A-Level-2-tp21587519p21587519.html Sent from the stdcxx-user mailing list archive at Nabble.com.
[MS]
> Steve Petrie, P.Eng. wrote:
> [...]
>> I use the following MSYS console shell command, to compile the
>> test_stdcxx_1.cpp program:
>>
>> g++.exe -I./include -nostdinc++ -nostdinc -nostdlib -c -o
>> test_stdcxx_1.o
>> test_stdcxx_1.cpp
>
> You also need -I./include/ansi. Its also a good idea to avoid
> using the g++ command and use gcc instead just to make it 100%
> clear that the native C++ Standard Library should not be linked
> (unless you know better , I don't think you want -nostdlib as
> it normally prevents linking with files you want to link with).
[...]
> That's because you're missing -Iinlude/ansi -- that's where
> our cwchar lives. All the errors after this one should clear
> up after you add it.
>
[SP]
OK -- I now have a test program that compiles, links and runs using stdcxx
under MinGW+MSYS.
There's more to it than adding -I./include/ansi to the compile as Martin
suggested, but the -I./include/ansi is definitely necessary.
Here's the test program (it's based on the sample that Farid provided at my
request, designed to conclusively PROVE that it's using stdcxx and not only
the standard library shipped with MinGW+MSYS (The __rw_atomic_add32()
function is SPECIFIC to stdcxx, there's no _atomic-x86.h in MinGW) :
// test_stdcxx_2.cpp ...
// standard library includes...
#include <iostream>
// ...standard library includes.
using std::cout;
// app includes...
#include "rw/_atomic-x86.h"
//... app includes.
using __rw::__rw_atomic_add32;
int main (void)
{
cout << "Hello from test_stdcxx_2.cpp!\n";
int ret = -1;
// dependency on stdcxx library
ret = __rw::__rw_atomic_add32 (&ret, 1);
return ret;
}
// ... test_stdcxx_2.cpp.
* * *
* * *
Here is an MSYS console shell command that successfully compiles the
test_stdcxx_2.cpp program:
gcc.exe -D_RWSTDDEBUG -I./include -I./include/ansi -c -o test_stdcxx_2.o
test_stdcxx_2.cpp
I use the -D_RWSTDDEBUG parameter, because my stdcxx library was built for
debugging.
* * *
* * *
The link is more complicated.
I could NOT find any way to use gcc.exe or g++.exe, to get a successful
link. So I analyzed the various forms of the parameters used with the
following intermediate command (generated by gcc.exe and g++.exe from my
parameters used with them):
i:/apps/mingw/bin/../libexec/gcc/mingw32/3.4.5/collect2.exe ...
parameters ...
Here is the MSYS console shell command, that successfully links the
test_stdcxx_2.o object file (the key items are flagged "**n" here for
convenient reference below):
ld.exe \
-Bstatic \ **1
-o test_stdcxx_2.exe \ **2
i:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../crt2.o \
i:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/crtbegin.o \
-L./lib \ **3
-Li:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5 \
-Li:/apps/mingw/bin/../lib/gcc \
-Li:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../mingw32/lib \
-Li:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/../../.. \
test_stdcxx_2.o \ **4
-lstd11s \ **5
-lstdc++ \ **6
-lmingw32 \
-lgcc \
-lmoldname \
-lmingwex \
-lmsvcrt \
-luser32 \
-lkernel32 \
-ladvapi32 \
-lshell32 \
-lmingw32 \
-lgcc \
-lmoldname \
-lmingwex \
-lmsvcrt \
i:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/crtend.o
The key points in the above are:
**1 => either -Bstatic or -Bdynamic works (omitting the -B parameter
entirely also works).
**2 => -o test_stdcxx_2.exe is the executable to be generated.
**3 =>-L./lib is the directory containing the libstd11s.a build of Apache
stdcxx, built with MinGW_MSYS
(it's FIRST in the list of -L parameters, as I assume this
will give it search priority).
**4=> test_stdcxx_2.o is the object input (it MUST precede the -lstd11s
parameter).
**5 => -lstd11s is the reference to the libstd11s.a build of Apache stdcxx
(it's FIRST in the list of -l parameters, as I assume this
will give it search priority).
**6 => -lstdc++ is the reference to the standard library shipped with
MinGW
(it's NECESSARY to resolve references in some of the
MinGW-supplied object modules)
* * *
* * *
I have a shell script file, that compiles, links and runs the C++ test
program. If you would like to have the script file, and the C++ source file,
just let me know.
For purposes of performing this test, the MSYS console current directory is
where the source program test_stdcxx_2.cpp is:
i:/USR/ASP/stdcxx/
and the libstdcxx.a library is in:
i:/USR/ASP/stdcxx/lib/
* * *
* * *
There are now only two OUTSTANDING ISSUES:
(1) The link produces a HUGE (4.9 MB) test_stdcxx_2.exe executable:
(1.1) I've tried the ld "--gc-sections" parameter, which the
ld --help says will "Remove unused sections (on some targets)"
but it doesn't shrink the executable.
(1.2) compiling without the "-D_RWSTDDEBUG" parameter, doesn't help
to shrink the executable.
(1.3) Removing the "__rw_atomic_add32()" function call, doesn't help
to shrink the executable.
(1.4) By contrast with stdcxx, a similar test program (minus the
__rw_atomic_add32() function call)
compiled and linked using g++.exe and the MinGW_MSYS
standard library, produces
an executable ONLY 486 KB in size.
(2) I will now proceed to work on getting my NetBeans 6.5 IDE (with C++
plugin) to use the Apache stdcxx.
* * *
* * *
Any suggestions, for how to shrink the sixe of executable files, would be
greatly appreciated.
Although I have used open source "products" before, this is my first time
working actively with an open source community, and it's proving to be a
very pleasant and productive experience.
Thanks to Farid and Martin, for all your help.
Steve
----- Original Message -----
From: "Martin Sebor" <msebor@gmail.com>
To: <user@stdcxx.apache.org>
Sent: Thursday, December 04, 2008 5:29 PM
Subject: Re: Building stdcxx-4.2.2 Using MinGW+MSYS On Windows XP (SP2)
> Steve Petrie, P.Eng. wrote:
> [...]
>> I use the following MSYS console shell command, to compile the
>> test_stdcxx_1.cpp program:
>>
>> g++.exe -I./include -nostdinc++ -nostdinc -nostdlib -c -o
>> test_stdcxx_1.o
>> test_stdcxx_1.cpp
>
> You also need -I./include/ansi. Its also a good idea to avoid
> using the g++ command and use gcc instead just to make it 100%
> clear that the native C++ Standard Library should not be linked
> (unless you know better , I don't think you want -nostdlib as
> it normally prevents linking with files you want to link with).
>
>>
>> (Note the dot "." between "-I" and "/include". I have an stdcxx "include"
>> directory, with all its sub-directories, as a sub-directory of the
>> directory
>> where the test_stdcxx_1.cpp source program is located, because I haven't
>> yet
>> been able to figure out how to get g++.exe to respect a "-I" parameter
>> pointing to a more complex path description. The "include" directory,
>> with
>> all its sub-directories, is a copy of what is shipped with stdcxx-4.2.2.)
>>
>> g++.exe displays the following compile errors on the MSYS console:
>>
>> In file included from ./include/rw/_traits.h:40,
>> from ./include/rw/_strref.h:48,
>> from ./include/string:43,
>> from ./include/loc/_locale.h:36,
>> from ./include/rw/_iosbase.h:36,
>> from ./include/streambuf:39,
>> from ./include/ostream:39,
>> from ./include/istream:38,
>> from ./include/iostream:33,
>> from test_stdcxx_1.cpp:4:
>> ./include/rw/_mbstate.h:195:27: cwchar: No such file or directory
>
> That's because you're missing -Iinlude/ansi -- that's where
> our cwchar lives. All the errors after this one should clear
> up after you add it.
>
> Martin
Steve Petrie, P.Eng. wrote: [...] > I use the following MSYS console shell command, to compile the > test_stdcxx_1.cpp program: > > g++.exe -I./include -nostdinc++ -nostdinc -nostdlib -c -o test_stdcxx_1.o > test_stdcxx_1.cpp You also need -I./include/ansi. Its also a good idea to avoid using the g++ command and use gcc instead just to make it 100% clear that the native C++ Standard Library should not be linked (unless you know better , I don't think you want -nostdlib as it normally prevents linking with files you want to link with). > > (Note the dot "." between "-I" and "/include". I have an stdcxx "include" > directory, with all its sub-directories, as a sub-directory of the > directory > where the test_stdcxx_1.cpp source program is located, because I haven't > yet > been able to figure out how to get g++.exe to respect a "-I" parameter > pointing to a more complex path description. The "include" directory, with > all its sub-directories, is a copy of what is shipped with stdcxx-4.2.2.) > > g++.exe displays the following compile errors on the MSYS console: > > In file included from ./include/rw/_traits.h:40, > from ./include/rw/_strref.h:48, > from ./include/string:43, > from ./include/loc/_locale.h:36, > from ./include/rw/_iosbase.h:36, > from ./include/streambuf:39, > from ./include/ostream:39, > from ./include/istream:38, > from ./include/iostream:33, > from test_stdcxx_1.cpp:4: > ./include/rw/_mbstate.h:195:27: cwchar: No such file or directory That's because you're missing -Iinlude/ansi -- that's where our cwchar lives. All the errors after this one should clear up after you add it. Martin
Hi Farid:
[FZ]
It's ok. The rwstderr.cat catalog file is used for overriding standard
exceptions
what() messages (i.e. to have localized messages). On MinGW (as well as on
entire Windows) stdcxx doesn't using rwstderr.cat, but using rwstderr.dll
instead.
Actually if you're fine with english messages, you don't need
rwstderr.{cat|dll}
because of the english messages are hardcoded in library sources.
[SP]
Thanks to your previous assistance, I did succeed in using the GNUmakefile
under MinGW+MSYS, to build a stdcxx libnary libstd11s.a.
HOWEVER, I've been trying without success, to compile a minimal C++ program
under MinGW+MSYS, using the Apache C++ Standard Library (stdcxx), instead of
the Standard Library that is shipped with MinGW+MSYS.
* * *
* * *
The MinGW_MSYS environment, will compile, link and run the following test
program, using the Standard Library shipped with MinGW_MSYS:
// test_mingw.cpp ...
// standard library includes...
#include <iostream>
// ...standard library includes.
using std::cout;
int main (void)
{
cout << "Hello from test_mingw.cpp!\n";
return 0;
}
// ... test_mingw.cpp.
I use the following MSYS console shell commands to compile and link the
test_mingw.cpp program:
g++ -c -o test_mingw.o test_mingw.cpp # compiles ok.
g++ -o test_mingw test_mingw.o # links ok.
The test_mingw.exe program produce by ld, runs fine and displays the
following on the MSYS console:
Hello from test_mingw.cpp!.
* * *
* * *
HOWEVER, so far I have not found a way to compile a similar minimal C++
program under MinGW+MSYS, using the Apache C++ Standard Library (stdcxx),
instead of the Standard Library that is shipped with MinGW+MSYS.
The minimal C++ program I'm trying to compile is:
// test_stdcxx_1.cpp ...
// standard library includes...
#include <iostream>
// ...standard library includes.
using std::cout;
int main (void)
{
cout << "Hello from test_stdcxx_1.cpp!\n";
return 0;
}
// ... test_stdcxx_1.cpp.
I use the following MSYS console shell command, to compile the
test_stdcxx_1.cpp program:
g++.exe -I./include -nostdinc++ -nostdinc -nostdlib -c -o test_stdcxx_1.o
test_stdcxx_1.cpp
(Note the dot "." between "-I" and "/include". I have an stdcxx "include"
directory, with all its sub-directories, as a sub-directory of the directory
where the test_stdcxx_1.cpp source program is located, because I haven't yet
been able to figure out how to get g++.exe to respect a "-I" parameter
pointing to a more complex path description. The "include" directory, with
all its sub-directories, is a copy of what is shipped with stdcxx-4.2.2.)
g++.exe displays the following compile errors on the MSYS console:
In file included from ./include/rw/_traits.h:40,
from ./include/rw/_strref.h:48,
from ./include/string:43,
from ./include/loc/_locale.h:36,
from ./include/rw/_iosbase.h:36,
from ./include/streambuf:39,
from ./include/ostream:39,
from ./include/istream:38,
from ./include/iostream:33,
from test_stdcxx_1.cpp:4:
./include/rw/_mbstate.h:195:27: cwchar: No such file or directory
In file included from ./include/rw/_strref.h:48,
from ./include/string:43,
from ./include/loc/_locale.h:36,
from ./include/rw/_iosbase.h:36,
from ./include/streambuf:39,
from ./include/ostream:39,
from ./include/istream:38,
from ./include/iostream:33,
from test_stdcxx_1.cpp:4::
./include/rw/_traits.h:104:51: cstring: No such file or directory
In file included from ./include/rw/_strref.h:48,
from ./include/string:43,
from ./include/loc/_locale.h:36,
from ./include/rw/_iosbase.h:36,
from ./include/streambuf:39,
from ./include/ostream:39,
from ./include/istream:38,
from ./include/iostream:33,
from test_stdcxx_1.cpp:4:
./include/rw/_traits.h:302: error: expected `;' before "state_type"
./include/rw/_traits.h:303: error: `state_type' was not declared in this
scope
./include/rw/_traits.h:303: error: template argument 1 is invalid
./include/rw/_traits.h: In static member function `static _CharT*
std::char_traits<_CharT>::move(_CharT*, const _CharT*, unsigned int)':
./include/rw/_traits.h:347: error: `memmove' is not a member of `std'
./include/rw/_traits.h: In static member function `static _CharT*
std::char_traits<_CharT>::copy(_CharT*, const _CharT*, unsigned int)':
./include/rw/_traits.h:353: error: `memcpy' is not a member of `std'
./include/rw/_traits.h: At global scope:
./include/rw/_traits.h:396: error: expected `;' before "state_type"
./include/rw/_traits.h:397: error: `state_type' was not declared in this
scope
./include/rw/_traits.h:397: error: template argument 1 is invalid
./include/rw/_traits.h: In static member function `static int
std::char_traits<char>::compare(const char*, const char*, unsigned int)':
./include/rw/_traits.h:420: error: `memcmp' is not a member of `std'
./include/rw/_traits.h: In static member function `static const char*
std::char_traits<char>::find(const char*, unsigned int, const char&)':
./include/rw/_traits.h:428: error: `memchr' is not a member of `std'
./include/rw/_traits.h: In static member function `static unsigned int
std::char_traits<char>::length(const char*)':
./include/rw/_traits.h:434: error: `strlen' is not a member of `std'
./include/rw/_traits.h: In static member function `static char*
std::char_traits<char>::move(char*, const char*, unsigned int)':
./include/rw/_traits.h:439: error: `memmove' is not a member of `std'
./include/rw/_traits.h: In static member function `static char*
std::char_traits<char>::copy(char*, const char*, unsigned int)':
./include/rw/_traits.h:445: error: `memcpy' is not a member of `std'
./include/rw/_traits.h: In static member function `static char*
std::char_traits<char>::assign(char*, unsigned int, char)':
./include/rw/_traits.h:451: error: `memset' is not a member of `std'
./include/rw/_traits.h: At global scope:
./include/rw/_traits.h:483: error: expected `;' before "state_type"
./include/rw/_traits.h:484: error: `state_type' was not declared in this
scope
./include/rw/_traits.h:484: error: template argument 1 is invalid
./include/rw/_traits.h: In static member function `static int
std::char_traits<wchar_t>::compare(const wchar_t*, const wchar_t*, unsigned
int)':
./include/rw/_traits.h:504: error: `wmemcmp' was not declared in this
scope
./include/rw/_traits.h: In static member function `static unsigned int
std::char_traits<wchar_t>::length(const wchar_t*)':
./include/rw/_traits.h:509: error: `wcslen' is not a member of `std'
./include/rw/_traits.h: In static member function `static const wchar_t*
std::char_traits<wchar_t>::find(const wchar_t*, unsigned int, const
wchar_t&)':
./include/rw/_traits.h:515: error: `wmemchr' is not a member of `std'
./include/rw/_traits.h: In static member function `static wchar_t*
std::char_traits<wchar_t>::copy(wchar_t*, const wchar_t*, unsigned int)':
./include/rw/_traits.h:522: error: `wmemcpy' is not a member of `std'
./include/rw/_traits.h: In static member function `static wchar_t*
std::char_traits<wchar_t>::move(wchar_t*, const wchar_t*, unsigned int)':
./include/rw/_traits.h:528: error: `wmemmove' is not a member of `std'
./include/rw/_traits.h: In static member function `static wchar_t*
std::char_traits<wchar_t>::assign(wchar_t*, unsigned int, wchar_t)':
./include/rw/_traits.h:534: error: `wmemset' is not a member of `std'
In file included from ./include/rw/_iosbase.h:36,
from ./include/streambuf:39,
from ./include/ostream:39,
from ./include/istream:38,
from ./include/iostream:33,
from test_stdcxx_1.cpp:4:
./include/loc/_locale.h: At global scope:
./include/loc/_locale.h:403: error: `mbstate_t' is not a member of `std'
./include/loc/_locale.h:403: error: `mbstate_t' is not a member of `std'
./include/loc/_locale.h:403: error: template argument 3 is invalid
./include/loc/_locale.h:470: error: `mbstate_t' is not a member of `std'
./include/loc/_locale.h:470: error: `mbstate_t' is not a member of `std'
./include/loc/_locale.h:470: error: template argument 3 is invalid
I've tried using a "-Z" parameter with the g++.exe command, but g++.exe
still won't generate an object file.
The first file "cwchar" that g++.exe is complaining that it can't find, does
exist. It's in directory ./include/ansi/ I tried copying file "cwchar" to
./include/ but this didn't fix the first compiler error.
* * *
* * *
.
Any suggestions you could make, would be most appreciated. Or, if you could
compile and link my minimal test program "test_stdcxx_1.cpp" under your
MinGW+MSYS, and tell me how you did it, that would be even better.
Thanks.
Steve
----- Original Message -----
From: "Farid Zaripov" <Farid_Zaripov@epam.com>
To: <user@stdcxx.apache.org>
Sent: Wednesday, December 03, 2008 3:51 AM
Subject: Re: Building stdcxx-4.2.2 Using MinGW+MSYS On Windows XP (SP2)
> HOWEVER, after the completion of the "ar rv libstd11s.a ..." command
> executed near the very end of the build process, the following was
> displayed
> on the MSYS console, and the build process stopped:
[...]
> i:\apps\mingw\bin\ar.exe: creating libstd11s.a
> gencat rwstderr.cat /stdcxx-4.2.2/src/rwstderr.msg
> /bin/sh: gencat: command not found
> make[2]: [rwstderr.cat] Error 127 (ignored)
It's ok. The rwstderr.cat catalog file is used for overriding standard
exceptions
what() messages (i.e. to have localized messages). On MinGW (as well as on
entire Windows) stdcxx doesn't using rwstderr.cat, but using rwstderr.dll
instead.
Actually if you're fine with english messages, you don't need
rwstderr.{cat|dll}
because of the english messages are hardcoded in library sources.
> Would please tell me, what do I need to do, to get the gencat.exe utility
> to
> accept the rwstderr.msg file?
On Windows gencat.exe acceps rwstderr.rc file and produces rwstderr.dll
file.
Farid.
> HOWEVER, after the completion of the "ar rv libstd11s.a ..." command
> executed near the very end of the build process, the following was displayed
> on the MSYS console, and the build process stopped:
[...]
> i:\apps\mingw\bin\ar.exe: creating libstd11s.a
> gencat rwstderr.cat /stdcxx-4.2.2/src/rwstderr.msg
> /bin/sh: gencat: command not found
> make[2]: [rwstderr.cat] Error 127 (ignored)
It's ok. The rwstderr.cat catalog file is used for overriding standard exceptions
what() messages (i.e. to have localized messages). On MinGW (as well as on
entire Windows) stdcxx doesn't using rwstderr.cat, but using rwstderr.dll instead.
Actually if you're fine with english messages, you don't need rwstderr.{cat|dll}
because of the english messages are hardcoded in library sources.
> Would please tell me, what do I need to do, to get the gencat.exe utility to
> accept the rwstderr.msg file?
On Windows gencat.exe acceps rwstderr.rc file and produces rwstderr.dll file.
Farid.
[FZ]
I have MSYS 1.0.11.0(0.46/3/2) and "ln --version" reports version 5.97
[SP]
The "ln" in MSYS 1.0.10 was pre-5.97, so I downloaded and installed:
msysCORE-1.0.11-20080826.tar.gz.
In this version of MSYS, the "ln" version is 5.97.
I reverted to the GNUmakefile shipped with stdcxx-4.2.2, and ran the
stdcxx-4.2.2 build under MSYS with the following command (following the
instructions in your earlier email, except: changing the BUILDTYPE to 11s
from 15D, and explicitly specifying the CONFIG=gcc.config):
make BUILDDIR=/stdcxx-4.2.2/build_11s \
BUILDTYPE=11s \
CONFIG=gcc.config \
config lib
The "ln" command worked ok, and the build created a "libstd11s.a" file of
12.4 MB size.
HOWEVER, after the completion of the "ar rv libstd11s.a ..." command
executed near the very end of the build process, the following was displayed
on the MSYS console, and the build process stopped:
ar rv libstd11s.a
[...]
a - valarray.o
a - vecbool.o
a - version.o
a - wcodecvt.o
a - wctype.o
i:\apps\mingw\bin\ar.exe: creating libstd11s.a
gencat rwstderr.cat /stdcxx-4.2.2/src/rwstderr.msg
/bin/sh: gencat: command not found
make[2]: [rwstderr.cat] Error 127 (ignored)
make[2]: Leaving directory `/stdcxx-4.2.2/build_11s/lib'
make[1]: Leaving directory `/stdcxx-4.2.2/build_11s'
make: Nothing to be done for `lib'.
SteveP@DELL /stdcxx-4.2.2
It looked to me like the (line 10) message:
"/bin/sh: gencat: command not found"
happened because the stdcxx-4.2.2 utilities had not been built, so no
"gencat.exe" utility program existed..
So I deleted the "build_11s" build, and ran the stdcxx-4.2.2 build under
MSYS, using the following command:
make BUILDDIR=/stdcxx-4.2.2/build_11s \
BUILDTYPE=11s \
CONFIG=gcc.config \
builddir config util lib locales
Again, the build ended, with a "/bin/sh: gencat: command not found" error.
However, there was now a "gencat.exe" in /stdcxx-4.2.2/build_11s/bin".
It looked like the "/bin/sh: gencat: command not found" error was caused
because "gencat.exe" was not reachable via any path definition.
So I copied "gencat.exe" into the /msys/1.0.11/bin/" directory, and tried to
install the library, using the following command, with MSYS in the
/stdcxx-4.2.2/build_11s directory:
make install PREFIX=install_11s
The install displayed the following on the MSYS console:
$ make install PREFIX=install_11s
mkdir -p install_11s
make -Clib install
make[1]: Entering directory `/stdcxx-4.2.2/build_11s/lib'
gencat rwstderr.cat /stdcxx-4.2.2/src/rwstderr.msg
windres: i:/apps/stdcxx-4.2.2/src/rwstderr.msg:1: syntax error
make[1]: [rwstderr.cat] Error 1 (ignored)
mkdir -p install_11s/lib
cp libstd11s.a install_11s/lib
if [ libstd11s.a != libstd11s.a ]; then \
rm install_11s/lib/libstd11s.a; \
ln -s libstd11s.a install_11s/lib/libstd11s.a; \
fi
mkdir -p install_11s/etc
cp rwstderr.cat install_11s/etc
cp: cannot stat `rwstderr.cat': No such file or directory
make[1]: *** [install] Error 1
make[1]: Leaving directory `/stdcxx-4.2.2/build_11s/lib'
make: *** [install] Error 2
SteveP@DELL /stdcxx-4.2.2/build_11s
On line 6 of the above, the gencat command failed, and displayed:
"windres: i:/apps/stdcxx-4.2.2/src/rwstderr.msg:1: syntax error".
On line 16 of the above, the cp command failed (due to the earlier failure
of the gencat command), and displayed:
"cp: cannot stat `rwstderr.cat': No such file or directory".
I tried changing the format of file "rwstderr.msg" from DOS to UNIX format
(i.e from 0D0A line ends, to 0A line ends) but got the same error from
"gencat.exe".
So now I'm stuck at the install step.
Would please tell me, what do I need to do, to get the gencat.exe utility to
accept the rwstderr.msg file?
Thanks,
Steve
----- Original Message -----
From: "Farid Zaripov" <Farid_Zaripov@epam.com>
To: <user@stdcxx.apache.org>
Sent: Friday, November 28, 2008 8:09 AM
Subject: Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
> But I definitely DO have the problem with "ln" on my MSYS :(
[...]
> I'm using Windows XP (SP2) and MinGW (5.1.4) and MSYS (1.0.10). Perhaps we
> have a difference in our operating environments?
I have MSYS 1.0.11.0(0.46/3/2) and "ln --version" reports version 5.97
> Then I created a documented test case shell script "test.mingw.ln"
> (attached), that replicates the problem on my MinGW+MSYS system.
> Would you like to run the script in an MSYS console on your system, and
> let
> me know the result?
Unfortunately, I don't see any file attached :(
> Here are a couple of interesting quotes related to MinGW+MSYS and ln, that
> I
> found through a Google search:
>
> <quote 1>
>
> There is no way to create a "file symlink" in MSYS in a way similar to a
> "directory symlink" (that is, a mount point).
> The command ln for creating links works, but it actually makes a copy of
> the
> original file, not a symlink to it.
>
> </quote 1>
Right, the ln just copying file on my side.
> Is there a simple test I can use, a simple C++ program, that e.g. obtains
> the ID and version of the stdcxx library?
Try this:
-----------
#include <iostream>
int main ()
{
// install dependency on stdcxx headers
std::cout << "Test program using stdcxx version " << _RWSTD_VER_STR <<
std::endl;
int ret = -1;
// install dependency on stdcxx library
ret = __rw::__rw_atomic_add32 (&ret, 1);
return ret;
}
-----------
> HOWEVER, until ALL the stdcxx tests are verified as ok on gcc/MinGW, this
> means that there IS/ARE some problem(s) with stdcxx in MinGW, does it not?
> After all, isn't the purpose of the tests to prove that the stdcxx libary
> on the
> target system is working correctly?
In general it is, but there are might be some expected failures (which has
been
documented in JIRA) and failures, that should be an expected, but not
documented
in JIRA yet. BTW any stdcxx user can document new failures by creating
corresponding
issues in JIRA ;)
The 18.c.limits.stdcxx-988.cpp test fails to compile on gcc/MinGW due to
undefined
LONG_BIT, SSIZE_MAX, WORD_BIT values. They're expected to be defined in
<limits.h>
provided by compiler. Strictly speaking I didn't found these names mentioned
in
current C++ standard in header <climits> synopsis. I suppose that they're
optional
(i.e. required by POSIX only) and can be not exercised (as it is already
done for EDG eccp).
Farid.
> But I definitely DO have the problem with "ln" on my MSYS :(
[...]
> I'm using Windows XP (SP2) and MinGW (5.1.4) and MSYS (1.0.10). Perhaps we
> have a difference in our operating environments?
I have MSYS 1.0.11.0(0.46/3/2) and "ln --version" reports version 5.97
> Then I created a documented test case shell script "test.mingw.ln"
> (attached), that replicates the problem on my MinGW+MSYS system.
> Would you like to run the script in an MSYS console on your system, and let
> me know the result?
Unfortunately, I don't see any file attached :(
> Here are a couple of interesting quotes related to MinGW+MSYS and ln, that I
> found through a Google search:
>
> <quote 1>
>
> There is no way to create a "file symlink" in MSYS in a way similar to a
> "directory symlink" (that is, a mount point).
> The command ln for creating links works, but it actually makes a copy of the
> original file, not a symlink to it.
>
> </quote 1>
Right, the ln just copying file on my side.
> Is there a simple test I can use, a simple C++ program, that e.g. obtains
> the ID and version of the stdcxx library?
Try this:
-----------
#include <iostream>
int main ()
{
// install dependency on stdcxx headers
std::cout << "Test program using stdcxx version " << _RWSTD_VER_STR <<
std::endl;
int ret = -1;
// install dependency on stdcxx library
ret = __rw::__rw_atomic_add32 (&ret, 1);
return ret;
}
-----------
> HOWEVER, until ALL the stdcxx tests are verified as ok on gcc/MinGW, this
> means that there IS/ARE some problem(s) with stdcxx in MinGW, does it not?
> After all, isn't the purpose of the tests to prove that the stdcxx libary on the
> target system is working correctly?
In general it is, but there are might be some expected failures (which has been
documented in JIRA) and failures, that should be an expected, but not documented
in JIRA yet. BTW any stdcxx user can document new failures by creating corresponding
issues in JIRA ;)
The 18.c.limits.stdcxx-988.cpp test fails to compile on gcc/MinGW due to undefined
LONG_BIT, SSIZE_MAX, WORD_BIT values. They're expected to be defined in <limits.h>
provided by compiler. Strictly speaking I didn't found these names mentioned in
current C++ standard in header <climits> synopsis. I suppose that they're optional
(i.e. required by POSIX only) and can be not exercised (as it is already done for EDG eccp).
Farid.
[SP] > > Then I created a documented test case shell script "test.mingw.ln" > (attached), that replicates the problem on my MinGW+MSYS system. > Would you like to run the script in an MSYS console on your system, and > let > me know the result? > [SP] I notice that user@stdcxx.apache.org has stripped the file attachment "test.mingw.ln" from my email, before sending my email to mailing list subscribers. I will be away from my computer for a couple of days. When I return, I'll provide the "test.mingw.ln" file to you. Steve ----- Original Message ----- From: "Steve Petrie, P.Eng." <apetrie@attglobal.net> To: <user@stdcxx.apache.org> Sent: Friday, November 28, 2008 12:05 AM Subject: Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2) > [FZ] > Actually my goal is make it possible to build stdcxx/MinGW and > stdcxx/Cygwin using Cygwin environment as well as stdcxx/MinGW using MSYS > environment. > > [SP] > Good -- so we share the same goal of making it possible to build > stdcxx/MinGW using the MSYS > environment. > > * * * > * * * > > [FZ] >> On the three lines marked ** above, I added an explicit file name after >> the >> $(buildpath) because the MinGW <ls> command, was REPLACING the >> /stdcxx-4.2.1/build/ directory name, with a link (named >> /stdcxx-4.2.1/build) >> to the file, instead of creating a link to the file (with the name of the >> file), IN the /stdcxx-4.2.1/build/ directory. > > I have no such problems when running make on MSYS. > > [SP] > Lucky you :) > > But I definitely DO have the problem with "ln" on my MSYS :( > > ( It's actually the "ln" command, not "ls" that has the bug. Due to lack > of > sleep. I mis-named the "ln" command "ls" in my description. But the > example > code above the description, showed "ln".) > > I'm using Windows XP (SP2) and MinGW (5.1.4) and MSYS (1.0.10). Perhaps we > have a difference in our operating environments? > > I have replicated the problem outside the stdcxx-4.2.2 make, by manually > entering the ln commands at an MSYS console. > > Then I created a documented test case shell script "test.mingw.ln" > (attached), that replicates the problem on my MinGW+MSYS system. > Would you like to run the script in an MSYS console on your system, and > let > me know the result? > > I plan to report this problem (and provide the test script) to > www.mingw.org > and it would be helpful to know for sure that it's something peculiar to > my > environment. > > Here are a couple of interesting quotes related to MinGW+MSYS and ln, that > I > found through a Google search: > > <quote 1> > > There is no way to create a "file symlink" in MSYS in a way similar to a > "directory symlink" (that is, a mount point). > The command ln for creating links works, but it actually makes a copy of > the > original file, not a symlink to it. > > </quote 1> > > > <quote 2> > It is possible to build under MinGW, however the release packages are > build under cygwin and I am trying to duplicate the setup used. > [...] > Cygwin softlinks are unusable under native windows, so we need to > disableCygwin's "ln" command and let gcc's build scripts use "cp" > instead.</quote 2> > > quote 2 above, is from web page > http://article.gmane.org/gmane.comp.gnu.mingw.user/25585 > > * * * > * * * > > [FZ] > My congratulations, you have just build the stdcxx library :) > > [SP] > Great! > > Now I'll install the stdcxx library, for use with my NetBeans 6.5 IDE > (With > C++ plugin.) > > Is there a simple test I can use, a simple C++ program, that e.g. obtains > the > ID and version of the stdcxx library? > > After I install the stdcxx library, I would like to conclusively PROVE to > myself, > that I'm actually hooking into the stdcxx library, and not the standard > library shipped with MinGW. > > * * * > * * * > > [FZ] > Hmm, you must be wrong, we don't have any file with the name "build" in > svn. > > [SP} > You are correct -- my apologies. > > The /stdcxx-4.2.2/build file, that I mistakenly thought came with the svn, > was a file link named "build", linked to > /stdcxx-4.2.2/etc/config/makefile.rules. > > This link was created by the buggy MinGW <ln> command that I described in > my > "Fix #1 -- /stdcxx-4.2.2/CNUmakefile". > > I must have run the make first once, and forgot about the buggy MinGW <ln> > that created the /stdcxx-4.2.2/build file link. So I assumed that the > /stdcxx-4.2.2/build file came with the svn. > > * * * > * * * > > [FZ] > It depends on what you want :) You have build the stdcxx library > successfully, so now you can compile > your programs with stdcxx. > [...] > 18.c.limits.stdcxx-988.cpp is just one of the regression tests. It was > not > verified on gcc/MinGW so > it fails to compile. But this failure doesn't means that there is some > problem or bug in stdcxx library. > > [SP] > I don't entirely follow your thinking. > > I'm glad to know that I've successfully built the stdcxx library -- that's > a > HUGE step in the right direction. And certainly I'm going to start using > stdcxx in my C++ programming work. > > HOWEVER, until ALL the stdcxx tests are verified as ok on gcc/MinGW, this > means > that there IS/ARE some problem(s) with stdcxx in MinGW, does it not? After > all, isn't > the purpose of the tests to prove that the stdcxx libary on the target > system is working correctly? > > Steve > > ----- Original Message ----- > From: "Farid Zaripov" <Farid_Zaripov@epam.com> > To: <user@stdcxx.apache.org> > Sent: Thursday, November 27, 2008 2:24 PM > Subject: RE: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2) > > >> I assume that you are building stdcxx-4.2.2 using Cygwin, and targeting >> MinGW. My objective is to build stdcxx-4.2.2 using MinGW. I don't use >> Cygwin >> and I don't plan to use it. > > Actually my goal is make it possible to build stdcxx/MinGW and > stdcxx/Cygwin > using Cygwin environment as well as stdcxx/MinGW using MSYS environment. > >> There were two fixes I had to make, to get the build of the patched >> stdcxx-4.2.2 to run: > > [...] > >> On the three lines marked ** above, I added an explicit file name after >> the >> $(buildpath) because the MinGW <ls> command, was REPLACING the >> /stdcxx-4.2.1/build/ directory name, with a link (named >> /stdcxx-4.2.1/build) >> to the file, instead of creating a link to the file (with the name of the >> file), IN the /stdcxx-4.2.1/build/ directory. > > I have no such problems when running make on MSYS. > >> Fix #2 -- Your /stdcxx-4.2.2/build file: >> >> I renamed the /stdcxx-4.2.2/build file that came with the svn download, >> to >> /stdcxx-4.2.1/build_faridz, because the presence of the build FILE was >> preventing the GNUmakefile from creating the /stdcxx-4.2.2/build/ >> DIRECTORY. > > Hmm, you must be wrong, we don't have any file with the name "build" in > svn. > > [...] > >> There is an /stdcxx-4.2.2/build/liblibstd.a file of size 2.33 MB. > > My congratulations, you have just build the stdcxx library :) > >> HOWEVER, the build ended with the following displayed on the MSYS >> console: > > When you run make without targets specified, the examples, tests, locales > will be build. > Not all tests are compiling without errors on gcc/MinGW at the moment. It > is > ok. > > You can build the library only (without examples, tests and so on) using > this command: "make config lib" > Also I suggest to explicitly specify the build type. I.e.: > > make BUILDDIR=/var/tmp/stdcxx-4.2.2/gcc/15d BUILDTYPE=15d config lib > >> In the line "make[1]: [tests] Error 2 (ignored)", does the "(ignored)" >> mean >> that <make> did not terminate prematurely, and that file: >> >> /stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp >> >> is the last test source file to be compiled? > > I don't think so. The make should stop on the first error encountered > unless make was executed with "-k" option specified. > >> According to the /stdcxx-4.2.2/README file, the last build step is the >> locale databases. The build I ran left the /stdcxx-4.2.2/nls/ directory >> completely EMPTY. > > Right, that because of make stopped on the compile error you mentioned > above. > >> Please let me know -- did the build complete successfully? > > It depends on what you want :) You have build the stdcxx library > successfully, so now you can compile > your programs with stdcxx. > >> If not, and I >> need to fix the 18.c.limits.stdcxx-988.cpp compile error, what changes to >> I >> need to make to fix the compile error? > > 18.c.limits.stdcxx-988.cpp is just one of the regression tests. It was > not > verified on gcc/MinGW so > it fails to compile. But this failure doesn't means that there is some > problem or bug in stdcxx library. > > Farid. >
[MS] > Right. I think a "build" directory gets created automatically > when one isn't specified on the command line (via BUILDDIR). > Something weird seems to be going on in Steve's environment > (the behavior of ln -s is definitely bizarre)... > [SP] Yes there is something wierd. Please see my response to Farid's message, regarding a test shell script I created, to replicate the MinGW+MSYS ln problem. But I've got a workaround for the problem. And Farid says my stdcxx build is now working. So no big deal. I'm "only" using MinGW+MSYS for compiling and building C++ programs through the NetBeans IDE (with C++ plugin). That all seems to work fine. It's the comparably far more complex process of building the stdcxx library, that is stressing my MinGW+MSYS. But I want to use stdcxx because it seems to me likely to be superior to the standard library shipped with g++, so I don't mind at all working through the glitches to get stdcxx built and working. * * * * * * [MS]>>> There is an /stdcxx-4.2.2/build/liblibstd.a file of size 2.33 MB. >> >> My congratulations, you have just build the stdcxx library :) > > Although it probably shouldn't be called liblibstd, should it? > What's with the duplicate "lib" part? > [SP] It's lack of sleep -- the correct pathname is /stdcxx-4.2.2/build/lib/libstd.a Steve ----- Original Message ----- From: "Martin Sebor" <msebor@gmail.com> To: <user@stdcxx.apache.org> Sent: Thursday, November 27, 2008 3:05 PM Subject: Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2) > Farid Zaripov wrote: > [...] >>> Fix #2 -- Your /stdcxx-4.2.2/build file: >>> >>> I renamed the /stdcxx-4.2.2/build file that came with the svn download, >>> to >>> /stdcxx-4.2.1/build_faridz, because the presence of the build FILE was >>> preventing the GNUmakefile from creating the /stdcxx-4.2.2/build/ >>> DIRECTORY. >> >> Hmm, you must be wrong, we don't have any file with the name "build" in >> svn. > > Right. I think a "build" directory gets created automatically > when one isn't specified on the command line (via BUILDDIR). > Something weird seems to be going on in Steve's environment > (the behavior of ln -s is definitely bizarre)... > >> >> [...] >> >>> There is an /stdcxx-4.2.2/build/liblibstd.a file of size 2.33 MB. >> >> My congratulations, you have just build the stdcxx library :) > > Although it probably shouldn't be called liblibstd, should it? > What's with the duplicate "lib" part? > > Martin >
[FZ] Actually my goal is make it possible to build stdcxx/MinGW and stdcxx/Cygwin using Cygwin environment as well as stdcxx/MinGW using MSYS environment. [SP] Good -- so we share the same goal of making it possible to build stdcxx/MinGW using the MSYS environment. * * * * * * [FZ] > On the three lines marked ** above, I added an explicit file name after > the > $(buildpath) because the MinGW <ls> command, was REPLACING the > /stdcxx-4.2.1/build/ directory name, with a link (named > /stdcxx-4.2.1/build) > to the file, instead of creating a link to the file (with the name of the > file), IN the /stdcxx-4.2.1/build/ directory. I have no such problems when running make on MSYS. [SP] Lucky you :) But I definitely DO have the problem with "ln" on my MSYS :( ( It's actually the "ln" command, not "ls" that has the bug. Due to lack of sleep. I mis-named the "ln" command "ls" in my description. But the example code above the description, showed "ln".) I'm using Windows XP (SP2) and MinGW (5.1.4) and MSYS (1.0.10). Perhaps we have a difference in our operating environments? I have replicated the problem outside the stdcxx-4.2.2 make, by manually entering the ln commands at an MSYS console. Then I created a documented test case shell script "test.mingw.ln" (attached), that replicates the problem on my MinGW+MSYS system. Would you like to run the script in an MSYS console on your system, and let me know the result? I plan to report this problem (and provide the test script) to www.mingw.org and it would be helpful to know for sure that it's something peculiar to my environment. Here are a couple of interesting quotes related to MinGW+MSYS and ln, that I found through a Google search: <quote 1> There is no way to create a "file symlink" in MSYS in a way similar to a "directory symlink" (that is, a mount point). The command ln for creating links works, but it actually makes a copy of the original file, not a symlink to it. </quote 1> <quote 2> It is possible to build under MinGW, however the release packages are build under cygwin and I am trying to duplicate the setup used. [...] Cygwin softlinks are unusable under native windows, so we need to disableCygwin's "ln" command and let gcc's build scripts use "cp" instead.</quote 2> quote 2 above, is from web page http://article.gmane.org/gmane.comp.gnu.mingw.user/25585 * * * * * * [FZ] My congratulations, you have just build the stdcxx library :) [SP] Great! Now I'll install the stdcxx library, for use with my NetBeans 6.5 IDE (With C++ plugin.) Is there a simple test I can use, a simple C++ program, that e.g. obtains the ID and version of the stdcxx library? After I install the stdcxx library, I would like to conclusively PROVE to myself, that I'm actually hooking into the stdcxx library, and not the standard library shipped with MinGW. * * * * * * [FZ] Hmm, you must be wrong, we don't have any file with the name "build" in svn. [SP} You are correct -- my apologies. The /stdcxx-4.2.2/build file, that I mistakenly thought came with the svn, was a file link named "build", linked to /stdcxx-4.2.2/etc/config/makefile.rules. This link was created by the buggy MinGW <ln> command that I described in my "Fix #1 -- /stdcxx-4.2.2/CNUmakefile". I must have run the make first once, and forgot about the buggy MinGW <ln> that created the /stdcxx-4.2.2/build file link. So I assumed that the /stdcxx-4.2.2/build file came with the svn. * * * * * * [FZ] It depends on what you want :) You have build the stdcxx library successfully, so now you can compile your programs with stdcxx. [...] 18.c.limits.stdcxx-988.cpp is just one of the regression tests. It was not verified on gcc/MinGW so it fails to compile. But this failure doesn't means that there is some problem or bug in stdcxx library. [SP] I don't entirely follow your thinking. I'm glad to know that I've successfully built the stdcxx library -- that's a HUGE step in the right direction. And certainly I'm going to start using stdcxx in my C++ programming work. HOWEVER, until ALL the stdcxx tests are verified as ok on gcc/MinGW, this means that there IS/ARE some problem(s) with stdcxx in MinGW, does it not? After all, isn't the purpose of the tests to prove that the stdcxx libary on the target system is working correctly? Steve ----- Original Message ----- From: "Farid Zaripov" <Farid_Zaripov@epam.com> To: <user@stdcxx.apache.org> Sent: Thursday, November 27, 2008 2:24 PM Subject: RE: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2) > I assume that you are building stdcxx-4.2.2 using Cygwin, and targeting > MinGW. My objective is to build stdcxx-4.2.2 using MinGW. I don't use > Cygwin > and I don't plan to use it. Actually my goal is make it possible to build stdcxx/MinGW and stdcxx/Cygwin using Cygwin environment as well as stdcxx/MinGW using MSYS environment. > There were two fixes I had to make, to get the build of the patched > stdcxx-4.2.2 to run: [...] > On the three lines marked ** above, I added an explicit file name after > the > $(buildpath) because the MinGW <ls> command, was REPLACING the > /stdcxx-4.2.1/build/ directory name, with a link (named > /stdcxx-4.2.1/build) > to the file, instead of creating a link to the file (with the name of the > file), IN the /stdcxx-4.2.1/build/ directory. I have no such problems when running make on MSYS. > Fix #2 -- Your /stdcxx-4.2.2/build file: > > I renamed the /stdcxx-4.2.2/build file that came with the svn download, to > /stdcxx-4.2.1/build_faridz, because the presence of the build FILE was > preventing the GNUmakefile from creating the /stdcxx-4.2.2/build/ > DIRECTORY. Hmm, you must be wrong, we don't have any file with the name "build" in svn. [...] > There is an /stdcxx-4.2.2/build/liblibstd.a file of size 2.33 MB. My congratulations, you have just build the stdcxx library :) > HOWEVER, the build ended with the following displayed on the MSYS console: When you run make without targets specified, the examples, tests, locales will be build. Not all tests are compiling without errors on gcc/MinGW at the moment. It is ok. You can build the library only (without examples, tests and so on) using this command: "make config lib" Also I suggest to explicitly specify the build type. I.e.: make BUILDDIR=/var/tmp/stdcxx-4.2.2/gcc/15d BUILDTYPE=15d config lib > In the line "make[1]: [tests] Error 2 (ignored)", does the "(ignored)" > mean > that <make> did not terminate prematurely, and that file: > > /stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp > > is the last test source file to be compiled? I don't think so. The make should stop on the first error encountered unless make was executed with "-k" option specified. > According to the /stdcxx-4.2.2/README file, the last build step is the > locale databases. The build I ran left the /stdcxx-4.2.2/nls/ directory > completely EMPTY. Right, that because of make stopped on the compile error you mentioned above. > Please let me know -- did the build complete successfully? It depends on what you want :) You have build the stdcxx library successfully, so now you can compile your programs with stdcxx. > If not, and I > need to fix the 18.c.limits.stdcxx-988.cpp compile error, what changes to > I > need to make to fix the compile error? 18.c.limits.stdcxx-988.cpp is just one of the regression tests. It was not verified on gcc/MinGW so it fails to compile. But this failure doesn't means that there is some problem or bug in stdcxx library. Farid.
Farid Zaripov wrote:
>> Although it probably shouldn't be called liblibstd, should it?
>> What's with the duplicate "lib" part?
>
> I think you should know, that the library file located in lib subdirectory ;)
>
> I suppose that there missed '/' after the first 'lib': /stdcxx-4.2.2/build/lib/libstd.a
>
> And what I don't like is that when BUILDTYPE is not specified, the name of library
file is always
> libstd.{a;so} for any possible BUILDMODE values (even for empty BUILDMODE). The comments
> in GNUMakefile says that BUILDTYPE and BUILDMODE both are optional and by default will
be
> used 11s, but this is not true...
We should fix the text. When you don't specify either you get neither
debugging (i.e., no -g) nor optimization (i.e., no -O). I.e., you get
whatever the default invocation of the compiler gives you with no
options.
Martin
>
> Farid.
> Although it probably shouldn't be called liblibstd, should it?
> What's with the duplicate "lib" part?
I think you should know, that the library file located in lib subdirectory ;)
I suppose that there missed '/' after the first 'lib': /stdcxx-4.2.2/build/lib/libstd.a
And what I don't like is that when BUILDTYPE is not specified, the name of library file
is always
libstd.{a;so} for any possible BUILDMODE values (even for empty BUILDMODE). The comments
in GNUMakefile says that BUILDTYPE and BUILDMODE both are optional and by default will be
used 11s, but this is not true...
Farid.
Farid Zaripov wrote: [...] >> Fix #2 -- Your /stdcxx-4.2.2/build file: >> >> I renamed the /stdcxx-4.2.2/build file that came with the svn download, to >> /stdcxx-4.2.1/build_faridz, because the presence of the build FILE was >> preventing the GNUmakefile from creating the /stdcxx-4.2.2/build/ DIRECTORY. > > Hmm, you must be wrong, we don't have any file with the name "build" in svn. Right. I think a "build" directory gets created automatically when one isn't specified on the command line (via BUILDDIR). Something weird seems to be going on in Steve's environment (the behavior of ln -s is definitely bizarre)... > > [...] > >> There is an /stdcxx-4.2.2/build/liblibstd.a file of size 2.33 MB. > > My congratulations, you have just build the stdcxx library :) Although it probably shouldn't be called liblibstd, should it? What's with the duplicate "lib" part? Martin
> I assume that you are building stdcxx-4.2.2 using Cygwin, and targeting > MinGW. My objective is to build stdcxx-4.2.2 using MinGW. I don't use Cygwin > and I don't plan to use it. Actually my goal is make it possible to build stdcxx/MinGW and stdcxx/Cygwin using Cygwin environment as well as stdcxx/MinGW using MSYS environment. > There were two fixes I had to make, to get the build of the patched > stdcxx-4.2.2 to run: [...] > On the three lines marked ** above, I added an explicit file name after the > $(buildpath) because the MinGW <ls> command, was REPLACING the > /stdcxx-4.2.1/build/ directory name, with a link (named /stdcxx-4.2.1/build) > to the file, instead of creating a link to the file (with the name of the > file), IN the /stdcxx-4.2.1/build/ directory. I have no such problems when running make on MSYS. > Fix #2 -- Your /stdcxx-4.2.2/build file: > > I renamed the /stdcxx-4.2.2/build file that came with the svn download, to > /stdcxx-4.2.1/build_faridz, because the presence of the build FILE was > preventing the GNUmakefile from creating the /stdcxx-4.2.2/build/ DIRECTORY. Hmm, you must be wrong, we don't have any file with the name "build" in svn. [...] > There is an /stdcxx-4.2.2/build/liblibstd.a file of size 2.33 MB. My congratulations, you have just build the stdcxx library :) > HOWEVER, the build ended with the following displayed on the MSYS console: When you run make without targets specified, the examples, tests, locales will be build. Not all tests are compiling without errors on gcc/MinGW at the moment. It is ok. You can build the library only (without examples, tests and so on) using this command: "make config lib" Also I suggest to explicitly specify the build type. I.e.: make BUILDDIR=/var/tmp/stdcxx-4.2.2/gcc/15d BUILDTYPE=15d config lib > In the line "make[1]: [tests] Error 2 (ignored)", does the "(ignored)" mean > that <make> did not terminate prematurely, and that file: > > /stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp > > is the last test source file to be compiled? I don't think so. The make should stop on the first error encountered unless make was executed with "-k" option specified. > According to the /stdcxx-4.2.2/README file, the last build step is the > locale databases. The build I ran left the /stdcxx-4.2.2/nls/ directory > completely EMPTY. Right, that because of make stopped on the compile error you mentioned above. > Please let me know -- did the build complete successfully? It depends on what you want :) You have build the stdcxx library successfully, so now you can compile your programs with stdcxx. > If not, and I > need to fix the 18.c.limits.stdcxx-988.cpp compile error, what changes to I > need to make to fix the compile error? 18.c.limits.stdcxx-988.cpp is just one of the regression tests. It was not verified on gcc/MinGW so it fails to compile. But this failure doesn't means that there is some problem or bug in stdcxx library. Farid.
Hi Martin, Thanks for your post. I'll keep your Jira tip in mind, for the future. * * * * * * I'm no longer working with stdcxx-4.2.1. Farid has notified me that stdcxx-4.2.2 is ported to MinGW, and he has provided a patch to apply the MinGW updates to stdcxx-4.2.2. The work I did on building stdcxx-4.2.1 using MinGW+MSYS wasn't wasted however, because one of the fixes I discovered (to GNUmakefile), is needed for using MinGW+MSYS to build stdcxx-4.2.2. Please see http://www.nabble.com/forum/ViewPost.jtp?post=20712556&framed=y for the results of my first build of stdcxx-4.2.2 using MinGW+MSYS. Steve ----- Original Message ----- From: "Martin Sebor" <msebor@gmail.com> To: <user@stdcxx.apache.org> Sent: Wednesday, November 26, 2008 6:32 PM Subject: Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2) > Steve Petrie wrote: >> Posting the files in the Nabble Message box hangs my Firefox (the file >> are >> quite big) so I'm trying the "Upload File..." button above the Nabble >> Message box... > > FYI: You can also open a Jira issue for the problems you're having > and attach the files to it. That might actually be even preferable. > > Martin > >> >> http://www.nabble.com/file/p20695038/config.h config.h >> http://www.nabble.com/file/p20695038/config.log config.log Martin Sebor-2 >> wrote: >>> >>> Could you post here the config.h and config.log files from the >>> $BUILDDIR/include directory? >>> >>> Martin >>> >>> >> >
Hi Farid,
I got stdcxx-4.2.2 from svn and applied the mingw.patch you provided.
I assume that you are building stdcxx-4.2.2 using Cygwin, and targeting
MinGW. My objective is to build stdcxx-4.2.2 using MinGW. I don't use Cygwin
and I don't plan to use it.
There were two fixes I had to make, to get the build of the patched
stdcxx-4.2.2 to run:
Fix #1 -- /stdcxx-4.2.2/CNUmakefile:
On lines 583, 591 and 592 of /stdcxx-4.2.2/GNUmakefile:
ln -sf $(TOPDIR)/GNUmakefile $(buildpath)/GNUmakefile;
\ **
ln -sf $(ETCDIR)/GNUmakefile.cfg $(buildpath)/include/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.lib $(LIBDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.rwt $(buildpath)/rwtest/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.exm $(EXMDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.tst $(TSTDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.ph $(PHTSTDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.bin $(BINDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/makefile.common $(buildpath)/makefile.common;
\ **
ln -sf $(ETCDIR)/makefile.rules $(buildpath)/makefile.rules;
\ **
ln -sf $(ETCDIR)/configure.sh $(buildpath)/include/configure;
\
ln -sf $(BINDIR)/exec $(buildpath)/run;
\
ln -sf $(BINDIR)/exec $(BINDIR)/run;
\
ln -sf $(ETCDIR)/run_locale_utils.sh $(BINDIR)/run_utils;
\
ln -sf $(BINDIR)/exec $(TSTDIR)/run;
\
ln -sf $(BINDIR)/exec $(PHTSTDIR)/run;
\
ln -sf $(BINDIR)/exec $(EXMDIR)/run
On the three lines marked ** above, I added an explicit file name after the
$(buildpath) because the MinGW <ls> command, was REPLACING the
/stdcxx-4.2.1/build/ directory name, with a link (named /stdcxx-4.2.1/build)
to the file, instead of creating a link to the file (with the name of the
file), IN the /stdcxx-4.2.1/build/ directory.
Fix #2 -- Your /stdcxx-4.2.2/build file:
I renamed the /stdcxx-4.2.2/build file that came with the svn download, to
/stdcxx-4.2.1/build_faridz, because the presence of the build FILE was
preventing the GNUmakefile from creating the /stdcxx-4.2.2/build/ DIRECTORY.
* * *
* * *
The build go a LOT further with the patched stdcxx-4.2.2 than it did with
the stdcxx-4.2.1.
According to Windows XP, the final size of the /stdcxx-4.2.1/build/
directory (including sub-directories) is 126 MB.
There is an /stdcxx-4.2.2/build/liblibstd.a file of size 2.33 MB.
HOWEVER, the build ended with the following displayed on the MSYS console:
<MSYS:>
[...]
generating dependencies for $(TOPDIR)/tests/self/0.alloc.cpp
gcc -M -I/stdcxx-4.2.2/include/ansi -I/stdcxx-4.2.2/include
-I/stdcxx-4.2.2/build/include -I/stdcxx-4.2.2/tests/include -pedantic
-nostdinc++ -mno-cygwin -W -Wall -Wcast-qual -Winline -Wshadow
-Wwrite-strings -Wno-long-long -Wcast-align
/stdcxx-4.2.2/tests/self/0.alloc.cpp
make[2]: Leaving directory `/stdcxx-4.2.2/build/tests'
make[2]: Entering directory `/stdcxx-4.2.2/build/tests'
[...]
gcc -c -I/stdcxx-4.2.2/include/ansi -I/stdcxx-4.2.2/include
-I/stdcxx-4.2.2/build/include -I/stdcxx-4.2.2/tests/include -pedantic
-nostdinc++ -mno-cygwin -W -Wall -Wcast-qual -Winline -Wshadow
-Wwrite-strings -Wno-long-long -Wcast-align
/stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp
i:/apps/stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp: In function
`int main()':
i:/apps/stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp:144: error:
`LONG_BIT' was not declared in this scope
i:/apps/stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp:145: error:
`_POSIX_SSIZE_MAX' was not declared in this scope
i:/apps/stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp:146: error:
`WORD_BIT' was not declared in this scope
i:/apps/stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp:151: warning:
this decimal constant is unsigned only in ISO C90
i:/apps/stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp:152: warning:
this decimal constant is unsigned only in ISO C90
i:/apps/stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp:144: warning:
unused variable 'LONG_BIT'
i:/apps/stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp:145: warning:
unused variable '_POSIX_SSIZE_MAX'
i:/apps/stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp:146: warning:
unused variable 'WORD_BIT'
make[2]: *** [18.c.limits.stdcxx-988.o] Error 1
make[2]: Leaving directory `/stdcxx-4.2.2/build/tests'
make[1]: [tests] Error 2 (ignored)
make[1]: Leaving directory `/stdcxx-4.2.2/build'
SteveP@DELL /stdcxx-4.2.2
$
</MSYS:>
In the line "make[1]: [tests] Error 2 (ignored)", does the "(ignored)" mean
that <make> did not terminate prematurely, and that file:
/stdcxx-4.2.2/tests/regress/18.c.limits.stdcxx-988.cpp
is the last test source file to be compiled?
According to the /stdcxx-4.2.2/README file, the last build step is the
locale databases. The build I ran left the /stdcxx-4.2.2/nls/ directory
completely EMPTY.
* * *
* * *
Please let me know -- did the build complete successfully? If not, and I
need to fix the 18.c.limits.stdcxx-988.cpp compile error, what changes to I
need to make to fix the compile error?
Thanks,
Steve
Farid Zaripov-2 wrote:
>
> Hi Steve.
>
>> I am trying to build stdcxx-4.2.1 on Windows XP (SP2), using the
>> MinGW(3.4.5) + MSYS(1.0.10) + (with gcc, g++, etc.)
>> operating environment.
>
> The 4.2.1 version of the stdcxx isn't ported to MinGW.
>
> You need to get (yet unreleased) 4.2.2 version from svn, i.e.:
>
> svn co http://svn.apache.org/repos/asf/stdcxx/branches/4.2.x
> stdcxx-4.2.2
>
> Then apply this patch: http://people.apache.org/~faridz/mingw.patch
>
> Farid.
>
>
--
View this message in context: http://www.nabble.com/Building-stdcxx-4.2.1-Using-MinGW%2BMSYS-On-Windows-XP-%28SP2%29-tp20672758p20712556.html
Sent from the stdcxx-user mailing list archive at Nabble.com.
Steve Petrie wrote: > Posting the files in the Nabble Message box hangs my Firefox (the file are > quite big) so I'm trying the "Upload File..." button above the Nabble > Message box... FYI: You can also open a Jira issue for the problems you're having and attach the files to it. That might actually be even preferable. Martin > > http://www.nabble.com/file/p20695038/config.h config.h > > http://www.nabble.com/file/p20695038/config.log config.log > > > Martin Sebor-2 wrote: >> >> Could you post here the config.h and config.log files from the >> $BUILDDIR/include directory? >> >> Martin >> >> >
Hi Farid,
Thanks for your response -- excellent news!
Please feel free to delete, from the stdcxx-user Nabble forum, my two latest
postings:
Steve Petrie Nov 26, 2008; 01:11am
Steve Petrie Nov 26, 2008; 12:27am
As they relate to further work I did on stdcxx-4.2.1, following up on
Martin's suggestions, before I received your email.
* * *
* * *
I will proceed to get stdcxx-4.2.2, apply the MinGW patch, and post the
results I get from a build, on the stdcxx-user Nabble forum.
Steve
----- Original Message -----
From: "Farid Zaripov" <Farid_Zaripov@epam.com>
To: <user@stdcxx.apache.org>
Sent: Wednesday, November 26, 2008 7:18 AM
Subject: RE: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
Hi Steve.
> I am trying to build stdcxx-4.2.1 on Windows XP (SP2), using the
> MinGW(3.4.5) + MSYS(1.0.10) + (with gcc, g++, etc.)
> operating environment.
The 4.2.1 version of the stdcxx isn't ported to MinGW.
You need to get (yet unreleased) 4.2.2 version from svn, i.e.:
svn co http://svn.apache.org/repos/asf/stdcxx/branches/4.2.x stdcxx-4.2.2
Then apply this patch: http://people.apache.org/~faridz/mingw.patch
Farid.
Hi Steve. > I am trying to build stdcxx-4.2.1 on Windows XP (SP2), using the > MinGW(3.4.5) + MSYS(1.0.10) + (with gcc, g++, etc.) > operating environment. The 4.2.1 version of the stdcxx isn't ported to MinGW. You need to get (yet unreleased) 4.2.2 version from svn, i.e.: svn co http://svn.apache.org/repos/asf/stdcxx/branches/4.2.x stdcxx-4.2.2 Then apply this patch: http://people.apache.org/~faridz/mingw.patch Farid.
Here's a paste of lines 939..956 from file /stdcxx-4.2.1/include/ansi/cwchar:
extern "C" {
inline wchar_t* wcsrchr (wchar_t *__s, wchar_t __c)
{
const wchar_t *__ss = __s;
while (*__ss++);
while (--__ss != __s && *__ss != __c);
return *__ss == __c ? __ss : 0;
}
} // extern "C"
inline const wchar_t* wcsrchr (const wchar_t *__s, wchar_t __c)
{
return wcsrchr (_RWSTD_CONST_CAST (wchar_t*, __s), __c);
}
} // extern "C"
If function wcsrchr on line 951 of file cwchar can't be extern "C", then
there appears to be an extraneous:
} // extern "C"
on line 956.
Martin Sebor-2 wrote:
>
>
>>
>>
>> i:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/../include/wchar.h:217:
>> error: previous declaration `wchar_t* wcsrchr(const wchar_t*, wchar_t)'
>> here
>> i:/apps/stdcxx-4.2.1/include/ansi/cwchar: In function `wchar_t*
>> wcsrchr(wchar_t*, wchar_t)':
>>
>> Also, it looks like there's an extern "C" { missing before the
>> declaration
>> of function wcsrchr on line 951 of file cwchar:
>
> No, that function is a C++ overload of the C function. It can't
> be extern "C" (C doesn't allow overloading).
>
> Martin
>
>
--
View this message in context: http://www.nabble.com/Building-stdcxx-4.2.1-Using-MinGW%2BMSYS-On-Windows-XP-%28SP2%29-tp20672758p20695299.html
Sent from the stdcxx-user mailing list archive at Nabble.com.
Posting the files in the Nabble Message box hangs my Firefox (the file are quite big) so I'm trying the "Upload File..." button above the Nabble Message box... http://www.nabble.com/file/p20695038/config.h config.h http://www.nabble.com/file/p20695038/config.log config.log Martin Sebor-2 wrote: > > > Could you post here the config.h and config.log files from the > $BUILDDIR/include directory? > > Martin > > -- View this message in context: http://www.nabble.com/Building-stdcxx-4.2.1-Using-MinGW%2BMSYS-On-Windows-XP-%28SP2%29-tp20672758p20695038.html Sent from the stdcxx-user mailing list archive at Nabble.com.
Steve Petrie wrote:
> Greetings,
>
> I am trying to build stdcxx-4.2.1 on Windows XP (SP2), using the
> MinGW(3.4.5) + MSYS(1.0.10) + (with gcc, g++, etc.) operating environment.
> Running make from an MSYS console.
I have no experience with building stdcxx on MinGW and don't have
access to the environment but I believe one of our developers has
ported stdcxx there so he should be able to answer some of your
questions. Farid, do you have any insight into Steve's problems?
Btw., it might be helpful to know the build type/mode you chose
for stdcxx, or if none, to try to explicitly specify a debug one
to see what happens. For example, to build an archive library
with debugging info, define BUILDTYPE=11s (alternatively,
BUILDMODE=debug) on the command line when invoking make.
In the meantime, let me try to answer some of the questions that
I think I might be able to help with.
>
[...]
> ** GNUmakefile / MinGW+MSYS Incompatibility #3 **
>
[...]
> I believe they fail because the directory /stdcxx-4.2.1/build/bin/ defined
> by the BINDIR variable BINDIR = $(buildpath)/bin contains no file called
> <exec> at the time that the ls commands execute.
>
> This problem I just ignored for the time being, because I didn't know what
> the file <exec> is supposed to contain.
Exec is a utility program that stdcxx uses to run its tests and
example programs in batch testing. It's only useful if you're
maintaining the project.
>
> * * *
> * * *
>
> ** GNUmakefile / MinGW+MSYS Incompatibility #4 **
[...]
> Lines 38..40 of file /stdcxx-4.2.1/build/include/vars.sh are:
>
> ...
> BUILDTAG= ; export BUILDTAG
> PLATFORM=mingw32_nt-5.1-1.0.10(0.46-3-2)-i86 ; export PLATFORM
> DEFAULT_SHROBJ= ; export DEFAULT_SHROBJ
> ...
>
>
> It appears that the make config process does not like the parentheses in the
> PLATFORM variable.
Right.
>
> PLATFORM := mingw32_nt-5.1-1.0.10(0.46-3-2)-i86
>
> I fixed the problem by adjusting the relevant statement in the GNUmakefile
> to read:
>
> PLATFORM := mingw32_nt-5.1-1.0.10-0.46-3-2--i86
>
> changing the "(" and ")" to "-".
The right fix is to do something similar to what we do for Cygwin.
>
> The above syntax error problem is fixed, but what about all the "no"
> messages, and the "--" message(s) I am seeing on the MSYS console? Are they
> normal or do they indicate an invalid build?
The "no" messages are expected. There should be no "--" messages.
They usually indicate a configuration problem.
Could you post here the config.h and config.log files from the
$BUILDDIR/include directory?
>
> * * *
> * * *
>
> ** GNUmakefile / MinGW+MSYS Incompatibility #5 **
>
[...]
> The error:
>
>
> i:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/../include/wchar.h:204:
> error: previous declaration `wchar_t* wcschr(const wchar_t*, wchar_t)' here
>
> is puzzling. Why is the stdcxx-4.2.1 build examining the MinGW
> /MinGW/include/ library?
The stdcxx C++ headers "expose" symbols declared in the underlying
C library (like printf() or wcschr()). Not all the symbols defined
in the C library are always declared in the C library headers. The
stdcxx configuration machinery tries to detect this so that our
headers can declare the symbols. When the configuration tests fail
for a reason other than the one they're designed to fail for as
may be the case here (not because the symbol isn't declared but
because it's declared wrong), the library still tries to declare
the symbol the "right way" and the right declaration in stdcxx
conflicts with the wrong one. It's a limitation/bug in stdcxx.
>
> I temporarily worked around this problem by changing line 204 of the the
> MinGW wchar.h file to conform with the /stdcxx-4.2.1/include/ansi/cwchar
> declaration of the C function `wchar_t* wcschr(wchar_t*, wchar_t), and this
> eliminated the error message.
>
> The error:
>
> i:/apps/stdcxx-4.2.1/include/ansi/cwchar:725: error: expected
> nested-name-specifier before "wcscspn"
>
> seemed legitimate, as the "::" qualifier before the "wcscspn" was missing.
> So I added the "::" qualifier to the line 725 in the
> /stdcxx-4.2.1/include/ansi/cwchar file.
That looks like the right fix. We made the same change in 4.2.2
to resolve STDCXX-663:
https://issues.apache.org/jira/browse/STDCXX-663
>
> * * *
> * * *
>
> ** GNUmakefile / MinGW+MSYS Incompatibility #6 **
>
> With the above-mentioned fixes in place, the build failed further on, with a
> bunch of additional errors:
>
[...]
>
> There's another conflict with file wchar.h in the MinGW /MinGW/include/
> library:
It seems the <wchar.h> header on MinGW is non-conforming in a way
that we're not prepared to deal with (we normally try to adjust to
these kinds of things but the machinery isn't perfect).
>
>
> i:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/../include/wchar.h:217:
> error: previous declaration `wchar_t* wcsrchr(const wchar_t*, wchar_t)' here
> i:/apps/stdcxx-4.2.1/include/ansi/cwchar: In function `wchar_t*
> wcsrchr(wchar_t*, wchar_t)':
>
> Also, it looks like there's an extern "C" { missing before the declaration
> of function wcsrchr on line 951 of file cwchar:
No, that function is a C++ overload of the C function. It can't
be extern "C" (C doesn't allow overloading).
>
> inline const wchar_t* wcsrchr (const wchar_t *__s, wchar_t __c)
>
> Finally, there are a whole bunch of macro errors, in several files like:
>
> ...
> i:/apps/stdcxx-4.2.1/include/ansi/cwchar:919:1: unterminated #else
> ...
> i:/apps/stdcxx-4.2.1/include/rw/_mbstate.h:131:1: unterminated #else
> ...
> i:/apps/stdcxx-4.2.1/include/rw/_traits.h:39:1: unterminated #ifndef
> ...
> i:/apps/stdcxx-4.2.1/include/rw/_strref.h:47:1: unterminated #ifndef
> ...
> i:/apps/stdcxx-4.2.1/include/string:30:1: unterminated #ifndef
> ...
> i:/apps/stdcxx-4.2.1/include/bitset:30:1: unterminated #ifndef
They're probably all fallout from a single unterminated preprocessor
directive, quite possibly the first one in <cwchar>.
>
> * * *
> * * *
>
> At this point, I decided that I must be doing something VERY WRONG in
> running the build, so I backed out the changes I made to the two source
> files:
>
> /MinGW/include/wchar.h
> /stdcxx-4.2.1/include/ansi/cwchar
>
> and decided to post a message to stdcxx-user.
>
> Any suggestions would be most welcome.
I wonder if there are other problems or if <wchar.h> is the only one.
One way to find out while you're waiting for Farid's input might be
to apply the change below to see haw much further you can get in the
build. Alternatively, try a debug build where, AFAIK, stdcxx doesn't
#include <cwchar> anywhere.
--- cwchar 2008-11-25 18:33:27.000000000 -0700
+++ cwchar.1 2008-11-25 18:33:47.000000000 -0700
@@ -29,7 +29,7 @@
#include <rw/_defs.h>
-#ifndef _RWSTD_NO_PURE_C_HEADERS
+#if 1 // ndef _RWSTD_NO_PURE_C_HEADERS
# include <ansi/_cwchar.h>
#else
Martin
Greetings,
I am trying to build stdcxx-4.2.1 on Windows XP (SP2), using the
MinGW(3.4.5) + MSYS(1.0.10) + (with gcc, g++, etc.) operating environment.
Running make from an MSYS console.
The MinGW + MSYS, etc. seems to be working OK, when used by the NetBeans 6.5
IDE C/C++ plugin. Using NetBeans 6.5 I have successfully compiled, linked
and tested a couple of simple programs, that use cin and cout from the
standard library shipped with the g++ that comes with MinGW.
I have never tried to build anything directly with make before, let alone
anything as complicated as the Apache C++ Standard Library. I've always used
make through the intermediation of an IDE:
Metrowerks CodeWarrior
Microsoft VC++ 2005 Express
NetBeans 6.5 C/C++
* * *
* * *
(
I have searched the Apache archive without success, for tips on building
stdcxx-4.2.1 Using MinGW+MSYS, so I'm posting here.
There was one page I found:
http://mail-archives.apache.org/mod_mbox/xerces-c-dev/200708.mbox/%3C46CC9F94.60603@perforce.com%3E
...
> Hi Charles,
>
> Charles McLouth <cmclouth@perforce.com> writes:
>
>> As an FYI I tested the zip file with mingw-msys on windows and all
built
>> correctly and linked with the samples. Below is the specific
configure
>> options I used (even testing the new static option):
>> runConfigure -p mingw-msys -c gcc -x g++ -m inmem -n winsock -t Win32
>> runConfigure -p mingw-msys -d -c gcc -x g++ -m inmem -n winsock -t
Win32
>> runConfigure -p mingw-msys -s -c gcc -x g++ -m inmem -n winsock -t
Win32
>> runConfigure -p mingw-msys -d -s -c gcc -x g++ -m inmem -n winsock -t
Win32
>
...
But so far as I can tell, this is referring to the ability of the Cygwin
tools to generate mingw-msys compatible libraries, and not what I'm trying
to do, which is to build stdcxx-4.2.1 using MinGW+MSYS On Windows XP.
)
* * *
* * *
I'm running just plain make (with no command line parameters) at the MSYS
console prompt, in $TOPDIR, which is /i/apps/stdcxx-4.2.1/ in MSYS (mapped
from I:\APPS\stdcxx-4.2.1\ in Windows).
So far I have found and worked around some incompatibilities between: (A)
the GNUmakefile (616588 2008-01-30 02:10:55Z) shipped in stdcxx-4.2.1.tar.gz
and (B) the "POSIX" environment emulated by MinGW+MSYS. Please see the
sections below:
** GNUmakefile / MinGW+MSYS Incompatibility #1 **
thru
** GNUmakefile / MinGW+MSYS Incompatibility #5 **
for the fixes I have tried.
At section:
** GNUmakefile / MinGW+MSYS Incompatibility #6 **
below, I decided that, given my inexperience with the exciting world of make
and Standard Library building, I'd better get in touch with the experts who
programmed the Apache C++ Standard Library library, and who have already
successfully built it a few thoussand times.
* * *
* * *
** GNUmakefile / MinGW+MSYS Incompatibility #1 **
The last line of the following code snippet from GNUmakefile (lines
542..546) fails:
# harmonize all the different Intel IA32 chips
PLATFORM := $(subst i486,i86,$(PLATFORM))
PLATFORM := $(subst i586,i86,$(PLATFORM))
PLATFORM := $(subst i686,i86,$(PLATFORM))
PLATFORM := $(shell echo $(PLATFORM) | tr "[:upper:]" "[:lower:]")
so I commented the lines out and forced:
PLATFORM := mingw32_nt-5.1-1.0.10(0.46-3-2)-i86
(On my MSYS, the uname command prints: MINGW32_NT-5.1).
* * *
* * *
** GNUmakefile / MinGW+MSYS Incompatibility #2 **
In the make-builddir function (lines 574..599) from GNUmakefile, the
following snippet:
ln -sf $(TOPDIR)/GNUmakefile $(buildpath);
\ **
ln -sf $(ETCDIR)/GNUmakefile.cfg $(buildpath)/include/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.lib $(LIBDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.rwt $(buildpath)/rwtest/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.exm $(EXMDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.tst $(TSTDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.ph $(PHTSTDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.bin $(BINDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/makefile.common $(buildpath);
\ **
ln -sf $(ETCDIR)/makefile.rules $(buildpath);
\ **
ln -sf $(ETCDIR)/configure.sh $(buildpath)/include/configure;
\
ln -sf $(BINDIR)/exec $(buildpath)/run;
\
ln -sf $(BINDIR)/exec $(BINDIR)/run;
\
ln -sf $(ETCDIR)/run_locale_utils.sh $(BINDIR)/run_utils;
\
ln -sf $(BINDIR)/exec $(TSTDIR)/run;
\
ln -sf $(BINDIR)/exec $(PHTSTDIR)/run;
\
ln -sf $(BINDIR)/exec $(EXMDIR)/run
has 3 ls commands (marked ** above) that specify a directory (i.e. that do
not specify a file). These commands are of the form:
ls -sf file dir
and according to my UNIX book, for this form of the ls command: "ls creates
a link in <dir> to <file>. However, MSYS does NOT create a link IN <dir>
but
REPLACES <dir> with a link to <file>, naming the link the same as <dir>.
So when the above snippet in function make-builddir has finished executing,
DIRECTORY /stdcxx-4.2.1/build/ has been replaced by a FILE
/stdcxx-4.2.1/build linked to file /stdcxx-4.2.1/etc/config/makefile.rules
I worked around this problem, by changing the 3 ls commands (marked **
above) so that they are of the form:
ln -sf $(TOPDIR)/GNUmakefile $(buildpath)/GNUmakefile;
\
...
ln -sf $(ETCDIR)/makefile.common $(buildpath)/makefile.common;
\
ln -sf $(ETCDIR)/makefile.rules $(buildpath)/makefile.rules;
\
...
* * *
* * *
** GNUmakefile / MinGW+MSYS Incompatibility #3 **
In the same make-builddir function (lines 574..599) as above, in the same
snippet:
ln -sf $(TOPDIR)/GNUmakefile $(buildpath);
\
ln -sf $(ETCDIR)/GNUmakefile.cfg $(buildpath)/include/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.lib $(LIBDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.rwt $(buildpath)/rwtest/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.exm $(EXMDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.tst $(TSTDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.ph $(PHTSTDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/GNUmakefile.bin $(BINDIR)/GNUmakefile;
\
ln -sf $(ETCDIR)/makefile.common $(buildpath);
\
ln -sf $(ETCDIR)/makefile.rules $(buildpath);
\
ln -sf $(ETCDIR)/configure.sh $(buildpath)/include/configure;
\
ln -sf $(BINDIR)/exec $(buildpath)/run;
\ **
ln -sf $(BINDIR)/exec $(BINDIR)/run;
\ **
ln -sf $(ETCDIR)/run_locale_utils.sh $(BINDIR)/run_utils;
\
ln -sf $(BINDIR)/exec $(TSTDIR)/run;
\ **
ln -sf $(BINDIR)/exec $(PHTSTDIR)/run;
\ **
ln -sf $(BINDIR)/exec $(EXMDIR)/run
**
when the make-builddir function executes, the 5 ls commands (marked **
above) fail and display the following on the MSYS console:
creating BUILDDIR=/stdcxx-4.2.1/build
ln: creating symbolic link `/stdcxx-4.2.1/build/run' to
`/stdcxx-4.2.1/build/bin/exec': No such file or directory
ln: creating symbolic link `/stdcxx-4.2.1/build/bin/run' to
`/stdcxx-4.2.1/build/bin/exec': No such file or directory
ln: creating symbolic link `/stdcxx-4.2.1/build/tests/run' to
`/stdcxx-4.2.1/build/bin/exec': No such file or directory
ln: creating symbolic link `/stdcxx-4.2.1/build/plumhall/run' to
`/stdcxx-4.2.1/build/bin/exec': No such file or directory
ln: creating symbolic link `/stdcxx-4.2.1/build/examples/run' to
`/stdcxx-4.2.1/build/bin/exec': No such file or directory
I believe they fail because the directory /stdcxx-4.2.1/build/bin/ defined
by the BINDIR variable BINDIR = $(buildpath)/bin contains no file called
<exec> at the time that the ls commands execute.
This problem I just ignored for the time being, because I didn't know what
the file <exec> is supposed to contain.
* * *
* * *
** GNUmakefile / MinGW+MSYS Incompatibility #4 **
In what appears to me to be another iteration of the GNUmakefile during its
ececution, the following is displayed on the MSYS console:
...
make[2]: Entering directory `/stdcxx-4.2.1/build/include'
make config
make[3]: Entering directory `/stdcxx-4.2.1/build/include'
configuring stdcxx 4.2.1 for gcc-3.4.5 on
mingw32_nt-5.1-1.0.10(0.46-3-2)-i86
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
/stdcxx-4.2.1/etc/config/src/libc_decl.sh: ./vars.sh: line 39: syntax
error near unexpected token `PLATFORM=mingw32_nt-5.1-1.0.10(0'
/stdcxx-4.2.1/etc/config/src/libc_decl.sh: ./vars.sh: line 39:
`PLATFORM=mingw32_nt-5.1-1.0.10(0.46-3-2)-i86 ; export PLATFORM'
checking for <cassert> no (_RWSTD_NO_CASSERT)
checking for <assert.h> ok
("i:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/assert.h")
checking for <cctype> no (_RWSTD_NO_CCTYPE)
checking for <ctype.h> ok
("i:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/ctype.h")
checking for <cerrno> no (_RWSTD_NO_CERRNO)
checking for <errno.h> ok
("i:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/errno.h")
...
Lines 38..40 of file /stdcxx-4.2.1/build/include/vars.sh are:
...
BUILDTAG= ; export BUILDTAG
PLATFORM=mingw32_nt-5.1-1.0.10(0.46-3-2)-i86 ; export PLATFORM
DEFAULT_SHROBJ= ; export DEFAULT_SHROBJ
...
It appears that the make config process does not like the parentheses in the
PLATFORM variable.
PLATFORM := mingw32_nt-5.1-1.0.10(0.46-3-2)-i86
I fixed the problem by adjusting the relevant statement in the GNUmakefile
to read:
PLATFORM := mingw32_nt-5.1-1.0.10-0.46-3-2--i86
changing the "(" and ")" to "-".
The above syntax error problem is fixed, but what about all the "no"
messages, and the "--" message(s) I am seeing on the MSYS console? Are they
normal or do they indicate an invalid build?
* * *
* * *
** GNUmakefile / MinGW+MSYS Incompatibility #5 **
Further along in the build proces, with all the above-mentioned fixes in
place, the build terminated with the following displayed on the MSYS
console:
generating dependencies for $(TOPDIR)/src/assert.cpp
gcc -M -I/stdcxx-4.2.1/include/ansi -I/stdcxx-4.2.1/include
-I/stdcxx-4.2.1/build/include -pedantic -nostdinc++ -W -Wall -Wcast-qual
-Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
/stdcxx-4.2.1/src/assert.cpp
make[2]: Leaving directory `/stdcxx-4.2.1/build/lib'
make[2]: Entering directory `/stdcxx-4.2.1/build/lib'
gcc -c -I/stdcxx-4.2.1/include/ansi -I/stdcxx-4.2.1/include
-I/stdcxx-4.2.1/build/include -pedantic -nostdinc++ -W -Wall -Wcast-qual
-Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
/stdcxx-4.2.1/src/assert.cpp
gcc -c -I/stdcxx-4.2.1/include/ansi -I/stdcxx-4.2.1/include
-I/stdcxx-4.2.1/build/include -pedantic -nostdinc++ -W -Wall -Wcast-qual
-Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
/stdcxx-4.2.1/src/atomic-cxx.S
gcc -c -I/stdcxx-4.2.1/include/ansi -I/stdcxx-4.2.1/include
-I/stdcxx-4.2.1/build/include -pedantic -nostdinc++ -W -Wall -Wcast-qual
-Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
/stdcxx-4.2.1/src/bitset.cpp
In file included from i:/apps/stdcxx-4.2.1/include/rw/_mbstate.h:195,
from i:/apps/stdcxx-4.2.1/include/rw/_traits.h:40,
from i:/apps/stdcxx-4.2.1/include/rw/_strref.h:48,
from i:/apps/stdcxx-4.2.1/include/string:43,
from i:/apps/stdcxx-4.2.1/include/bitset:34,
from i:/apps/stdcxx-4.2.1/src/bitset.cpp:31:
i:/apps/stdcxx-4.2.1/include/ansi/cwchar: In function `wchar_t*
wcschr(wchar_t*, wchar_t)':
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:613: error: declaration of C
function `wchar_t* wcschr(wchar_t*, wchar_t)' conflicts with
i:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/../include/wchar.h:204:
error: previous declaration `wchar_t* wcschr(const wchar_t*, wchar_t)' here
i:/apps/stdcxx-4.2.1/include/ansi/cwchar: At global scope:
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:725: error: expected
nested-name-specifier before "wcscspn"
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:725: confused by earlier errors,
bailing out
make[2]: *** [bitset.o] Error 1
make[2]: Leaving directory `/stdcxx-4.2.1/build/lib'
make[1]: *** [lib] Error 2
make[1]: Leaving directory `/stdcxx-4.2.1/build'
make: *** [libstd] Error 2
SteveP@DELL /stdcxx-4.2.1
The error:
i:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/../include/wchar.h:204:
error: previous declaration `wchar_t* wcschr(const wchar_t*, wchar_t)' here
is puzzling. Why is the stdcxx-4.2.1 build examining the MinGW
/MinGW/include/ library?
I temporarily worked around this problem by changing line 204 of the the
MinGW wchar.h file to conform with the /stdcxx-4.2.1/include/ansi/cwchar
declaration of the C function `wchar_t* wcschr(wchar_t*, wchar_t), and this
eliminated the error message.
The error:
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:725: error: expected
nested-name-specifier before "wcscspn"
seemed legitimate, as the "::" qualifier before the "wcscspn" was missing.
So I added the "::" qualifier to the line 725 in the
/stdcxx-4.2.1/include/ansi/cwchar file.
* * *
* * *
** GNUmakefile / MinGW+MSYS Incompatibility #6 **
With the above-mentioned fixes in place, the build failed further on, with a
bunch of additional errors:
generating dependencies for $(TOPDIR)/src/assert.cpp
gcc -M -I/stdcxx-4.2.1/include/ansi -I/stdcxx-4.2.1/include
-I/stdcxx-4.2.1/build/include -pedantic -nostdinc++ -W -Wall -Wcast-qual
-Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
/stdcxx-4.2.1/src/assert.cpp
make[2]: Leaving directory `/stdcxx-4.2.1/build/lib'
make[2]: Entering directory `/stdcxx-4.2.1/build/lib'
gcc -c -I/stdcxx-4.2.1/include/ansi -I/stdcxx-4.2.1/include
-I/stdcxx-4.2.1/build/include -pedantic -nostdinc++ -W -Wall -Wcast-qual
-Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
/stdcxx-4.2.1/src/assert.cpp
gcc -c -I/stdcxx-4.2.1/include/ansi -I/stdcxx-4.2.1/include
-I/stdcxx-4.2.1/build/include -pedantic -nostdinc++ -W -Wall -Wcast-qual
-Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
/stdcxx-4.2.1/src/atomic-cxx.S
gcc -c -I/stdcxx-4.2.1/include/ansi -I/stdcxx-4.2.1/include
-I/stdcxx-4.2.1/build/include -pedantic -nostdinc++ -W -Wall -Wcast-qual
-Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align
/stdcxx-4.2.1/src/bitset.cpp
In file included from i:/apps/stdcxx-4.2.1/include/rw/_mbstate.h:195,
from i:/apps/stdcxx-4.2.1/include/rw/_traits.h:40,
from i:/apps/stdcxx-4.2.1/include/rw/_strref.h:48,
from i:/apps/stdcxx-4.2.1/include/string:43,
from i:/apps/stdcxx-4.2.1/include/bitset:34,
from i:/apps/stdcxx-4.2.1/src/bitset.cpp:31:
i:/apps/stdcxx-4.2.1/include/ansi/cwchar: In function `wchar_t*
wcsrchr(wchar_t*, wchar_t)':
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:944: error: declaration of C
function `wchar_t* wcsrchr(wchar_t*, wchar_t)' conflicts with
i:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/../include/wchar.h:217:
error: previous declaration `wchar_t* wcsrchr(const wchar_t*, wchar_t)' here
i:/apps/stdcxx-4.2.1/include/ansi/cwchar: In function `wchar_t*
wcsrchr(wchar_t*, wchar_t)':
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:948: error: invalid conversion
from `const wchar_t*' to `wchar_t*'
i:/apps/stdcxx-4.2.1/include/ansi/cwchar: At global scope:
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:958: error: expected declaration
before '}' token
In file included from i:/apps/stdcxx-4.2.1/include/rw/_mbstate.h:195,
from i:/apps/stdcxx-4.2.1/include/rw/_traits.h:40,
from i:/apps/stdcxx-4.2.1/include/rw/_strref.h:48,
from i:/apps/stdcxx-4.2.1/include/string:43,
from i:/apps/stdcxx-4.2.1/include/bitset:34,
from i:/apps/stdcxx-4.2.1/src/bitset.cpp:31:
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:919:1: unterminated #else
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:99:1: unterminated #if
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:87:1: unterminated #if
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:65:1: unterminated #ifndef
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:36:1: unterminated #else
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:32:1: unterminated #else
In file included from i:/apps/stdcxx-4.2.1/include/rw/_traits.h:40,
from i:/apps/stdcxx-4.2.1/include/rw/_strref.h:48,
from i:/apps/stdcxx-4.2.1/include/string:43,
from i:/apps/stdcxx-4.2.1/include/bitset:34,
from i:/apps/stdcxx-4.2.1/src/bitset.cpp:31:
i:/apps/stdcxx-4.2.1/include/rw/_mbstate.h:131:1: unterminated #else
i:/apps/stdcxx-4.2.1/include/rw/_mbstate.h:40:1: unterminated #elif
i:/apps/stdcxx-4.2.1/include/rw/_mbstate.h:32:1: unterminated #ifndef
In file included from i:/apps/stdcxx-4.2.1/include/rw/_strref.h:48,
from i:/apps/stdcxx-4.2.1/include/string:43,
from i:/apps/stdcxx-4.2.1/include/bitset:34,
from i:/apps/stdcxx-4.2.1/src/bitset.cpp:31:
i:/apps/stdcxx-4.2.1/include/rw/_traits.h:39:1: unterminated #ifndef
i:/apps/stdcxx-4.2.1/include/rw/_traits.h:32:1: unterminated #ifndef
In file included from i:/apps/stdcxx-4.2.1/include/string:43,
from i:/apps/stdcxx-4.2.1/include/bitset:34,
from i:/apps/stdcxx-4.2.1/src/bitset.cpp:31:
i:/apps/stdcxx-4.2.1/include/rw/_strref.h:47:1: unterminated #ifndef
i:/apps/stdcxx-4.2.1/include/rw/_strref.h:32:1: unterminated #ifndef
In file included from i:/apps/stdcxx-4.2.1/include/bitset:34,
from i:/apps/stdcxx-4.2.1/src/bitset.cpp:31:
i:/apps/stdcxx-4.2.1/include/string:30:1: unterminated #ifndef
In file included from i:/apps/stdcxx-4.2.1/src/bitset.cpp:31:
i:/apps/stdcxx-4.2.1/include/bitset:30:1: unterminated #ifndef
make[2]: *** [bitset.o] Error 1
make[2]: Leaving directory `/stdcxx-4.2.1/build/lib'
make[1]: *** [lib] Error 2
make[1]: Leaving directory `/stdcxx-4.2.1/build'
make: *** [libstd] Error 2
SteveP@DELL /stdcxx-4.2.1
There's another conflict with file wchar.h in the MinGW /MinGW/include/
library:
i:/apps/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/../include/wchar.h:217:
error: previous declaration `wchar_t* wcsrchr(const wchar_t*, wchar_t)' here
i:/apps/stdcxx-4.2.1/include/ansi/cwchar: In function `wchar_t*
wcsrchr(wchar_t*, wchar_t)':
Also, it looks like there's an extern "C" { missing before the declaration
of function wcsrchr on line 951 of file cwchar:
inline const wchar_t* wcsrchr (const wchar_t *__s, wchar_t __c)
Finally, there are a whole bunch of macro errors, in several files like:
...
i:/apps/stdcxx-4.2.1/include/ansi/cwchar:919:1: unterminated #else
...
i:/apps/stdcxx-4.2.1/include/rw/_mbstate.h:131:1: unterminated #else
...
i:/apps/stdcxx-4.2.1/include/rw/_traits.h:39:1: unterminated #ifndef
...
i:/apps/stdcxx-4.2.1/include/rw/_strref.h:47:1: unterminated #ifndef
...
i:/apps/stdcxx-4.2.1/include/string:30:1: unterminated #ifndef
...
i:/apps/stdcxx-4.2.1/include/bitset:30:1: unterminated #ifndef
* * *
* * *
At this point, I decided that I must be doing something VERY WRONG in
running the build, so I backed out the changes I made to the two source
files:
/MinGW/include/wchar.h
/stdcxx-4.2.1/include/ansi/cwchar
and decided to post a message to stdcxx-user.
Any suggestions would be most welcome.
--
View this message in context: http://www.nabble.com/Building-stdcxx-4.2.1-Using-MinGW%2BMSYS-On-Windows-XP-%28SP2%29-tp20672758p20672758.html
Sent from the stdcxx-user mailing list archive at Nabble.com.
Misha Aizatulin wrote:
> hi all,
>
> at the very end of http://stdcxx.apache.org/doc/stdlibug/34-2.html
> there is an example of using a reference to create a "copy" of cout.
> However this example doesn't initialize the defined reference at once
> (which is required in C++) and for this reason doesn't compile with my
> gcc 4.2.1.
That's definitely incorrect. The uninitialized reference is not
C++ and as noted in LWG issue 50, stream objects are not copyable.
The next C++ Standard makes that explicit by declaring the copy
ctor and copy assignment operator of class ios_base deleted.
I opened STDCXX-1024 to have the problematic example removed:
http://issues.apache.org/jira/browse/STDCXX-1024
LWG issue #50 for reference
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#50
Thanks for pointing it out!
Martin
>
> For convenience here is the example:
>
> int main(int argc, char *argv[])
> {
> std::ostream& fr;
> if (argc > 1)
> fr = *(new std::ofstream(argv[1]));
> else
> fr = std::cout;
>
> fr << "Hello world!" << std::endl;
>
> if (&fr!=&std::cout)
> delete(&fr);
> }
>
> Cheers,
> Misha
>
hi all,
at the very end of http://stdcxx.apache.org/doc/stdlibug/34-2.html
there is an example of using a reference to create a "copy" of cout.
However this example doesn't initialize the defined reference at once
(which is required in C++) and for this reason doesn't compile with my
gcc 4.2.1.
For convenience here is the example:
int main(int argc, char *argv[])
{
std::ostream& fr;
if (argc > 1)
fr = *(new std::ofstream(argv[1]));
else
fr = std::cout;
fr << "Hello world!" << std::endl;
if (&fr!=&std::cout)
delete(&fr);
}
Cheers,
Misha
Steve Petrie wrote: > I tried your suggestion of using an Apache mirror. I picked: > > mirror.csclub.uwaterloo.ca > > and it worked fine -- Firefox 3.0.3 downloaded the file stdcxx-4.2.1.tar.gz > WITHOUT TRUNCATION. > > The MD5 checksum on the file is correct. > > 7-Zip opened the .gx and the .tar without error, and extracted both without > error, creating what looks like a valid directory tree with around 48 MB of > files. > > * * * > * * * Good to hear! > > I'm going to try the download again from the Apache web site Downloads page, > to make sure that the file truncation problem still exists with that site. > I'll let you know ONLY if the problem DOES NOT exist anymore. > > If the problem still exists, and Apache wants to try to fix the problem on > the Apache web site, just let me know and I'll be happy to act as tester > with Firefox 3.0.3 under Windows XP (SP2). Thanks for the offer. Martin > > Steve > > > Martin Sebor-2 wrote: >> >> I'm not sure what the problem is. No one has reported anything >> like this and I just downloaded 4.2.1 using Firefox 3.0.2 on >> Linux without any issues. I don't have access to a Windows >> machine at the moment but I'll see if I can find one that has >> Firefox 3.0.3 installed to see if I can reproduce it there. >> If not, you might want to try to ftp it from one of the Apache >> mirrors: http://www.apache.org/dyn/closer.cgi#ftp >> >> Martin >> >>
I tried your suggestion of using an Apache mirror. I picked: mirror.csclub.uwaterloo.ca and it worked fine -- Firefox 3.0.3 downloaded the file stdcxx-4.2.1.tar.gz WITHOUT TRUNCATION. The MD5 checksum on the file is correct. 7-Zip opened the .gx and the .tar without error, and extracted both without error, creating what looks like a valid directory tree with around 48 MB of files. * * * * * * I'm going to try the download again from the Apache web site Downloads page, to make sure that the file truncation problem still exists with that site. I'll let you know ONLY if the problem DOES NOT exist anymore. If the problem still exists, and Apache wants to try to fix the problem on the Apache web site, just let me know and I'll be happy to act as tester with Firefox 3.0.3 under Windows XP (SP2). Steve Martin Sebor-2 wrote: > > > I'm not sure what the problem is. No one has reported anything > like this and I just downloaded 4.2.1 using Firefox 3.0.2 on > Linux without any issues. I don't have access to a Windows > machine at the moment but I'll see if I can find one that has > Firefox 3.0.3 installed to see if I can reproduce it there. > If not, you might want to try to ftp it from one of the Apache > mirrors: http://www.apache.org/dyn/closer.cgi#ftp > > Martin > > -- View this message in context: http://www.nabble.com/File-truncation-Problem-Downloading-stdcxx-4.2.1.tar.gz-tp20452964p20465223.html Sent from the stdcxx-user mailing list archive at Nabble.com.
Steve Petrie wrote: > Greetings, > > (I have searched the Apache archive without success, for tips on > downloading, so I'm posting here.) > > I am trying to download the file stdcxx-4.2.1.tar.gz from > www.apache.org/dist/stdcxx/ using Firefox 3.0.3 (Using Windows XP SP2.). > > Small files download ok, e.g. the MD5 sum files, but large files e.g. > stdcxx-4.2.1.tar.gz and stdcxx-incubating-4.2.0.tar.gz are giving a file > truncation problem. I'm not sure what the problem is. No one has reported anything like this and I just downloaded 4.2.1 using Firefox 3.0.2 on Linux without any issues. I don't have access to a Windows machine at the moment but I'll see if I can find one that has Firefox 3.0.3 installed to see if I can reproduce it there. If not, you might want to try to ftp it from one of the Apache mirrors: http://www.apache.org/dyn/closer.cgi#ftp Martin > > The Firefox download in progress displays the file size of 6.9 MB in the > download dialog. The download appears to complete ssuccessfully, but the > file size actually stored on my disk drive is only 4.6 MB. The MD5 checksum > calculated on the truncated file, of course does not match the value > provided by the Apache web site. > > When I try to unpack the stdcxx-4.2.1.tar.gz file, using 7-Zip 4.57, the .gz > opens ok, but when I open the .tar, at "95% Copying" I get a "Data error in > 'stdcxx-4.2.1.tar'. File is broken" message. WinZip gave me similar > problems. > > Internet Explorer 6.0 -- displays the file size of 6.9 MB in the download > dialog, and indicates a successful completion of transfer, but the file size > actually stored is only 4.6 MB. (Same as with Firefox 3.0.3). > > I have downloaded lots of binary files much bigger than these stdcxx files, > from other sites, using Firefox 3.0.3, without any problems. > > * * * > * * * > > Using FileZilla with archive.apache.org 80, I get the following log: > > Status: Selected port usually in use by a different protocol. > Status: Resolving address of archive.apache.org > Status: Connecting to 140.211.11.130:80... > Status: Connection established, waiting for welcome message... > Error: Connection timed out > Trace: CFtpControlSocket::ResetOperation(2114) > Trace: CControlSocket::ResetOperation(2114) > Error: Could not connect to server > > but FileZilla works fine with other sites. > > Using command line ftp, the connection times out: > > ftp> open www.apache.org 80 > Connected to www.apache.org. > Connection closed by remote host. > > ftp> open www.apache.org 80 > Connected to www.apache.org. > Connection closed by remote host. > > but I can connect with command line ftp to other sites with no problem. > > * * * > * * * > > I use Kaspersky Internet Security, and I have downloaded lots of binary > files much bigger than these stdcxx files, using Firefox 3.0.3, without any > problems. > > I tried disabling the Kaspersky firewall, and then diabling all of > Kaspersky, but I still get the same file truncation problem with > stdcxx-s4.2.1.tar.gz. > > I can connect ok to other ftp sites with Kaspersky firewall enabled. > > * * * > * * * > > I really want to use the Apache C++ Standard Library with the GNU C++ > compiler, because the Apache product seems to me to be superior to what > comes with G++. > > Any suggestions would be most appreciated! > > > > >
Greetings, (I have searched the Apache archive without success, for tips on downloading, so I'm posting here.) I am trying to download the file stdcxx-4.2.1.tar.gz from www.apache.org/dist/stdcxx/ using Firefox 3.0.3 (Using Windows XP SP2.). Small files download ok, e.g. the MD5 sum files, but large files e.g. stdcxx-4.2.1.tar.gz and stdcxx-incubating-4.2.0.tar.gz are giving a file truncation problem. The Firefox download in progress displays the file size of 6.9 MB in the download dialog. The download appears to complete ssuccessfully, but the file size actually stored on my disk drive is only 4.6 MB. The MD5 checksum calculated on the truncated file, of course does not match the value provided by the Apache web site. When I try to unpack the stdcxx-4.2.1.tar.gz file, using 7-Zip 4.57, the .gz opens ok, but when I open the .tar, at "95% Copying" I get a "Data error in 'stdcxx-4.2.1.tar'. File is broken" message. WinZip gave me similar problems. Internet Explorer 6.0 -- displays the file size of 6.9 MB in the download dialog, and indicates a successful completion of transfer, but the file size actually stored is only 4.6 MB. (Same as with Firefox 3.0.3). I have downloaded lots of binary files much bigger than these stdcxx files, from other sites, using Firefox 3.0.3, without any problems. * * * * * * Using FileZilla with archive.apache.org 80, I get the following log: Status: Selected port usually in use by a different protocol. Status: Resolving address of archive.apache.org Status: Connecting to 140.211.11.130:80... Status: Connection established, waiting for welcome message... Error: Connection timed out Trace: CFtpControlSocket::ResetOperation(2114) Trace: CControlSocket::ResetOperation(2114) Error: Could not connect to server but FileZilla works fine with other sites. Using command line ftp, the connection times out: ftp> open www.apache.org 80 Connected to www.apache.org. Connection closed by remote host. ftp> open www.apache.org 80 Connected to www.apache.org. Connection closed by remote host. but I can connect with command line ftp to other sites with no problem. * * * * * * I use Kaspersky Internet Security, and I have downloaded lots of binary files much bigger than these stdcxx files, using Firefox 3.0.3, without any problems. I tried disabling the Kaspersky firewall, and then diabling all of Kaspersky, but I still get the same file truncation problem with stdcxx-s4.2.1.tar.gz. I can connect ok to other ftp sites with Kaspersky firewall enabled. * * * * * * I really want to use the Apache C++ Standard Library with the GNU C++ compiler, because the Apache product seems to me to be superior to what comes with G++. Any suggestions would be most appreciated! -- View this message in context: http://www.nabble.com/File-truncation-Problem-Downloading-stdcxx-4.2.1.tar.gz-tp20452964p20452964.html Sent from the stdcxx-user mailing list archive at Nabble.com.
-------- Original Message -------- Subject: Application Period Opens for Travel Assistance to ApacheCon US 2008 Date: Thu, 25 Sep 2008 23:36:44 +1000 From: Gavin <gavin@16degrees.com.au> Reply-To: private@stdcxx.apache.org To: <pmcs@apache.org> Dear PMCs, Please could you forward the below message to your user@ and dev@ mailing lists, thanks in advance. ------------- The Travel Assistance Committee is taking in applications for those wanting to attend ApacheCon US 2008 between the 3rd and 7th November 2008 in New Orleans. The Travel Assistance Committee is looking for people who would like to be able to attend ApacheCon US 2008 who need some financial support in order to get there. There are VERY few places available and the criteria is high, that aside applications are open to all open source developers who feel that their attendance would benefit themselves, their project(s), the ASF and open source in general. Financial assistance is available for flights, accomodation and entrance fees either in full or in part, depending on circumstances. It is intended that all our ApacheCon events are covered, so it may be prudent for those in Europe and or Asia to wait until an event closer to them comes up - you are all welcome to apply for ApacheCon US of course, but there must be compelling reasons for you to attend an event further away that your home location for your application to be considered above those closer to the event location. More information can be found on the main Apache website at http://www.apache.org/travel/index.html - where you will also find a link to the application form and details for submitting. Time is very tight for this event, so applications are open now and will end on the 2nd October 2008 - to give enough time for travel arrangements to be made. Good luck to all those that will apply. Regards, The Travel Assistance Committee
Mark Wright wrote: > Hello Martin, > > The top 4 bytes of the stack allocated pointer pbuf is > overwritten with 4 zero bytes when I do next over this line: > > const _RWSTD_SIZE_T dst_size = strxfrm (just_in_case_buf, psrc, 0); I wondered if it could be a bug in strxfrm(). I recall a problem with the function (STDCXX-68) but that was on Windows. > [...] > I can reproduce it easilly, and I have stdcxx compiled with debug > symbols, so its very easy for me to try stuff in the debuggger, just > let me know if you want me to try something. > > Or if you have some diffs for an idea to try, I can rebuild it and > let you know the results. > > It looks like this might be a bug in the Solaris 10u5 strxfrm(). Looks that way. > > Unfortunately I don't have Solaris support contract, so I can't > access SunSolve, or log a support issue with Sun. FWIW, I've been using the Sun Developer Network bug database to report bugs to Sun: http://bugreport.sun.com/bugreport/index.jsp > Doing a > google search I did find this hit on an old report of > a Solaris 8 strxfrm() memory overwrite bug: > > http://archives.postgresql.org/pgsql-ports/2002-05/msg00000.php > > Anyway I was wondering if it might help to make the > just_in_case_buf buffer large to try to work around Solaris 10's > strxfrm() insanity? I can try it if you like. That might work but I agree that the patch you proposed in your other post is safer. There's no need to use the MSVC workaround on Solaris. Let me open an issue for this and apply your patch. It will be included in 4.2.2, whenever it comes out. Thanks for debugging it! Martin PS You can keep track of the issue here: http://issues.apache.org/jira/browse/STDCXX-1010
> On Fri, 5 Sep 2008 21:27:09 +1000
> Mark Wright <markwright@internode.on.net> wrote:
>
> Anyway I was wondering if it might help to make the
> just_in_case_buf buffer large to try to work around Solaris 10's
> strxfrm() insanity?
The trouble with that idea though is the concern that strxfrm()
on Solaris 10u5 may still overwrite past the end of the buffer
no matter how large I made just_in_case_buf.
So I instead propose this fix:
goanna% diff -wc stdcxx-4.2.1/src/orig/collate.cpp stdcxx-4.2.1/src/collate.cpp
*** stdcxx-4.2.1/src/orig/collate.cpp 2008-04-25 10:25:19.000000000 +1000
--- stdcxx-4.2.1/src/collate.cpp 2008-09-05 22:00:05.074726012 +1000
***************
*** 522,531 ****
--- 522,537 ----
src += (last - src) + 1;
}
+ #if defined(__sun) && defined(__SVR4)
+ // Solaris 10u5 overwrites memory past the end of
+ // just_in_case_buf[8], to avoid this, pass a 0 pointer
+ char *just_in_case_buf = (char *)0;
+ #else
// provide a destination buffer to strxfrm() in case
// it's buggy (such as MSVC's) and tries to write to
// the buffer even if it's 0
char just_in_case_buf [8];
+ #endif
const _RWSTD_SIZE_T dst_size = strxfrm (just_in_case_buf, psrc, 0);
// check for strxfrm() errors
goanna%
I tested this with my test program on Solaris 10u5 with
Sun Studio 12 C++, it works fine.
Thanks very much, Mark
--
Hello Martin,
The top 4 bytes of the stack allocated pointer pbuf is
overwritten with 4 zero bytes when I do next over this line:
const _RWSTD_SIZE_T dst_size = strxfrm (just_in_case_buf, psrc, 0);
(dbx) where
=>[1] __rw::__rw_strnxfrm(src = 0x416fb5 "", nchars = 0), line 529 in "collate.cpp"
[2] std::collate_byname<char>::do_transform(this = 0x4170e0, low = 0x416f98 "Et la
marine va venir à Malte", high = 0x416fb5 ""), line 925 in "collate.cpp"
[3] std::collate_byname<char>::do_compare(this = 0x4170e0, low1 = 0x416f98 "Et la
marine va venir à Malte", high1 = 0x416fb5 "", low2 = 0x417048 "Et la marine va venir à Malte",
high2 = 0x417065 ""), line 895 in "collate.cpp"
[4] std::collate<char>::compare(this = 0x4170e0, __low1 = 0x416f98 "Et la marine va
venir à Malte", __high1 = 0x416fb5 "", __low2 = 0x417048 "Et la marine va venir à Malte",
__high2 = 0x417065 ""), line 119 in "_collate.h"
[5] main(), line 10 in "collate.cpp"
(dbx) print &just_in_case_buf[0]
&just_in_case_buf[0] = 0xfffffd7fffdfb360 "n(·ï^?ýÿÿ"
(dbx) examine 0xfffffd7fffdfb360 /145c
0xfffffd7fffdfb360: 'n' '(' '·' 'ï' '\0177' 'ý' 'ÿ' 'ÿ' '\0' '\0' '\0' '\0' '\0' '\0'
'\0' '\0'
0xfffffd7fffdfb370: '¼' ''' '·' 'ï' '\0177' 'ý' 'ÿ' 'ÿ' '»' ''' '·' 'ï' '\0177' 'ý' 'ÿ'
'ÿ'
0xfffffd7fffdfb380: 'õ' '(' '·' 'ï' '\0177' 'ý' 'ÿ' 'ÿ' '§' '³' 'ß' 'ÿ' '\0177' 'ý' 'ÿ'
'ÿ'
0xfffffd7fffdfb390: '\0' '\001' '\0' '\0' '\0' '\0' '\0' '\0' '§' '³' 'ß' 'ÿ' '\0177'
'ý' 'ÿ' 'ÿ'
0xfffffd7fffdfb3a0: '¾' ''' '·' 'ï' '\0177' 'ý' 'ÿ' 'E' 't' ' ' 'l' 'a' ' ' 'm' 'a' 'r'
0xfffffd7fffdfb3b0: 'i' 'n' 'e' ' ' 'v' 'a' ' ' 'v' 'e' 'n' 'i' 'r' ' ' 'à' ' ' 'M'
0xfffffd7fffdfb3c0: 'a' 'l' 't' 'e' '\0' 'ý' 'ÿ' 'ÿ' 'å' ''' '·' 'ï' '\0177' 'ý' 'ÿ'
'ÿ'
0xfffffd7fffdfb3d0: '\0' '\0' '\0' '\0' '\0' '\0' '\0' '\0' 'Î' '(' '·' 'ï' '\0177' 'ý'
'ÿ' 'ÿ'
0xfffffd7fffdfb3e0: 'Ñ' '(' '·' 'ï' '\0177' 'ý' 'ÿ' 'ÿ' 'Ô' '(' '·' 'ï' '\0177' 'ý' 'ÿ'
'ÿ'
0xfffffd7fffdfb3f0: '»'
(dbx) examine 0xfffffd7fffdfb360 /145n
0xfffffd7fffdfb360: 110 40 183 239 127 253 255 255 0 0 0 0 0 0 0 0
0xfffffd7fffdfb370: 188 39 183 239 127 253 255 255 187 39 183 239 127 253 255 255
0xfffffd7fffdfb380: 245 40 183 239 127 253 255 255 167 179 223 255 127 253 255 255
0xfffffd7fffdfb390: 0 1 0 0 0 0 0 0 167 179 223 255 127 253 255 255
0xfffffd7fffdfb3a0: 190 39 183 239 127 253 255 69 116 32 108 97 32 109 97 114
0xfffffd7fffdfb3b0: 105 110 101 32 118 97 32 118 101 110 105 114 32 224 32 77
0xfffffd7fffdfb3c0: 97 108 116 101 0 253 255 255 229 39 183 239 127 253 255 255
0xfffffd7fffdfb3d0: 0 0 0 0 0 0 0 0 206 40 183 239 127 253 255 255
0xfffffd7fffdfb3e0: 209 40 183 239 127 253 255 255 212 40 183 239 127 253 255 255
0xfffffd7fffdfb3f0: 187
(dbx) print pbuf
pbuf = 0xfffffd7fffdfb3a7 "Et la marine va venir à Malte"
(dbx) print &pbuf
&pbuf = 0xfffffd7fffdfb398
(dbx)
Its the top 4 bytes of the pointer pbuf here that are overwritten:
0xfffffd7fffdfb390: 0 1 0 0 0 0 0 0 167 179 223 255 127 253 255 255
I do next and strxfrm() zeros the top 4 bytes of the pbuf pointer:
(dbx) next
(dbx) print pbuf
pbuf = 0xffdfb3a7 "<bad address 0xffdfb3a7>"
(dbx) examine 0xfffffd7fffdfb360 /145c
0xfffffd7fffdfb360: 'n' '(' '·' 'ï' '\0177' 'ý' 'ÿ' 'ÿ' '\0' '\0' '\0' '\0' '\0' '\0'
'\0' '\0'
0xfffffd7fffdfb370: '¼' ''' '·' 'ï' '\0177' 'ý' 'ÿ' 'ÿ' '»' ''' '·' 'ï' '\0177' 'ý' 'ÿ'
'ÿ'
0xfffffd7fffdfb380: 'õ' '(' '·' 'ï' '\0177' 'ý' 'ÿ' 'ÿ' '§' '³' 'ß' 'ÿ' '\0177' 'ý' 'ÿ'
'ÿ'
0xfffffd7fffdfb390: '\0' '\001' '\0' '\0' '\0' '\0' '\0' '\0' '§' '³' 'ß' 'ÿ' '\0' '\0'
'\0' '\0'
0xfffffd7fffdfb3a0: '\0' '\0' 'ÿ' 'ÿ' '\0177' 'ý' '·' 'ï' 'å' ''' 'ÿ' 'ÿ' '\0' '\0' 't'
'e'
0xfffffd7fffdfb3b0: 'a' 'l' ' ' 'M' ' ' 'à' 'i' 'r' 'e' 'n' ' ' 'v' 'v' 'a' 'e' ' '
0xfffffd7fffdfb3c0: 'i' 'n' 'a' 'r' ' ' 'm' 'l' 'a' 't' ' ' 'ÿ' 'E' '\0177' 'ý' '·' 'ï'
0xfffffd7fffdfb3d0: '¾' ''' 'ÿ' 'ÿ' '\0177' 'ý' '\0' '\0' 'Î' '(' '·' 'ï' '\0177' 'ý'
'ÿ' 'ÿ'
0xfffffd7fffdfb3e0: 'Ñ' '(' '·' 'ï' '\0177' 'ý' 'ÿ' 'ÿ' 'Ô' '(' '·' 'ï' '\0177' 'ý' 'ÿ'
'ÿ'
0xfffffd7fffdfb3f0: '»'
(dbx) examine 0xfffffd7fffdfb360 /145n
0xfffffd7fffdfb360: 110 40 183 239 127 253 255 255 0 0 0 0 0 0 0 0
0xfffffd7fffdfb370: 188 39 183 239 127 253 255 255 187 39 183 239 127 253 255 255
0xfffffd7fffdfb380: 245 40 183 239 127 253 255 255 167 179 223 255 127 253 255 255
0xfffffd7fffdfb390: 0 1 0 0 0 0 0 0 167 179 223 255 0 0 0 0
0xfffffd7fffdfb3a0: 0 0 255 255 127 253 183 239 229 39 255 255 0 0 116 101
0xfffffd7fffdfb3b0: 97 108 32 77 32 224 105 114 101 110 32 118 118 97 101 32
0xfffffd7fffdfb3c0: 105 110 97 114 32 109 108 97 116 32 255 69 127 253 183 239
0xfffffd7fffdfb3d0: 190 39 255 255 127 253 0 0 206 40 183 239 127 253 255 255
0xfffffd7fffdfb3e0: 209 40 183 239 127 253 255 255 212 40 183 239 127 253 255 255
0xfffffd7fffdfb3f0: 187
(dbx) examine psrc /145c
0xfffffd7fffdfb3a7: 'ï' 'å' ''' 'ÿ' 'ÿ' '\0' '\0' 't' 'e' 'a' 'l' ' ' 'M' ' ' 'à' 'i'
0xfffffd7fffdfb3b7: 'r' 'e' 'n' ' ' 'v' 'v' 'a' 'e' ' ' 'i' 'n' 'a' 'r' ' ' 'm' 'l'
0xfffffd7fffdfb3c7: 'a' 't' ' ' 'ÿ' 'E' '\0177' 'ý' '·' 'ï' '¾' ''' 'ÿ' 'ÿ' '\0177' 'ý'
'\0'
0xfffffd7fffdfb3d7: '\0' 'Î' '(' '·' 'ï' '\0177' 'ý' 'ÿ' 'ÿ' 'Ñ' '(' '·' 'ï' '\0177'
'ý' 'ÿ'
0xfffffd7fffdfb3e7: 'ÿ' 'Ô' '(' '·' 'ï' '\0177' 'ý' 'ÿ' 'ÿ' '»' ''' '·' 'ï' '\0177' 'ý'
'ÿ'
0xfffffd7fffdfb3f7: 'ÿ' 'é' '(' '·' 'ï' '\0177' 'ý' 'ÿ' 'ÿ' 'ï' '(' '·' 'ï' '\0177' 'ý'
'ÿ'
0xfffffd7fffdfb407: 'ÿ' '×' '(' '·' 'ï' '\0177' 'ý' 'ÿ' 'ÿ' '\036' 'ø' '¶' 'ï' '\0177'
'ý' 'ÿ'
0xfffffd7fffdfb417: 'ÿ' 'ð' '²' 'ß' 'ï' '\0177' 'ý' 'ÿ' 'ÿ' '\0' '\0' '\0' '\0' '\0'
'\0' '\0'
0xfffffd7fffdfb427: '\0' '\0' '\0' '\0' '\0' '\0' '\0' '\0' '\0' '\0' '\0' '\0' '\0'
'\0' '\0' '\0'
0xfffffd7fffdfb437: '\0'
(dbx) examine psrc /145n
0xfffffd7fffdfb3a7: 239 229 39 255 255 0 0 116 101 97 108 32 77 32 224 105
0xfffffd7fffdfb3b7: 114 101 110 32 118 118 97 101 32 105 110 97 114 32 109 108
0xfffffd7fffdfb3c7: 97 116 32 255 69 127 253 183 239 190 39 255 255 127 253 0
0xfffffd7fffdfb3d7: 0 206 40 183 239 127 253 255 255 209 40 183 239 127 253 255
0xfffffd7fffdfb3e7: 255 212 40 183 239 127 253 255 255 187 39 183 239 127 253 255
0xfffffd7fffdfb3f7: 255 233 40 183 239 127 253 255 255 239 40 183 239 127 253 255
0xfffffd7fffdfb407: 255 215 40 183 239 127 253 255 255 30 248 182 239 127 253 255
0xfffffd7fffdfb417: 255 240 178 223 239 127 253 255 255 0 0 0 0 0 0 0
0xfffffd7fffdfb427: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0xfffffd7fffdfb437: 0
(dbx) print dst_size
dst_size = 144U
(dbx) where
=>[1] __rw::__rw_strnxfrm(src = 0x416fb5 "", nchars = 0), line 532 in "collate.cpp"
[2] std::collate_byname<char>::do_transform(this = 0x4170e0, low = 0x416f98 "Et la
marine va venir à Malte", high = 0x416fb5 ""), line 925 in "collate.cpp"
[3] std::collate_byname<char>::do_compare(this = 0x4170e0, low1 = 0x416f98 "Et la
marine va venir à Malte", high1 = 0x416fb5 "", low2 = 0x417048 "Et la marine va venir à Malte",
high2 = 0x417065 ""), line 895 in "collate.cpp"
[4] std::collate<char>::compare(this = 0x4170e0, __low1 = 0x416f98 "Et la marine va
venir à Malte", __high1 = 0x416fb5 "", __low2 = 0x417048 "Et la marine va venir à Malte",
__high2 = 0x417065 ""), line 119 in "_collate.h"
[5] main(), line 10 in "collate.cpp"
(dbx) print &pbuf
&pbuf = 0xfffffd7fffdfb398
(dbx)
I can reproduce it easilly, and I have stdcxx compiled with debug
symbols, so its very easy for me to try stuff in the debuggger, just
let me know if you want me to try something.
Or if you have some diffs for an idea to try, I can rebuild it and
let you know the results.
It looks like this might be a bug in the Solaris 10u5 strxfrm().
Unfortunately I don't have Solaris support contract, so I can't
access SunSolve, or log a support issue with Sun. Doing a
google search I did find this hit on an old report of
a Solaris 8 strxfrm() memory overwrite bug:
http://archives.postgresql.org/pgsql-ports/2002-05/msg00000.php
Anyway I was wondering if it might help to make the
just_in_case_buf buffer large to try to work around Solaris 10's
strxfrm() insanity? I can try it if you like.
Thanks very much,
Mark
On Thu, 04 Sep 2008 17:01:06 -0600
Martin Sebor <msebor@gmail.com> wrote:
> Mark Wright wrote:
> > Hi,
> >
> > I was just wondering if I'm doing something wrong in this
> > little program compiled with stdcxx 4.2.1, Sun Studio C++ 12,
> > Solaris 10u5 AMD64, compiled as 64 bit:
> >
> [...]
> > Running it encounters a sigsegv, when it calls delete [] pbuf
> > on non heap memory:
>
> I can't reproduce this problem in my environment. The program
> runs fine, both with libumem and in dbx with check -memuse on.
>
> Looking at the source code for __rw::__rw_strnxfrm(), pbuf is
> assigned one of two values: the address of the local array
> buf, and the result of the new expression. Its value is never
> assigned to another pointer that is then deleted and each of
> its delete expressions is guarded by a test for (pbuf != buf),
> so I don't see how it can ever be invalid.
>
> Can you step through the code to help debug it?
>
> Martin
>
> >
> > goanna% export LD_FLAGS_64="preload=libumem.so.1"
> > goanna% export UMEM_DEBUG=default
> > goanna% ./collate
> > zsh: segmentation fault (core dumped) ./collate
> > goanna% unset LD_FLAGS_64
> > goanna% unset UMEM_DEBUG
> > goanna% dbx collate core
> > Reading collate
> > core file header read successfully
> > Reading ld.so.1
> > Reading libumem.so.1
> > Reading libstd15D.so.4.2.1
> > Reading libCrun.so.1
> > Reading libm.so.2
> > Reading libthread.so.1
> > Reading libc.so.1
> > Reading fr_FR.ISO8859-1.so.3
> > t@1 (l@1) program terminated by signal SEGV (no mapping at the
> > fault address) 0xfffffd7fefd6374f: process_free+0x002f:
> > movl (%rsi),%r8d Current function is __rw::__rw_strnxfrm
> > 577 delete[] pbuf;
> > (dbx) where
> > current thread: t@1
> > [1] process_free(0xffdfb5b7, 0xffdfb5af, 0x0, 0xfffffd7fffdfb42f,
> > 0xfffffd7fffdfb5b7, 0xffdfb5b7), at 0xfffffd7fefd6374f [2]
> > free(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fefd638f5 [3]
> > operator delete(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at
> > 0xfffffd7fefbc9621 [4] operator delete[](0x0, 0x0, 0x0, 0x0, 0x0,
> > 0x0), at 0xfffffd7fefbc9549 =>[5] __rw::__rw_strnxfrm(src =
> > 0x450f45 "", nchars = 0), line 577 in "collate.cpp" [6]
> > std::collate_byname<char>::do_transform(this = 0x451f20, low =
> > 0x450f28 "Et la marine va venir à Malte", high = 0x450f45 ""), line
> > 925 in "collate.cpp" [7] std::collate_byname<char>::do_compare(this
> > = 0x451f20, low1 = 0x450f28 "Et la marine va venir à Malte", high1
> > = 0x450f45 "", low2 = 0x450e28 "Et la marine va venir à Malte",
> > high2 = 0x450e45 ""), line 895 in "collate.cpp" [8]
> > std::collate<char>::compare(this = 0x451f20, __low1 = 0x450f28 "Et
> > la marine va venir à Malte", __high1 = 0x450f45 "", __low2 =
> > 0x450e28 "Et la marine va venir à Malte", __high2 = 0x450e45 ""),
> > line 119 in "_collate.h" [9] main(), line 10 in "collate.cpp" (dbx)
> > print pbuf pbuf = 0xffdfb5b7 "<bad address 0xffdfb5b7>" (dbx)
> > loadobject -list m /h/goanna/2/eng/dev/cxx/collate/collate
> > (primary) m /lib/amd64/libumem.so.1
> > m /h/goanna/1/a_5.10_m64/c/lib/libstd15D.so.4.2.1
> > m /usr/lib/amd64/libCrun.so.1 m /lib/amd64/libm.so.2
> > m /lib/amd64/libthread.so.1 m /lib/amd64/libc.so.1
> > m /usr/lib/locale/fr_FR.ISO8859-1/amd64/fr_FR.ISO8859-1.so.3
> > (dbx)
> >
> > Thanks very much, Mark
> >
>
--
Mark Wright wrote: > Hi, > > I was just wondering if I'm doing something wrong in this > little program compiled with stdcxx 4.2.1, Sun Studio C++ 12, > Solaris 10u5 AMD64, compiled as 64 bit: > [...] > Running it encounters a sigsegv, when it calls delete [] pbuf > on non heap memory: I can't reproduce this problem in my environment. The program runs fine, both with libumem and in dbx with check -memuse on. Looking at the source code for __rw::__rw_strnxfrm(), pbuf is assigned one of two values: the address of the local array buf, and the result of the new expression. Its value is never assigned to another pointer that is then deleted and each of its delete expressions is guarded by a test for (pbuf != buf), so I don't see how it can ever be invalid. Can you step through the code to help debug it? Martin > > goanna% export LD_FLAGS_64="preload=libumem.so.1" > goanna% export UMEM_DEBUG=default > goanna% ./collate > zsh: segmentation fault (core dumped) ./collate > goanna% unset LD_FLAGS_64 > goanna% unset UMEM_DEBUG > goanna% dbx collate core > Reading collate > core file header read successfully > Reading ld.so.1 > Reading libumem.so.1 > Reading libstd15D.so.4.2.1 > Reading libCrun.so.1 > Reading libm.so.2 > Reading libthread.so.1 > Reading libc.so.1 > Reading fr_FR.ISO8859-1.so.3 > t@1 (l@1) program terminated by signal SEGV (no mapping at the fault address) > 0xfffffd7fefd6374f: process_free+0x002f: movl (%rsi),%r8d > Current function is __rw::__rw_strnxfrm > 577 delete[] pbuf; > (dbx) where > current thread: t@1 > [1] process_free(0xffdfb5b7, 0xffdfb5af, 0x0, 0xfffffd7fffdfb42f, 0xfffffd7fffdfb5b7, 0xffdfb5b7), at 0xfffffd7fefd6374f > [2] free(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fefd638f5 > [3] operator delete(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fefbc9621 > [4] operator delete[](0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fefbc9549 > =>[5] __rw::__rw_strnxfrm(src = 0x450f45 "", nchars = 0), line 577 in "collate.cpp" > [6] std::collate_byname<char>::do_transform(this = 0x451f20, low = 0x450f28 "Et la marine va venir à Malte", high = 0x450f45 ""), line 925 in "collate.cpp" > [7] std::collate_byname<char>::do_compare(this = 0x451f20, low1 = 0x450f28 "Et la marine va venir à Malte", high1 = 0x450f45 "", low2 = 0x450e28 "Et la marine va venir à Malte", high2 = 0x450e45 ""), line 895 in "collate.cpp" > [8] std::collate<char>::compare(this = 0x451f20, __low1 = 0x450f28 "Et la marine va venir à Malte", __high1 = 0x450f45 "", __low2 = 0x450e28 "Et la marine va venir à Malte", __high2 = 0x450e45 ""), line 119 in "_collate.h" > [9] main(), line 10 in "collate.cpp" > (dbx) print pbuf > pbuf = 0xffdfb5b7 "<bad address 0xffdfb5b7>" > (dbx) loadobject -list > m /h/goanna/2/eng/dev/cxx/collate/collate (primary) > m /lib/amd64/libumem.so.1 > m /h/goanna/1/a_5.10_m64/c/lib/libstd15D.so.4.2.1 > m /usr/lib/amd64/libCrun.so.1 > m /lib/amd64/libm.so.2 > m /lib/amd64/libthread.so.1 > m /lib/amd64/libc.so.1 > m /usr/lib/locale/fr_FR.ISO8859-1/amd64/fr_FR.ISO8859-1.so.3 > (dbx) > > Thanks very much, Mark >
Hi,
I was just wondering if I'm doing something wrong in this
little program compiled with stdcxx 4.2.1, Sun Studio C++ 12,
Solaris 10u5 AMD64, compiled as 64 bit:
#include <locale>
#include <string>
int main()
{
std::locale loc = std::locale("fr_FR");
std::string s1("Et la marine va venir à Malte");
std::string s2("Et la marine va venir à Malte");
const std::collate<std::string::value_type>& col = std::use_facet<std::collate<std::string::value_type>
>(loc);
if (col.compare(s1.c_str(),
s1.c_str() + s1.length(),
s2.c_str(),
s2.c_str() + s2.length()) == 0)
return 1;
return 0;
}
Running it encounters a sigsegv, when it calls delete [] pbuf
on non heap memory:
goanna% export LD_FLAGS_64="preload=libumem.so.1"
goanna% export UMEM_DEBUG=default
goanna% ./collate
zsh: segmentation fault (core dumped) ./collate
goanna% unset LD_FLAGS_64
goanna% unset UMEM_DEBUG
goanna% dbx collate core
Reading collate
core file header read successfully
Reading ld.so.1
Reading libumem.so.1
Reading libstd15D.so.4.2.1
Reading libCrun.so.1
Reading libm.so.2
Reading libthread.so.1
Reading libc.so.1
Reading fr_FR.ISO8859-1.so.3
t@1 (l@1) program terminated by signal SEGV (no mapping at the fault address)
0xfffffd7fefd6374f: process_free+0x002f: movl (%rsi),%r8d
Current function is __rw::__rw_strnxfrm
577 delete[] pbuf;
(dbx) where
current thread: t@1
[1] process_free(0xffdfb5b7, 0xffdfb5af, 0x0, 0xfffffd7fffdfb42f, 0xfffffd7fffdfb5b7, 0xffdfb5b7),
at 0xfffffd7fefd6374f
[2] free(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fefd638f5
[3] operator delete(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fefbc9621
[4] operator delete[](0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfffffd7fefbc9549
=>[5] __rw::__rw_strnxfrm(src = 0x450f45 "", nchars = 0), line 577 in "collate.cpp"
[6] std::collate_byname<char>::do_transform(this = 0x451f20, low = 0x450f28 "Et la
marine va venir à Malte", high = 0x450f45 ""), line 925 in "collate.cpp"
[7] std::collate_byname<char>::do_compare(this = 0x451f20, low1 = 0x450f28 "Et la
marine va venir à Malte", high1 = 0x450f45 "", low2 = 0x450e28 "Et la marine va venir à Malte",
high2 = 0x450e45 ""), line 895 in "collate.cpp"
[8] std::collate<char>::compare(this = 0x451f20, __low1 = 0x450f28 "Et la marine va
venir à Malte", __high1 = 0x450f45 "", __low2 = 0x450e28 "Et la marine va venir à Malte",
__high2 = 0x450e45 ""), line 119 in "_collate.h"
[9] main(), line 10 in "collate.cpp"
(dbx) print pbuf
pbuf = 0xffdfb5b7 "<bad address 0xffdfb5b7>"
(dbx) loadobject -list
m /h/goanna/2/eng/dev/cxx/collate/collate (primary)
m /lib/amd64/libumem.so.1
m /h/goanna/1/a_5.10_m64/c/lib/libstd15D.so.4.2.1
m /usr/lib/amd64/libCrun.so.1
m /lib/amd64/libm.so.2
m /lib/amd64/libthread.so.1
m /lib/amd64/libc.so.1
m /usr/lib/locale/fr_FR.ISO8859-1/amd64/fr_FR.ISO8859-1.so.3
(dbx)
Thanks very much, Mark
--