bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: test-symlink failure on MinGW


From: Simon Josefsson
Subject: Re: test-symlink failure on MinGW
Date: Tue, 29 Dec 2009 07:42:56 +0100
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)

Eric Blake <address@hidden> writes:

> According to Simon Josefsson on 12/27/2009 3:06 AM:
>> I got this error when cross-compiling to MinGW:
>> 
>> ../../../src/libidn-1.16/gltests/test-symlink.c:43: assertion failed
>> FAIL: test-symlink.exe
>> 
>> The reason is use of a system call.  I changed it into a shell script
>> wrapper instead.  OK to push?
>
> Not as is.  It would be much nicer to figure out why the system call is
> failing for you; it works for me when I cross compile from cygwin to
> mingw.

I suspect the reason is that I don't have 'rm' installed in the MinGW
environment:

address@hidden:~$ cat foo.c
#include <stdio.h>
#include <stdlib.h>
int main (void)
{
  int rc = system ("rm --help");
  printf ("rc %d\n", rc);
  return 0;
}
address@hidden:~$ i586-mingw32msvc-gcc -o foo.exe foo.c
address@hidden:~$ ./foo.exe
File not found

rc 9009
address@hidden:~$ 

> And there are a lot more tests than just test-symlink.c that used the
> same idiom.  They would all need the same fix.

Yes, they would need the same fix.  But it is not a lot of more tests.
Gnulib used to build fine just a week or two ago on a Debian MinGW
cross-compilation installation.  It is the recent patches to some
modules that break this.

> Does system() work at all in your environment, even for simple tasks
> like an echo (which should be a builtin, regardless of whether
> system() uses sh or cmd)?  If so, then maybe your problem is locating
> and running rm once the system call is started.

Yes.

> One thing that I would be more comfortable with is just weakening those
> system() calls to no longer be wrapped in an ASSERT - if it fails for a
> cross compile to mingw, that's no big loss, provided the test passes
> normally and leaves no garbage.  That line is really meant for cleanup
> from previous partial runs, to make it easier to debug failures.  But now
> that most of the failures for mingw have been debugged, there shouldn't
> (normally) be anything to clean up.  I really don't see a reason to add a
> shell script wrapper just for this special case.

So how about this patch?  If you agree with the approach, I can push the
same patch for the other modules affected too (about 2-3 others).

/Simon

diff --git a/ChangeLog b/ChangeLog
index a5c7e46..696bf4c 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,7 @@
+2009-12-29  Simon Josefsson  <address@hidden>
+
+       * tests/test-symlink.c (main): Ignore errors from rm.
+
 2009-12-28  Jim Meyering  <address@hidden>
 
        update-copyright: you may specify a max. line length other than 72
diff --git a/tests/test-symlink.c b/tests/test-symlink.c
index c84b2bc..f066ee3 100644
--- a/tests/test-symlink.c
+++ b/tests/test-symlink.c
@@ -40,7 +40,7 @@ int
 main (void)
 {
   /* Remove any leftovers from a previous partial run.  */
-  ASSERT (system ("rm -rf " BASE "*") == 0);
+  system ("rm -rf " BASE "*");
 
   return test_symlink (symlink, true);
 }




reply via email to

[Prev in Thread] Current Thread [Next in Thread]