tinycc-devel
[Top][All Lists]
Advanced

[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




reply via email to

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