> 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.

Reply via email to