[Top][All Lists]

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

Re: [Tinycc-devel] test 104 fails on windows: missing mkstemps

From: Christian Jullien
Subject: Re: [Tinycc-devel] test 104 fails on windows: missing mkstemps
Date: Wed, 19 Jun 2019 07:20:01 +0200


I quickly hacked 104 test to start to make it work but I’m not the author of this test. I let Petr improve it.

I fully agree with you that mixing C code and calling system (which forks a cmd.exe on Windows) to finally execute gnu commands that require Cygwin is a BAD idea!!

As you said, it’s much easier if 104 test generates a .o which the whole ‘unix’ infrastructure test will check. I let the maintainer of this test decide what to do.


About the diff, I don’t understand quite well what happens. Among other, it calls system(“sort …”); which spawns cmd.exe and then execute first sort seen in path. Depending on your PATH it can be Windows sort (if Windows path comes first) or Cygwin version if this one comes first.


Can you please try this diff which works as good for me but now forces sort Windows version:


diff --git a/tests/tests2/104_inline_test.c b/tests/tests2/104_inline_test.c

index cb288d2..d191602 100644

--- a/tests/tests2/104_inline_test.c

+++ b/tests/tests2/104_inline_test.c

@@ -5,8 +5,8 @@


#if __linux__ || __APPLE__

#define SYS_WHICH_NM "which nm >/dev/null 2>&1"

+#define SYS_SORT     "sort"

#define TCC_COMPILER "../../tcc"

-#define SYS_AWK


char c[]="/tmp/tcc-XXXXXX"; char o[]="/tmp/tcc-XXXXXX";

static int mktempfile(char *buf)

@@ -15,6 +15,7 @@ static int mktempfile(char *buf)


#elif defined(_WIN32)

#define SYS_WHICH_NM  "which nm >nul 2>&1"

+#define SYS_SORT      "%systemroot%\\system32\\sort /LOCALE C"


#if defined(_WIN64)

#define TCC_COMPILER "..\\..\\win32\\x86_64-win32-tcc"

@@ -72,7 +73,7 @@ int main(int C, char **V)

         sprintf(buf, "%s -c -xc %s -o %s", V[1]?V[1]:TCC_COMPILER, c, o); if(0!=system(buf)){ r=1;goto out;}

         sprintf(buf, "nm -Ptx %s > %s", o, c); if(system(buf)) {r=1;goto out;}

         sprintf(buf, "gawk '{ if($2 == \"T\") print $1 }' %s > %s", c, o); if(system(buf)) {r=1;goto out;}

-        sprintf(buf, "sort %s", o); if(system(buf)) {r=1;goto out;}

+        sprintf(buf, "%s %s", SYS_SORT, o); if(system(buf)) {r=1;goto out;}





From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=address@hidden] On Behalf Of avih
Sent: Tuesday, June 18, 2019 21:01
To: address@hidden; address@hidden; 'Michael Matz'
Subject: Re: [Tinycc-devel] test 104 fails on windows: missing mkstemps


Well, the diffs are not really diffs. They just moved. Looks like `sort` didn't work as expected, or maybe it's some locale issue (mine is en_US.UTF-8 at cygwin, and en-US at windows).


A script should handle this too, possibly with LC_ALL=C (and make sure the reference file is generated with the same sort locale).


If someone could split it to program+script then I can test the test in various use cases and make adjustment if required (I'm terrible with Makefiles but reasonably useful with shell).


On Tuesday, June 18, 2019 9:50 PM, avih <address@hidden> wrote:


After commit d39c49db  Remove empty conditional _WIN32 code

and some hacking of the code (it's an unhealthy mix of basically running a shell script from a program compiled using tcc for windows), I get the following 2 diffs:




I'm running it in a cygwin environment and the tools (nm, sort, gawk) are cygwin tools, while the tested tcc is normal mingw tcc for windows (which I build in a reproducible way using my script).

Regardless of these two diffs, I think the test should be composed of a program and a normal shell script (which uses mktemp, awk, sort etc), so that the paths are consistent between the tools.

Also, the TCC path is hardcoded at the test, but in fact it's parametric at the makefile as $(TCC), so it's better to use that instead (but then there are forward/backward slash issues which need to be handled too, because system(...) in win32 expects backward slashes, but $(TCC) at the makefile has forward slashes). Making this a program + a script should implicitly solve this issue as well.

After all, a working shell+tools is assumed for this test anyway, but the current way of using system(...) from a win32 program (compiled using tcc for windows) invokes a windows shell which can be inconsistent with the actual shell where `make` runs.



On Tuesday, June 18, 2019 12:11 AM, avih <address@hidden> wrote:


Hmm.. I now see that test 104 uses signal and nm, so it might require some effort to make it work on windows.


Nevertheless, considering the recent breakage specifically on windows from related code, I think it would be beneficial if this test could be made to work on windows,


On Monday, June 17, 2019 11:54 PM, avih <address@hidden> wrote:


Wouldn't it be better to just create a known/fixed file instead? (assuming the test doesn't need explicitly mkstemps, I didn't look at its actual code).


On Monday, June 17, 2019 11:50 PM, Christian Jullien <address@hidden> wrote:


Yes it has been previously reported.


Michael, as said in a private mail, I agree with you that this test should be skipped on Windows.




From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=address@hidden] On Behalf Of avih
Sent: Monday, June 17, 2019 22:46
To: Tinycc-devel Mailing List
Subject: [Tinycc-devel] test 104 fails on windows: missing mkstemps


Test 104 log on windows (both tcc32 and tcc 64):


Test: 104_inline_test...
--- 104_inline_test.expect      2019-06-17 23:42:00.162697100 +0300
+++ 104_inline_test.output      2019-06-17 23:42:35.531550400 +0300
@@ -1,25 +1,2 @@
+104_inline_test.c:30: warning: implicit declaration of function 'mkstemps'
+tcc: error: undefined symbol 'mkstemps'
make[1]: *** [Makefile:70: 104_inline_test.test] Error 1
Test: 105_local_extern...
make[1]: Target 'all' not remade because of errors.






reply via email to

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