ksh fails to compile with tcc #232
Comments
|
It would be nice if this worked, but I don't see it as a very high priority. As far as I know there are no systems that have tcc as their standard compiler. And isn't tcc designed more for quickly compiling and running small programs on the fly? |
It can do that, but its goal is to be a small and relatively simple c99 compliant compiler, currently also with some c11 features. It can build big projects, with varying degrees of efforts (some of those to work around gnu-ism), like the linux kernel, and apparently ksh is not too far off either. |
|
With the current patch the latest version of As it turns out I'm not sure if this can be cleanly fixed. The best way would be to have |
This allows ksh to be compiled with versions of tcc that define __dso_handle in libtcc1.a[*], although only on Linux. The two problems that remain are the following: 1) Older versions of tcc still fail to compile ksh, although now they fail after reaching the libdll feature test. I'm not sure if fixing that is feasible since even if I hack out the failing libdll feature test, ksh fails to link with a '__dso_handle' error. 2) tcc fails to build ksh on FreeBSD. For some reason tcc imitates GCC on FreeBSD but not on Linux. As a result the FreeBSD math.h header tries to define macros that call GCC/Clang builtins. This results in undefined symbol errors since tcc doesn't have those builtins. src/cmd/INIT/iffe.sh: compile(): - tcc forbids combining the -c compiler flag with -l* linker flags. Strip all -l* flags when -c was passed to the compiler. This is only done when tcc is the compiler to prevent build failures on some platforms (such as illumos). src/lib/libast/comp/atexit.c, src/lib/libast/features/lib, src/lib/libast/vmalloc/vmexit.c: - From what I've been able to gather the only OSes with support for on_exit are Linux and SunOS 4. However, on_exit takes two arguments, so the macro that defines it as taking one argument is incorrect. Since Solaris (SunOS 5) no longer has this call and the macro breaks on Linux, the clean fix is to remove it (atexit(3) is used instead). [*]: https://repo.or.cz/tinycc.git/commit/dd60b20c6e0d01df8e332b0234125abaa964d324 Progresses: ksh93#232
|
On *BSD systems Disabling these macros with |
|
Does |
|
I tried that before, but it only seems to work when applied to --- a/usr/include/math.h
+++ b/usr/include/math-copy.h
@@ -38,7 +38,7 @@ extern const union __nan_un {
#define __MATH_BUILTIN_CONSTANTS
#endif
-#if __GNUC_PREREQ__(3, 0) && !defined(__INTEL_COMPILER)
+#if __GNUC_PREREQ__(3, 0) && !defined(__INTEL_COMPILER) && !defined(__TINYC__)
#define __MATH_BUILTIN_RELOPS
#endif
|
|
Got tcc working on FreeBSD. That took some doing. The ports package does nothing but crash, so I got the latest git code. It requires gcc and gmake to compile. :-/ Anyway, I tried simply undefining But if I'm reading your diff above right, it looks like those math builtins are used on gcc 3.0 or later. So that made me think of the following... --- a/src/lib/libast/include/ast.h
+++ b/src/lib/libast/include/ast.h
@@ -78,6 +78,19 @@ struct _sfio_s;
#endif
#endif
+/*
+ * tcc on FreeBSD: Avoid using nonexistent math
+ * builtins by pretending to be an ancient gcc.
+ */
+#if __TINYC__ && __GNUC__ >= 3 && __FreeBSD__
+#undef __GNUC__
+#undef __GNUC_MINOR__
+#undef __GNUC_PATCHLEVEL__
+#define __GNUC__ 2
+#define __GNUC_MINOR__ 95
+#define __GNUC_PATCHLEVEL__ 3
+#endif
+
/*
* exit() support -- this matches shell exit codes
*/And presto, when applying this along with your PR, it now compiles on FreeBSD. No regression test failures. |
|
Here is a better fix for the illumos build failure to replace the one that broke tcc. The --- a/src/cmd/builtin/Mamfile
+++ b/src/cmd/builtin/Mamfile
@@ -37,7 +37,7 @@ make install
meta FEATURE/pty features/%>FEATURE/% features/pty pty
make features/pty
done features/pty
- exec - iffe ${IFFEFLAGS} -v -c "${CC} ${mam_cc_FLAGS} ${KSH_RELFLAGS} ${CCFLAGS} ${LDFLAGS} -lm" ref ${mam_cc_L+-L${INSTALLROOT}/lib} -I${PACKAGE_ast_INCLUDE} -I${INSTALLROOT}/include ${mam_libast} ${mam_libcmd} : run features/pty
+ exec - iffe ${IFFEFLAGS} -v -c "${CC} ${mam_cc_FLAGS} ${KSH_RELFLAGS} ${CCFLAGS} ${LDFLAGS}" ref ${mam_cc_L+-L${INSTALLROOT}/lib} -I${PACKAGE_ast_INCLUDE} -I${INSTALLROOT}/include ${mam_libast} ${mam_libcmd} : run features/pty
done FEATURE/pty generated
make ${PACKAGE_ast_INCLUDE}/ast_time.h implicit
done ${PACKAGE_ast_INCLUDE}/ast_time.h
diff --git a/src/cmd/builtin/features/pty b/src/cmd/builtin/features/pty
index 612609b..ab4a041 100755
--- a/src/cmd/builtin/features/pty
+++ b/src/cmd/builtin/features/pty
@@ -13,7 +13,7 @@ lib openpty,_getpty,ptsname -lutil
lib grantpt,unlockpt,posix_openpt stdlib.h
lib cfmakeraw termios.h
-tst - output{
+tst - -lm output{
#include <fcntl.h>
#if _lib_ptsname
#include <stdlib.h>
diff --git a/src/lib/libdll/Mamfile b/src/lib/libdll/Mamfile
index 0ef420e..29d9ddb 100644
--- a/src/lib/libdll/Mamfile
+++ b/src/lib/libdll/Mamfile
@@ -154,7 +154,7 @@ make install
done features/dll
bind -ldl dontcare
bind -last
- exec - iffe ${IFFEFLAGS} -v -c "${CC} ${mam_cc_FLAGS} ${KSH_RELFLAGS} ${CCFLAGS} ${LDFLAGS} -lm" ref ${mam_cc_L+-L.} ${mam_cc_L+-L${INSTALLROOT}/lib} -I${PACKAGE_ast_INCLUDE} -I${INSTALLROOT}/include ${mam_libdl} ${mam_libast} : run features/dll
+ exec - iffe ${IFFEFLAGS} -v -c "${CC} ${mam_cc_FLAGS} ${KSH_RELFLAGS} ${CCFLAGS} ${LDFLAGS}" ref ${mam_cc_L+-L.} ${mam_cc_L+-L${INSTALLROOT}/lib} -I${PACKAGE_ast_INCLUDE} -I${INSTALLROOT}/include ${mam_libdl} ${mam_libast} : run features/dll
done FEATURE/dll generated
exec - cmp 2>/dev/null -s FEATURE/dll dlldefs.h || { rm -f dlldefs.h; silent test -d . || mkdir .; cp FEATURE/dll dlldefs.h; }
done dlldefs.h generated
diff --git a/src/lib/libdll/features/dll b/src/lib/libdll/features/dll
index e5d5790..86163b4 100644
--- a/src/lib/libdll/features/dll
+++ b/src/lib/libdll/features/dll
@@ -74,7 +74,7 @@ tst run{
esac
echo "#define _DLL_NEXT_PATH \"$lib\""
}end
-tst - output{
+tst - -lm output{
#include <math.h>
#if defined(__MVS__) && !defined(__SUSV3)
#define __SUSV3 1 |
|
Now the only problem is getting versions of --- a/src/lib/libast/comp/atexit.c
+++ b/src/lib/libast/comp/atexit.c
@@ -34,6 +34,8 @@ NoN(atexit)
#else
+#undef _lib_on_exit
+
#if _lib_onexit || _lib_on_exit
#if !_lib_onexit
# The fmtdev change is just to fix a macro related problem with glibc
--- a/src/lib/libast/string/fmtdev.c
+++ b/src/lib/libast/string/fmtdev.c
@@ -30,6 +30,9 @@
#include <ast.h>
#include <ctype.h>
#include <ls.h>
+#ifdef __linux__
+#include <sys/sysmacros.h>
+#endif
char*
fmtdev(struct stat* st)The libdll feature test doesn't start failing until ksh93r 2006-01-24. Importing the ksh93q version of iffe fixes the libdll failure (after changing one |
|
Here is the result of a 20-iteration shbench test on my FreeBSD 12.2 VPS on ksh 93u+m versions compiled with all three compilers (clang 10.0.1, gcc 9.3.0, tcc latest git) with flags |
|
The shbench results are interesting, but the main reason to use tcc is for how fast it compiles (which allows patches to be tested quickly). These are the results I get from a timed |
If this tcc commit introduces some real issue, then you should report it to the tcc mailing list.
Dunno, clang and tcc seems about the same (not highly surprising considering no speed optimizations are enabled), and gcc is somewhat faster usually, but not so much different than the others. To me this indicates more than anything that these bench scripts are bound by things other than pure code execution. However, I didn't look at what these bench scripts do, so it is possible that they test pure execution performance (e.g. if there are not many subshells and IO). EDIT - looking at the clang/tcc numbers again, are you sure you didn't accidentally use the same binary? they're really close to eachother - more than I'd think they would be. |
I presume the build is not parallel? otherwise tcc is usually about 10x faster than gcc, while your results are less than 4x. |
The current problem is that versions of tcc older than the referenced commit can't compile ksh because they don't provide the
The current |
|
Right, I misunderstood then. I thought you meant one needs a tcc version older than dd60b20c in order to build ksh. Thanks.
Not worth it IMHO. 0.9.27 is fairly old now, and the next version will probably be released at some near-ish stage. There has been a LOT of progress in tcc since 0.9.27. |
|
I personally tend to agree that targeting tcc 0.9.27 and earlier is probably not worth the effort. There have been a lot of changes in iffe between 2006-01-24 and the previous version in the ksh multishell repo, so finding a workaround would be a challenge. I'm happy to merge this as it is now. @JohnoKing, how do you feel about that? |
|
I have to agree that finding a workaround isn't going to be worthwhile (errors related to |
In this case, the smaller-than-expected speedup while building with tcc might also be attributed to inefficiencies of the build system. I've seen it elsewhere too, where using tcc starts exposing bottlenecks of the build system (specifically, waf, while building mpv). Not suggesting it should be improved though. Just a data point. |
This bug was reported to me by Chase (one of the CDE contributers) via email:
I've attempted to fix this bug in the patch below, with limited success. It only fixes the compile on Linux and requires a relatively recent version of
tccto build (tcccommit dd60b20c or later). Even with the patch belowtccfails to compile ksh on FreeBSD and it breaksptyon illumos:The text was updated successfully, but these errors were encountered: