[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] tcc-busybox-w32 broken since 20a1ebf (tccpp : get rid
From: |
avih |
Subject: |
Re: [Tinycc-devel] tcc-busybox-w32 broken since 20a1ebf (tccpp : get rid of 'ch') |
Date: |
Mon, 10 Oct 2022 16:53:45 +0000 (UTC) |
On Monday, October 10, 2022, 12:33:48 PM GMT+3, grischka <grishka@gmx.de> wrote:
>> tcc-busybox is:
>> http://download.savannah.nongnu.org/releases/tinycc/tcc-busybox-for-win32.zip
>>
>> building this busybox using tcc which was built from mob 20a1ebf
>> or later results in sh.exe which always prints "sh: applet not found".
>
> Hi, I'm afraid you're right.
>
> Fortunately commit 20a1ebf had to do with the preprocessor exclusively,
> so I did add -E to the build command for the busybox and could produced
> two files, one of 180.381.021 bytes and one of 180.381.020 bytes... Hm.
> ...
> Anyway, fixed on mob.
Confirmed that it seems fixed for both tcc32 and 64. Thanks.
./sh.exe -c 'echo OK' now prints OK, and interactive shell seems good.
> As to spurious problems with MSYS2 I can only say that in my experience
> it is not a completely reliable build system.
>
> As a derivative from cygwin it shares the same fork() emulation hack,
> and I've seen it sub-processes just silently terminating (or maybe not
> even start them) with no failure code whatsoever.
I presume you refer to my mail "test failures on win32 x86-64" here:
https://lists.nongnu.org/archive/html/tinycc-devel/2022-10/msg00019.html
If yes, then while cygwin/MSYS2 fork issue is possible, I don't think
it's the cause, and I don't usually have fork issues with cygwin.
I think the resulting tcc.exe is faulty in some ways when built using
mingw gcc 64 (tested cygwin gcc 11.3, and MSYS2/w64devkit gcc 12.2).
w64devkit is interesting because it seems to be a native win32 mingw
gcc, i.e. not a cross compiler, and same for its 'make', and the
shell too (busybox-w32) - https://github.com/skeeto/w64devkit
In all 3 gcc versions and their 'make' and shell/env it's exactly the
same tests which fail, and seemingly in exactly the same ways:
- test3 and test1b _seem_ to crash
- 104_inline outputs "tcc: error: internal error: relocation failed"
And all the tests always pass with mingw i386 - both when building
in MSYS2 and cygwin (and their respective mingw i386 gcc).
Interestingly, when building using native win32 x86-64 tcc, then all
the tests do pass (even if building in MSYS2/cygwin with their fork).
Shall we continue this discussion at its original email thread?
- avih
> That would not affect the built tcc itself however it could affect the
> 'diff' used by the tests for example.
>
> Mostly it seems to work just fine though, I personally don't currently
> see any problems. Known reasons could be bad interaction with some
> anti-virus-defender-etc...ware. What I see is that on a windows-10
> with its 'defender' ON, building & test tcc with msys is almost twice
> as slow.
>
> -- grischka