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
