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.
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: > > > > 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. > > 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 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 provided by compiler. Strictly speaking I didn't found these names mentioned in current C++ standard in header 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.
Re: Building stdcxx-4.2.1 Using MinGW+MSYS On Windows XP (SP2)
> 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.
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 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 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.
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.
RE: copy ostringstream ostream_iterator output out of order
> -Original Message- > From: Mark Wright [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 25, 2008 12:42 PM > To: user@stdcxx.apache.org > Subject: copy ostringstream ostream_iterator output out of order > > I compile and run following the program with stdcxx compiled > from subversion > (svn update and compiled today) with Sun Studio 12 64 bit > build mode 15D: [...] > I am wondering if I am doing something wrong, as the output is > out of order: This is a definitely bug in stdcxx library. I have created the corresponding issue: https://issues.apache.org/jira/browse/STDCXX-795 Fixed thus: http://svn.apache.org/viewvc?rev=640831&view=rev Thanks for the report! Farid.