stdcxx-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Petrie, P.Eng." <>
Subject Re: Building stdcxx-4.2.2 Using MinGW+MSYS On Windows XP (SP2)
Date Mon, 01 Dec 2008 05:59:23 GMT
 I have MSYS and "ln --version" reports version 5.97

The "ln" in MSYS 1.0.10 was pre-5.97, so I downloaded and installed:


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 /stdcxx-4.2.2/src/rwstderr.msg
   /bin/sh: gencat: command not found
   make[2]: [] 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 /stdcxx-4.2.2/src/rwstderr.msg
   windres: i:/apps/stdcxx-4.2.2/src/rwstderr.msg:1: syntax error
   make[1]: [] 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; \
   mkdir -p install_11s/etc
   cp install_11s/etc
   cp: cannot stat `': 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 `': 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

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?



----- Original Message ----- 
From: "Farid Zaripov" <>
To: <>
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 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 <<

    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
documented in JIRA) and failures, that should be an expected, but not
in JIRA yet. BTW any stdcxx user can document new failures by creating
issues in JIRA ;)

  The 18.c.limits.stdcxx-988.cpp test fails to compile on gcc/MinGW due to
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
current C++ standard in header <climits> synopsis. I suppose that they're
(i.e. required by POSIX only) and can be not exercised (as it is already
done for EDG eccp).


View raw message