On 2013-06-14 21:06, Thorsten Glaser wrote:
Hi,
instead of sending this to me Ib> in public, on the miros-mksh@ list b> bounce
those mails there and will follow up in public.
Hi
sure you can do that. I just thought this to be a bit too "fringe" to
actually be of general interest.
Jens Staal dixit:
Naturally curious as I am, I started to play with trying to compile mksh with
openwatcom on Linux (Arch x86_64) - mostly due to nostalgia with all the Dos4GW
Oh, Watcom now exists for Linux? Do you have any further information
on that (does it come with source; is it even Open Source; does it
exist in Debian, is it portable to MirBSD, what (CPU) architectures
are supported)?
The official version is handled by perfoce, which is somewhat annoying,
but source tarballs are available along with x86/x86_64 Linux binaries.
http://www.openwatcom.org/index.php/Downloads
There is also a github mirror/fork
https://github.com/open-watcom
but I failed building that one...
It seems like the tests choke on a number of places (preprocessor does not
successfully identify watcom etc...).
Feel free to suggest fixes for that ;-)
I will if I figure it out... basically trial-and-error stuff at the
moment. Just realized that setting CC=owcc instead of CC=wc386 makes a
lot of the tests work.
The only way I found that was thanks to stored e-mail stuff found via
google related to using gmake Makefiles instead of wmake ones.
Documentation is definitely scarse.
Stuff I do need to try to figure out is whether I need to
define some other stuff like AR, RANLIB or similar (I also played with
trying to build suckless.org sbase (aiming for small stuff with no
external dependencies) and got as far as the "util.a" library but could
not link it to make a binary - got errorcodes that are "ungoogleable").
and the libc bundled with openwatcom does
not contain some headers that seems to be needed.
mksh does need a somewhat Unix environment. If you can share what
headers are missingb> make them optional and/or include/check for different
headers.
apparently just doing "touch pwd.h" is enough to pass that test.
fork() is an absolute requirement however, so a DOS-like environment
including djgpp (I tried! But bash.exe segfaulted trying to run
Build.shb>
cool. I will grep around a bit among the headers and clib sources to see
what is in there (there should be some posix stuff).
Are there any tricks to get through the Build.sh?
Depends mostly on the place. Header checks are easy, others, not so.
At the moment is stops at:
___________________________________________________________________
Build.sh: Finished configuration testing, now producing output.
owcc -zq -I. -I/opt/watcom/h -I/opt/watcom/lh -DMKSH_BUILDSH
-D_GNU_SOURCE -DSETUID_CAN_FAIL_WITH_EAGAIN -DHAVE_ATTRIBUTE_BOUNDED=0
-DHAVE_ATTRIBUTE_FORMAT=0 -DHAVE_ATTRIBUTE_NORETURN=0
-DHAVE_ATTRIBUTE_UNUSED=0 -DHAVE_ATTRIBUTE_USED=0 -DHAVE_SYS_TIME_H=1
-DHAVE_TIME_H=1 -DHAVE_BOTH_TIME_H=1 -DHAVE_SYS_BSDTYPES_H=0
-DHAVE_SYS_FILE_H=0 -DHAVE_SYS_MKDEV_H=0 -DHAVE_SYS_MMAN_H=1
-DHAVE_SYS_PARAM_H=0 -DHAVE_SYS_RESOURCE_H=0 -DHAVE_SYS_SELECT_H=0
-DHAVE_SYS_SYSMACROS_H=0 -DHAVE_BSTRING_H=0 -DHAVE_GRP_H=0
-DHAVE_LIBGEN_H=1 -DHAVE_LIBUTIL_H=0 -DHAVE_PATHS_H=0 -DHAVE_STDINT_H=1
-DHAVE_STRINGS_H=1 -DHAVE_TERMIOS_H=1 -DHAVE_ULIMIT_H=0
-DHAVE_VALUES_H=0 -DHAVE_CAN_INTTYPES=1 -DHAVE_CAN_UCBINTS=1
-DHAVE_CAN_INT8TYPE=1 -DHAVE_CAN_UCBINT8=1 -DHAVE_RLIM_T=0
-Dsig_t=nosig_t -DHAVE_SIG_T=0 -Dsys_nerr=_sys_nerr
-Dsys_errlist=_sys_errlist -DHAVE_SYS_ERRLIST=1 -DHAVE_SYS_SIGNAME=0
-DHAVE_SYS_SIGLIST=0 -DHAVE_FLOCK=0 -DHAVE_LOCK_FCNTL=0
-DHAVE_GETRUSAGE=0 -DHAVE_GETTIMEOFDAY=1 -DHAVE_KILLPG=0
-DHAVE_MEMMOVE=1 -DHAVE_MKNOD=0 -DHAVE_MMAP=0 -DHAVE_NICE=1
-DHAVE_REVOKE=0 -DHAVE_SETLOCALE_CTYPE=1 -DHAVE_LANGINFO_CODESET=0
-DHAVE_SELECT=1 -DHAVE_SETRESUGID=0 -DHAVE_SETGROUPS=0 -DHAVE_STRERROR=0
-DHAVE_STRSIGNAL=0 -DHAVE_STRLCPY=1 -DHAVE_FLOCK_DECL=1
-DHAVE_REVOKE_DECL=1 -DHAVE_SYS_ERRLIST_DECL=1 -DHAVE_SYS_SIGLIST_DECL=0
-DHAVE_PERSISTENT_HISTORY=0 -DMKSH_BUILD_R=461 -c lalloc.c
sh.h(701): Error! E1022: Missing or misspelled data type near 'sigjmp_buf'
sh.h(983): Error! E1022: Missing or misspelled data type near 'sigset_t'
Error: Compiler returned a bad status compiling 'lalloc.c'
_____________________________________________________________________
so it seems to get through most of the stuff. I will have to check more
what the clib says...
There were lots of warnings earlier also about types so I will perhaps
have to look at that too.
Or is the watcom support abandoned?
Thereb> from IRC, but only b> myself, either.
ah ok :) Well... there is the open source version ;)
There seems to be a lot of warnings during the tests...
Thatb> a reasonable level still) a minor bug for b>
I suggest you speak to RT on IRC and/or try to get me a Watcom b:
heh well the openwatcom is out there... I am mostly curious to see how
well the resulting binaries will perform ;)
bye,
//mirabilos
