Open shdon opened 2 years ago
Thanks @shdon, I'll try to figure out a suitable fix. It'd be great if you could try the fix :)
@shdon Could you provide me output from the following:
djgpp -E -x c -dM /dev/null
I'm trying to figure out which existing platform djgpp currently matches (I'm guessing it's generic Unix but just want to be sure). It can maybe be handled there as a spot fix, or maybe djgpp should have its own platform file.
I figure the most relevant ones are (the variants of) __MSDOS__
, __unix__
, __GNUC__
and __DJGPP
.
Just to be sure, could you show the printout from:
print(Duktape.env);
Using Duktape's built-in print
function it terminates with a SIGABRT
, but substituting in my own implementation, I get the output: ll p nl p2 a8 x86 unknown gcc
Ok, so it's most likely detected as "generic UNIX".
Any idea why the built-in print() would SIGABRT?
@shdon Could you check if https://github.com/svaarala/duktape/pull/2473 works for you, and what Duktape.env
you get with it?
Had some trouble getting configure.py to run, as I didn't have PyYAML that was compatible with Python 2 (configure.py doesn't like Python 3) and compiling duktape.c takes a few minutes on my old DOS machine, but eventually got it done. The new Duktape.env is ll p nl p2 a8 x86 msdos djgpp
Next I'll try to see if I can find out where duk__print
is failing.
Ah, you can ignore that bit. I got the Duktape.env from my test program, which simply didn't include print()
and alert()
, so the SIGABRT was effectively just a ReferenceError: identifier 'print' undefined
.
:+1: So looks good in this pull now?
Re: SIGABRT, it's best practice for the first call into Duktape to be a protected one (e.g. duk_safe_call()) so that you should not easily be able to invoke an abort.
This was just a very simple 3-line test program:
duk_context *ctx = duk_create_heap_default ();
duk_eval_string_nosult (ctx, "print(Duktape.env);");
duk_destroy_heap (ctx);
Mostly as the build environment has been a nightmare to set up and I didn't want to jump through hoops to get the cmdline sample to build, but ended up doing that anyway.
And yeah, it looks good! Glad to see it is set to show up in 2.8.0 already, without having to wait for 3.0.0 😊
Ok, merging -- thanks for the testing effort!
Can we have a .1 release with this? I'm porting tic80 to djgpp and this is one of pieces it needs
There is a very simple fix, though... I added in
in duk_config.h after the OS/compiler detection logic and my test program compiled and ran flawlessly.