Re: [Tinycc-devel] tcc-busybox-w32 broken since 20a1ebf (tccpp : get rid of 'ch')
On Monday, October 10, 2022, 12:33:48 PM GMT+3, grischka 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 ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tcc-busybox-w32 broken since 20a1ebf (tccpp : get rid of 'ch')
On 08.10.2022 22:50, avih via Tinycc-devel wrote: Hi, It's the first time I tried building it (cute), and turns out that it's currently broken. 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. --- x1.c2022-10-09 02:13:59.909900800 +0200 +++ x2.c2022-10-09 02:14:02.998700800 +0200 @@ -1916652,7 +1916652,7 @@ } max -= 150; } - max /= (unsigned)8; + max = (unsigned)8; i /= (unsigned)8; # 289 "libbb/appletlib.c" while (i < max) { Turned out that max(a,b) was defined as a macro, and in order to see whether it should be applied to the 'max' above, tcc needs to find out whether there is a '(' following, and in course of that whether possibly '/' could be the start of a comment, as for example in max /* ... */ (1,2) However seen that after having read '=' that this is not the case, tcc (by that commit of mine) forgot to put back the '/' on the input stream. Anyway, fixed on mob. 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. 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 The steps to reproduce below are using MSYS2 mingw, but it was reproduced also after building win32 tcc in other environments. Interestingly, renaming the binary to ash.exe seem to "fix" it. e.g. ./sh.exe -c 'echo hello' # -> sh: applet not found mv ./sh.exe ./ash.exe ./ash.exe -c 'echo hello' # -> hello This happens with both win32 tcc i386 and x86-64, and tcc i386 does pass all tests (x86-64 fails some tests, but probably unrelated). Building one commit earlier (85c32dd tccpp: integrate __has_include..) and both i386 and x86-64 tcc build sh.exe which seem to work as expected. I didn't try to find what fails in busybox, and the the bad commit 20a1ebf is quite big, so it's hard to pinpoint the culprit, if any. regards, avih steps to reproduce using MSYS2 with mingw i686 and x86-64 installed: the following prints "sh: applet not found" if built using tcc from 20a1ebf, but prints "OK" if built using tcc from 85c32dd or earlier. # get the sources once: mkdir /c/test \ && cd /c/test \ && wget http://download.savannah.nongnu.org/releases/tinycc/tcc-busybox-for-win32.zip \ && unzip tcc-busybox-for-win32.zip \ && git clone http://repo.or.cz/tinycc.git # build tcc32, busybox, and test: # MSYSTEM=... PATH=... emulates the mingw32 desktop shortcut cd /c/test/tinycc \ && git clean -xfd \ && rm -rf /c/test/tcc-busybox-for-win32/tcc \ && ( MSYSTEM=MINGW32 PATH=/mingw32/bin:$PATH \ && ./configure --cpu=i386 --prefix=/c/test/tcc-busybox-for-win32/tcc \ && make \ && make install \ && cd /c/test/tcc-busybox-for-win32/busybox \ && rm -f ../sh.exe \ && PATH=/c/test/tcc-busybox-for-win32/tcc \ && tcc @0.tcc/busybox.tcc.rsp -w \ && ../sh.exe -c 'echo OK' ) # tcc64: ... MSYSTEM=MINGW64 PATH=/mingw64/bin:$PATH \ #&& ./configure --cpu=x86_64 --prefix=... ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] tcc-busybox-w32 broken since 20a1ebf (tccpp : get rid of 'ch')
Hi, It's the first time I tried building it (cute), and turns out that it's currently broken. 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". The steps to reproduce below are using MSYS2 mingw, but it was reproduced also after building win32 tcc in other environments. Interestingly, renaming the binary to ash.exe seem to "fix" it. e.g. ./sh.exe -c 'echo hello' # -> sh: applet not found mv ./sh.exe ./ash.exe ./ash.exe -c 'echo hello' # -> hello This happens with both win32 tcc i386 and x86-64, and tcc i386 does pass all tests (x86-64 fails some tests, but probably unrelated). Building one commit earlier (85c32dd tccpp: integrate __has_include..) and both i386 and x86-64 tcc build sh.exe which seem to work as expected. I didn't try to find what fails in busybox, and the the bad commit 20a1ebf is quite big, so it's hard to pinpoint the culprit, if any. regards, avih steps to reproduce using MSYS2 with mingw i686 and x86-64 installed: the following prints "sh: applet not found" if built using tcc from 20a1ebf, but prints "OK" if built using tcc from 85c32dd or earlier. # get the sources once: mkdir /c/test \ && cd /c/test \ && wget http://download.savannah.nongnu.org/releases/tinycc/tcc-busybox-for-win32.zip \ && unzip tcc-busybox-for-win32.zip \ && git clone http://repo.or.cz/tinycc.git # build tcc32, busybox, and test: # MSYSTEM=... PATH=... emulates the mingw32 desktop shortcut cd /c/test/tinycc \ && git clean -xfd \ && rm -rf /c/test/tcc-busybox-for-win32/tcc \ && ( MSYSTEM=MINGW32 PATH=/mingw32/bin:$PATH \ && ./configure --cpu=i386 --prefix=/c/test/tcc-busybox-for-win32/tcc \ && make \ && make install \ && cd /c/test/tcc-busybox-for-win32/busybox \ && rm -f ../sh.exe \ && PATH=/c/test/tcc-busybox-for-win32/tcc \ && tcc @0.tcc/busybox.tcc.rsp -w \ && ../sh.exe -c 'echo OK' ) # tcc64: ... MSYSTEM=MINGW64 PATH=/mingw64/bin:$PATH \ #&& ./configure --cpu=x86_64 --prefix=... ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel