The table below summarizes the platforms and compilers which Duktape is known to work on, with portability notes where appropriate. This is not an exhaustive list of supported/unsupported platforms, rather a list of what is known to work (and not to work). Platform and compiler specific issues are discussed in more detail below the table.
Operating system | Compiler | Processor | Notes |
---|---|---|---|
Linux | GCC | x86 | No known issues. |
Linux | GCC | x64 | No known issues. |
Linux | GCC | x32 | No known issues, use -mx32 . |
Linux | GCC | ARM | No known issues. |
Linux | GCC | MIPS | No known issues. |
Linux | GCC | SuperH | No known issues. |
Linux | GCC | SPARC | No known issues. |
Linux | Clang | x86 | No known issues. |
Linux | Clang | x64 | No known issues. |
Linux | Clang | ARM | No known issues. |
Linux | Clang | MIPS | No known issues. |
Linux | TCC | x64 | Zero sign issues (see below). |
FreeBSD | Clang | x86 | Aliasing issues with clang 3.3 on 64-bit FreeBSD, -m32 , and packed duk_tval (see below). |
FreeBSD | Clang | x64 | No known issues. |
NetBSD | GCC | x86 | No known issues (NetBSD 6.0). There are some pow() function incompatibilities on NetBSD, but
there is a workaround for them. |
OpenBSD | GCC | x86 | No known issues (FreeBSD 5.4). |
Windows | MinGW | x86 | -std=c99 recommended, only ISO 8601 date format supported (no platform specific format). |
Windows | MinGW-w64 | x64 | -m64 , -std=c99 recommended, only ISO 8601 date format supported (no platform specific format). |
Windows | MSVC (Visual Studio Express 2010) |
x86 | Only ISO 8601 date format supported (no platform specific format).
Harmless warnings if /Wp64 is enabled. |
Windows | MSVC (Visual Studio Express 2013 for Windows Desktop) |
x64 | Only ISO 8601 date format supported (no platform specific format). |
Windows | MSVC (Visual Studio 2010) |
x64 | Only ISO 8601 date format supported (no platform specific format).
May require explicit DUK_OPT_NO_PACKED_TVAL with
Duktape 0.10.0. |
Android | GCC (Android NDK) |
ARM | -std=c99 required at least on some NDK versions. |
OSX | Clang | x64 | Tested on OSX 10.9.2 with XCode. |
Darwin | GCC | x86 | No known issues. |
QNX | GCC | x86 | -std=c99 recommended. Architectures other than x86 should also work. |
AmigaOS | VBCC | M68K | Requires some preprocessor defines, datetime resolution limited to full seconds. |
TOS (Atari ST) |
VBCC | M68K | Requires some preprocessor defines, datetime resolution limited to full seconds. |
Emscripten | Emscripten | n/a | Requires additional options, see below. At least V8/NodeJs works. |
Adobe Flash Runtime | CrossBridge (GCC-4.2 with Flash backend) |
n/a | -std=c99 recommended, may need -jvmopt=-Xmx1G if running
32-bit Java. Tested with CrossBridge
1.0.1 on 64-bit Windows 7. |
pNaCl | clang | n/a | No known issues. |
Linux | BCC (Bruce's C compiler) |
i386 | -3 and -ansi required; compiles but doesn't link. This is an
old compiler useful for portability torture tests (for instance 16-bit int type). |
Clang 3.3 on FreeBSD has some aliasing issues (at least) when using
-m32
and when Duktape ends up using a packed duk_tval
value representation type. You can work around the problem by defining
DUK_OPT_NO_PACKED_TVAL
to disable packed value type. The
problem does not appear in all clang versions. Duktape self tests cover
this issue (define DUK_OPT_SELF_TESTS
when compiling).
See internal test file misc/clang_aliasing.c
.
The /Wp64
(Detect 64-bit Portability issues) option causes harmless compile warnings when compiling
32-bit code, e.g.:
duk_api.c(2419): warning C4311: 'type cast' : pointer truncation from 'duk_hstring *' to 'duk_uint32_t'
The warnings are caused by Duktape casting 32-bit pointers to 32-bit integers
used by its internal value representation. These casts would be incorrect in a 64-bit
environment which is reported by the /Wp64
option. When Duktape is
compiled in a 64-bit environment a different value representation is used which
doesn't use these casts at all, so the warnings are not relevant.
Compilation with /Wall
is not clean at the moment.
TCC has zero sign handling issues; Duktape mostly works but zero sign is
not handled correctly. This results in Ecmascript non-compliance, for
instance 1/-0
evaluates to Infinity
, not -Infinity
as it should.
VBCC doesn't appear to provide OS or processor defines. To compile for M68K AmigaOS or TOS you must:
__MC68K__
manually.AMIGA
or __TOS__
manually.Datetime resolution is limited to full seconds only when using VBCC on AmigaOS or TOS.
Needs a set of emcc
options. When executed with
V8, the following seem to work:
-DEMSCRIPTEN
: mandatory option, needed by Duktape
to detect Emscripten. Without this Duktape may use unaligned accesses
which Emscripten does not allow. This results in odd and inconsistent
behavior, and is not necessarily caught by Duktape self tests.-std=c99
-O2
-s ASM_JS=0
-s MAX_SETJMPS=1000
-s OUTLINING_LIMIT=20000
Dukweb is compiled using Emscripten, so you can also check out the Duktape git repository to see how Dukweb is compiled.
-std=c99
or similar). Type
detection without C99 is less reliable than with C99.DUK_OPT_SELF_TESTS
. Self tests
detect some compiler and platform issues which cannot be caught
compile time.DUK_OPT_FORCE_ALIGN=4
or DUK_OPT_FORCE_ALIGN=8
.
The alignment number should match whatever alignment is needed for IEEE
doubles and 64-bit integer values.DUK_OPT_FORCE_BYTEORDER
to force endianness as a workaround.
If you know how the endianness detection should work on your platform,
please send an e-mail about the issue or contribute a patch.duk_features.h
does not yet handle the target platform
correctly. This is usually trivial to fix; please contribute a patch if
you do so. At other times the platform has no standard time APIs (like
POSIX). In this case you'll need to add a few platform specific Date
functions into duk_bi_date.c
, and implement platform detection
into duk_features.h
; again, please contribute a patch if you
do so. You can look at duk_bi_date.c
for POSIX and Windows
Date API examples.