If you want to report bugs, propose fixes or suggest enhancements, please use the -GitHub issue tracker. +» GitHub issue tracker.
Please send general questions to the -» LuaJIT mailing list. +» LuaJIT mailing list.
You can also send any questions you have directly to me: @@ -93,7 +89,7 @@
All documentation is -Copyright © 2005-2017 Mike Pall. +Copyright © 2005-2021 Mike Pall.
@@ -101,7 +97,7 @@+The string buffer library allows high-performance manipulation of +string-like data. +
++Unlike Lua strings, which are constants, string buffers are +mutable sequences of 8-bit (binary-transparent) characters. Data +can be stored, formatted and encoded into a string buffer and later +converted, extracted or decoded. +
++The convenient string buffer API simplifies common string manipulation +tasks, that would otherwise require creating many intermediate strings. +String buffers improve performance by eliminating redundant memory +copies, object creation, string interning and garbage collection +overhead. In conjunction with the FFI library, they allow zero-copy +operations. +
++The string buffer libary also includes a high-performance +serializer for Lua objects. +
+ ++This library is a work in progress. More +functionality will be added soon. +
+ ++The string buffer library is built into LuaJIT by default, but it's not +loaded by default. Add this to the start of every Lua file that needs +one of its functions: +
+
+local buffer = require("string.buffer")
+
++The convention for the syntax shown on this page is that buffer +refers to the buffer library and buf refers to an individual +buffer object. +
++Please note the difference between a Lua function call, e.g. +buffer.new() (with a dot) and a Lua method call, e.g. +buf:reset() (with a colon). +
+ ++A buffer object is a garbage-collected Lua object. After creation with +buffer.new(), it can (and should) be reused for many operations. +When the last reference to a buffer object is gone, it will eventually +be freed by the garbage collector, along with the allocated buffer +space. +
++Buffers operate like a FIFO (first-in first-out) data structure. Data +can be appended (written) to the end of the buffer and consumed (read) +from the front of the buffer. These operations may be freely mixed. +
++The buffer space that holds the characters is managed automatically +— it grows as needed and already consumed space is recycled. Use +buffer.new(size) and buf:free(), if you need more +control. +
++The maximum size of a single buffer is the same as the maximum size of a +Lua string, which is slightly below two gigabytes. For huge data sizes, +neither strings nor buffers are the right data structure — use the +FFI library to directly map memory or files up to the virtual memory +limit of your OS. +
+ ++Creates a new buffer object. +
++The optional size argument ensures a minimum initial buffer +size. This is strictly an optimization when the required buffer size is +known beforehand. The buffer space will grow as needed, in any case. +
++The optional table options sets various +serialization options. +
+ ++Reset (empty) the buffer. The allocated buffer space is not freed and +may be reused. +
+ ++The buffer space of the buffer object is freed. The object itself +remains intact, empty and may be reused. +
++Note: you normally don't need to use this method. The garbage collector +automatically frees the buffer space, when the buffer object is +collected. Use this method, if you need to free the associated memory +immediately. +
+ ++Appends a string str, a number num or any object +obj with a __tostring metamethod to the buffer. +Multiple arguments are appended in the given order. +
++Appending a buffer to a buffer is possible and short-circuited +internally. But it still involves a copy. Better combine the buffer +writes to use a single buffer. +
+ ++Appends the formatted arguments to the buffer. The format +string supports the same options as string.format(). +
+ ++Appends the given len number of bytes from the memory pointed +to by the FFI cdata object to the buffer. The object needs to +be convertible to a (constant) pointer. +
+ ++This method allows zero-copy consumption of a string or an FFI cdata +object as a buffer. It stores a reference to the passed string +str or the FFI cdata object in the buffer. Any buffer +space originally allocated is freed. This is not an append +operation, unlike the buf:put*() methods. +
++After calling this method, the buffer behaves as if +buf:free():put(str) or buf:free():put(cdata, len) +had been called. However, the data is only referenced and not copied, as +long as the buffer is only consumed. +
++In case the buffer is written to later on, the referenced data is copied +and the object reference is removed (copy-on-write semantics). +
++The stored reference is an anchor for the garbage collector and keeps the +originally passed string or FFI cdata object alive. +
+ ++The reserve method reserves at least size bytes of +write space in the buffer. It returns an uint8_t * FFI +cdata pointer ptr that points to this space. +
++The available length in bytes is returned in len. This is at +least size bytes, but may be more to facilitate efficient +buffer growth. You can either make use of the additional space or ignore +len and only use size bytes. +
++The commit method appends the used bytes of the +previously returned write space to the buffer data. +
++This pair of methods allows zero-copy use of C read-style APIs: +
+
+local MIN_SIZE = 65536
+repeat
+ local ptr, len = buf:reserve(MIN_SIZE)
+ local n = C.read(fd, ptr, len)
+ if n == 0 then break end -- EOF.
+ if n < 0 then error("read error") end
+ buf:commit(n)
+until false
+
++The reserved write space is not initialized. At least the +used bytes must be written to before calling the +commit method. There's no need to call the commit +method, if nothing is added to the buffer (e.g. on error). +
+ ++Returns the current length of the buffer data in bytes. +
+ ++The Lua concatenation operator .. also accepts buffers, just +like strings or numbers. It always returns a string and not a buffer. +
++Note that although this is supported for convenience, this thwarts one +of the main reasons to use buffers, which is to avoid string +allocations. Rewrite it with buf:put() and buf:get(). +
++Mixing this with unrelated objects that have a __concat +metamethod may not work, since these probably only expect strings. +
+ ++Skips (consumes) len bytes from the buffer up to the current +length of the buffer data. +
+ ++Consumes the buffer data and returns one or more strings. If called +without arguments, the whole buffer data is consumed. If called with a +number, up to len bytes are consumed. A nil argument +consumes the remaining buffer space (this only makes sense as the last +argument). Multiple arguments consume the buffer data in the given +order. +
++Note: a zero length or no remaining buffer data returns an empty string +and not nil. +
+ ++Creates a string from the buffer data, but doesn't consume it. The +buffer remains unchanged. +
++Buffer objects also define a __tostring metamethod. This means +buffers can be passed to the global tostring() function and +many other functions that accept this in place of strings. The important +internal uses in functions like io.write() are short-circuited +to avoid the creation of an intermediate string object. +
+ ++Returns an uint8_t * FFI cdata pointer ptr that +points to the buffer data. The length of the buffer data in bytes is +returned in len. +
++The returned pointer can be directly passed to C functions that expect a +buffer and a length. You can also do bytewise reads +(local x = ptr[i]) or writes +(ptr[i] = 0x40) of the buffer data. +
++In conjunction with the skip method, this allows zero-copy use +of C write-style APIs: +
+
+repeat
+ local ptr, len = buf:ref()
+ if len == 0 then break end
+ local n = C.write(fd, ptr, len)
+ if n < 0 then error("write error") end
+ buf:skip(n)
+until n >= len
+
++Unlike Lua strings, buffer data is not implicitly +zero-terminated. It's not safe to pass ptr to C functions that +expect zero-terminated strings. If you're not using len, then +you're doing something wrong. +
+ ++The following functions and methods allow high-speed serialization +(encoding) of a Lua object into a string and decoding it back to a Lua +object. This allows convenient storage and transport of structured +data. +
++The encoded data is in an internal binary +format. The data can be stored in files, binary-transparent +databases or transmitted to other LuaJIT instances across threads, +processes or networks. +
++Encoding speed can reach up to 1 Gigabyte/second on a modern desktop- or +server-class system, even when serializing many small objects. Decoding +speed is mostly constrained by object creation cost. +
++The serializer handles most Lua types, common FFI number types and +nested structures. Functions, thread objects, other FFI cdata and full +userdata cannot be serialized (yet). +
++The encoder serializes nested structures as trees. Multiple references +to a single object will be stored separately and create distinct objects +after decoding. Circular references cause an error. +
+ ++Serializes (encodes) the Lua object obj. The stand-alone +function returns a string str. The buffer method appends the +encoding to the buffer. +
++obj can be any of the supported Lua types — it doesn't +need to be a Lua table. +
++This function may throw an error when attempting to serialize +unsupported object types, circular references or deeply nested tables. +
+ ++The stand-alone function de-serializes (decodes) the string +str, the buffer method de-serializes one object from the +buffer. Both return a Lua object obj. +
++The returned object may be any of the supported Lua types — +even nil. +
++This function may throw an error when fed with malformed or incomplete +encoded data. The stand-alone function throws when there's left-over +data after decoding a single top-level object. The buffer method leaves +any left-over data in the buffer. +
+ ++The options table passed to buffer.new() may contain +the following members (all optional): +
++dict needs to be an array of strings and metatable needs +to be an array of tables. Both starting at index 1 and without holes (no +nil inbetween). The tables are anchored in the buffer object and +internally modified into a two-way index (don't do this yourself, just pass +a plain array). The tables must not be modified after they have been passed +to buffer.new(). +
++The dict and metatable tables used by the encoder and +decoder must be the same. Put the most common entries at the front. Extend +at the end to ensure backwards-compatibility — older encodings can +then still be read. You may also set some indexes to false to +explicitly drop backwards-compatibility. Old encodings that use these +indexes will throw an error when decoded. +
++Metatables that are not found in the metatable dictionary are +ignored when encoding. Decoding returns a table with a nil +metatable. +
++Note: parsing and preparation of the options table is somewhat +expensive. Create a buffer object only once and recycle it for multiple +uses. Avoid mixing encoder and decoder buffers, since the +buf:set() method frees the already allocated buffer space: +
+
+local options = {
+ dict = { "commonly", "used", "string", "keys" },
+}
+local buf_enc = buffer.new(options)
+local buf_dec = buffer.new(options)
+
+local function encode(obj)
+ return buf_enc:reset():encode(obj):get()
+end
+
+local function decode(str)
+ return buf_dec:set(str):decode()
+end
+
+
++In some contexts, it's desirable to do piecewise serialization of large +datasets, also known as streaming. +
++This serialization format can be safely concatenated and supports streaming. +Multiple encodings can simply be appended to a buffer and later decoded +individually: +
++local buf = buffer.new() +buf:encode(obj1) +buf:encode(obj2) +local copy1 = buf:decode() +local copy2 = buf:decode() ++
+Here's how to iterate over a stream: +
++while #buf ~= 0 do + local obj = buf:decode() + -- Do something with obj. +end ++
+Since the serialization format doesn't prepend a length to its encoding, +network applications may need to transmit the length, too. +
+ ++This serialization format is designed for internal use by LuaJIT +applications. Serialized data is upwards-compatible and portable across +all supported LuaJIT platforms. +
++It's an 8-bit binary format and not human-readable. It uses e.g. +embedded zeroes and stores embedded Lua string objects unmodified, which +are 8-bit-clean, too. Encoded data can be safely concatenated for +streaming and later decoded one top-level object at a time. +
++The encoding is reasonably compact, but tuned for maximum performance, +not for minimum space usage. It compresses well with any of the common +byte-oriented data compression algorithms. +
++Although documented here for reference, this format is explicitly +not intended to be a 'public standard' for structured data +interchange across computer languages (like JSON or MessagePack). Please +do not use it as such. +
++The specification is given below as a context-free grammar with a +top-level object as the starting point. Alternatives are +separated by the | symbol and * indicates repeats. +Grouping is implicit or indicated by {…}. Terminals are +either plain hex numbers, encoded as bytes, or have a .format +suffix. +
+
+object → nil | false | true
+ | null | lightud32 | lightud64
+ | int | num | tab | tab_mt
+ | int64 | uint64 | complex
+ | string
+
+nil → 0x00
+false → 0x01
+true → 0x02
+
+null → 0x03 // NULL lightuserdata
+lightud32 → 0x04 data.I // 32 bit lightuserdata
+lightud64 → 0x05 data.L // 64 bit lightuserdata
+
+int → 0x06 int.I // int32_t
+num → 0x07 double.L
+
+tab → 0x08 // Empty table
+ | 0x09 h.U h*{object object} // Key/value hash
+ | 0x0a a.U a*object // 0-based array
+ | 0x0b a.U a*object h.U h*{object object} // Mixed
+ | 0x0c a.U (a-1)*object // 1-based array
+ | 0x0d a.U (a-1)*object h.U h*{object object} // Mixed
+tab_mt → 0x0e (index-1).U tab // Metatable dict entry
+
+int64 → 0x10 int.L // FFI int64_t
+uint64 → 0x11 uint.L // FFI uint64_t
+complex → 0x12 re.L im.L // FFI complex
+
+string → (0x20+len).U len*char.B
+ | 0x0f (index-1).U // String dict entry
+
+.B = 8 bit
+.I = 32 bit little-endian
+.L = 64 bit little-endian
+.U = prefix-encoded 32 bit unsigned number n:
+ 0x00..0xdf → n.B
+ 0xe0..0x1fdf → (0xe0|(((n-0xe0)>>8)&0x1f)).B ((n-0xe0)&0xff).B
+ 0x1fe0.. → 0xff n.I
+
+
++Many of the buffer methods can throw an error. Out-of-memory or usage +errors are best caught with an outer wrapper for larger parts of code. +There's not much one can do after that, anyway. +
++OTOH you may want to catch some errors individually. Buffer methods need +to receive the buffer object as the first argument. The Lua colon-syntax +obj:method() does that implicitly. But to wrap a method with +pcall(), the arguments need to be passed like this: +
++local ok, err = pcall(buf.encode, buf, obj) +if not ok then + -- Handle error in err. +end ++ +
+The string buffer library has been designed to work well together with +the FFI library. But due to the low-level nature of the FFI library, +some care needs to be taken: +
++First, please remember that FFI pointers are zero-indexed. The space +returned by buf:reserve() and buf:ref() starts at the +returned pointer and ends before len bytes after that. +
++I.e. the first valid index is ptr[0] and the last valid index +is ptr[len-1]. If the returned length is zero, there's no valid +index at all. The returned pointer may even be NULL. +
++The space pointed to by the returned pointer is only valid as long as +the buffer is not modified in any way (neither append, nor consume, nor +reset, etc.). The pointer is also not a GC anchor for the buffer object +itself. +
++Buffer data is only guaranteed to be byte-aligned. Casting the returned +pointer to a data type with higher alignment may cause unaligned +accesses. It depends on the CPU architecture whether this is allowed or +not (it's always OK on x86/x64 and mostly OK on other modern +architectures). +
++FFI pointers or references do not count as GC anchors for an underlying +object. E.g. an array allocated with ffi.new() is +anchored by buf:set(array, len), but not by +buf:set(array+offset, len). The addition of the offset +creates a new pointer, even when the offset is zero. In this case, you +need to make sure there's still a reference to the original array as +long as its contents are in use by the buffer. +
++Even though each LuaJIT VM instance is single-threaded (but you can +create multiple VMs), FFI data structures can be accessed concurrently. +Be careful when reading/writing FFI cdata from/to buffers to avoid +concurrent accesses or modifications. In particular, the memory +referenced by buf:set(cdata, len) must not be modified +while buffer readers are working on it. Shared, but read-only memory +mappings of files are OK, but only if the file does not change. +
+The third argument specifies the mode, which is 'or'ed with a flag. -The flag can be LUAJIT_MODE_OFF to turn a feature on, -LUAJIT_MODE_ON to turn a feature off, or +The flag can be LUAJIT_MODE_OFF to turn a feature off, +LUAJIT_MODE_ON to turn a feature on, or LUAJIT_MODE_FLUSH to flush cached code.
@@ -179,7 +175,7 @@
All standard Lua metamethods are implemented. These are called directly, @@ -469,6 +465,8 @@
The main use for parameterized types are libraries implementing abstract data types -(» example), +(» example), similar to what can be achieved with C++ template metaprogramming. Another use case are derived types of anonymous structs, which avoids pollution of the global struct namespace. @@ -1225,7 +1221,7 @@
The following code shows how to access the zlib compression library from Lua code. +href="https://zlib.net/">» zlib compression library from Lua code. We'll define two convenience wrapper functions that take a string and compress or uncompress it to another string:
@@ -305,7 +301,7 @@Contains the target architecture name: -"x86", "x64", "arm", "arm64", "ppc", "mips" or "mips64". +"x86", "x64", "arm", "arm64", "arm64be", "ppc", "mips", "mipsel", "mips64", "mips64el", "mips64r6", "mips64r6el".
LuaJIT is fully upwards-compatible with Lua 5.1. It supports all -» standard Lua +» standard Lua library functions and the full set of -» Lua/C API +» Lua/C API functions.
@@ -105,7 +101,7 @@
LuaJIT supports all bitwise operations as defined by -» Lua BitOp: +» Lua BitOp:
bit.tobit bit.tohex bit.bnot bit.band bit.bor bit.bxor @@ -114,7 +110,7 @@bit.* — Bitwise operations
This module is a LuaJIT built-in — you don't need to download or install Lua BitOp. The Lua BitOp site has full documentation for all -» Lua BitOp API functions. +» Lua BitOp API functions. The FFI adds support for 64 bit bitwise operations, using the same API functions. @@ -209,9 +205,8 @@
string.dump(f [,strip]) generates portable bytecod
Note: LJ_GC64 mode requires a different frame layout, which implies -a different, incompatible bytecode format for ports that use this mode (e.g. -ARM64 or MIPS64) or when explicitly enabled for x64. This may be rectified -in the future. +a different, incompatible bytecode format for all 64 bit ports. This may be +rectified in the future.
table.new(narray, nhash) allocates a pre-sized table
@@ -254,6 +249,10 @@Enhanced PRNG for math.random()
It's correctly scaled up and rounded for math.random(n [,m]) to preserve uniformity. ++Important: Neither this nor any other PRNG based on the simplistic +math.random() API is suitable for cryptographic use. +
io.* functions handle 64 bit file offsets
@@ -374,6 +373,7 @@
Extensions from Lua 5.3
Please read the instructions given in these files, before changing any settings.
-LuaJIT on x64 currently uses 32 bit GC objects by default. -LJ_GC64 mode may be explicitly enabled: -add XCFLAGS=-DLUAJIT_ENABLE_GC64 to the make command or run -msvcbuild gc64 for MSVC/WinSDK. Please check the note -about the bytecode format -differences, too. +All LuaJIT 64 bit ports use 64 bit GC objects by default (LJ_GC64). +For x64, you can select the old 32-on-64 bit mode by adding +XCFLAGS=-DLUAJIT_DISABLE_GC64 to the make command. +Please check the note about the +bytecode format differences, too.
-Depending on your distribution, you may need to install a package for @@ -192,14 +187,19 @@
-Download the current source package of LuaJIT (pick the .tar.gz), -if you haven't already done so. Move it to a directory of your choice, -open a terminal window and change to this directory. Now unpack the archive -and change to the newly created directory: +The recommended way to fetch the latest version is to do a pull from +the git repository. +
++Alternatively download the latest source package of LuaJIT (pick the .tar.gz). +Move it to a directory of your choice, open a terminal window and change +to this directory. Now unpack the archive and change to the newly created +directory (replace XX.YY.ZZ with the version you downloaded):
-tar zxf LuaJIT-2.0.5.tar.gz -cd LuaJIT-2.0.5+tar zxf LuaJIT-XX.YY.ZZ.tar.gz +cd LuaJIT-XX.YY.ZZ +
The supplied Makefiles try to auto-detect the settings needed for your @@ -223,9 +223,12 @@
-Note for OSX: if the MACOSX_DEPLOYMENT_TARGET environment -variable is not set, then it's forced to 10.4. +Note for macOS: you must set the MACOSX_DEPLOYMENT_TARGET +environment variable to a value supported by your toolchain:
++MACOSX_DEPLOYMENT_TARGET=XX.YY make +
The top-level Makefile installs LuaJIT by default under @@ -252,27 +255,18 @@
Either install one of the open source SDKs (» MinGW or -» Cygwin), which come with a modified +» Cygwin), which come with a modified GCC plus the required development headers. +Or install Microsoft's Visual Studio (MSVC).
-Or install Microsoft's Visual C++ (MSVC). The freely downloadable -» Express Edition -works just fine, but only contains an x86 compiler. -
--The freely downloadable -» Windows SDK -only comes with command line tools, but this is all you need to build LuaJIT. -It contains x86 and x64 compilers. -
--Next, download the source package and unpack it using an archive manager -(e.g. the Windows Explorer) to a directory of your choice. +Next, pull from the git repository or download the source package and +unpack it using an archive manager (e.g. the Windows Explorer) to +a directory of your choice.
-Open a "Visual Studio .NET Command Prompt", cd to the +Open a "Visual Studio Command Prompt" (either x86 or x64), cd to the directory where you've unpacked the sources and run these commands:
@@ -280,37 +274,14 @@Building with MSVC
msvcbuild
-Then follow the installation instructions below. -
--Open a "Windows SDK Command Shell" and select the x86 compiler: -
--setenv /release /x86 --
-Or select the x64 compiler: -
--setenv /release /x64 --
-Then cd to the directory where you've unpacked the sources -and run these commands: -
--cd src -msvcbuild --
+Check the msvcbuild.bat file for more options. Then follow the installation instructions below.
Open a command prompt window and make sure the MinGW or Cygwin programs -are in your path. Then cd to the directory where -you've unpacked the sources and run this command for MinGW: +are in your path. Then cd to the directory of the git repository +or where you've unpacked the sources. Then run this command for MinGW:
mingw32-make @@ -365,7 +336,7 @@Cross-compiling LuaJIT
target OS differ, or you'll get assembler or linker errors:
-You can cross-compile for Android using the Android NDK. -The environment variables need to match the install locations and the -desired target platform. E.g. Android 4.0 corresponds to ABI level 14. -For details check the folder docs in the NDK directory. -
--Only a few common variations for the different CPUs, ABIs and platforms -are listed. Please use your own judgement for which combination you want -to build/deploy or which lowest common denominator you want to pick: +You can cross-compile for Android using the » Android NDK. +Please adapt the environment variables to match the install locations and the +desired target platform. E.g. Android 4.1 corresponds to ABI level 16.
-# Android/ARM, armeabi (ARMv5TE soft-float), Android 2.2+ (Froyo) -NDK=/opt/android/ndk -NDKABI=8 -NDKVER=$NDK/toolchains/arm-linux-androideabi-4.9 -NDKP=$NDKVER/prebuilt/linux-x86/bin/arm-linux-androideabi- -NDKF="--sysroot $NDK/platforms/android-$NDKABI/arch-arm" -make HOST_CC="gcc -m32" CROSS=$NDKP TARGET_FLAGS="$NDKF" - -# Android/ARM, armeabi-v7a (ARMv7 VFP), Android 4.0+ (ICS) -NDK=/opt/android/ndk -NDKABI=14 -NDKVER=$NDK/toolchains/arm-linux-androideabi-4.9 -NDKP=$NDKVER/prebuilt/linux-x86/bin/arm-linux-androideabi- -NDKF="--sysroot $NDK/platforms/android-$NDKABI/arch-arm" -NDKARCH="-march=armv7-a -mfloat-abi=softfp -Wl,--fix-cortex-a8" -make HOST_CC="gcc -m32" CROSS=$NDKP TARGET_FLAGS="$NDKF $NDKARCH" +# Android/ARM64, aarch64, Android 5.0+ (L) +NDKDIR=/opt/android/ndk +NDKBIN=$NDKDIR/toolchains/llvm/prebuilt/linux-x86_64/bin +NDKCROSS=$NDKBIN/aarch64-linux-android- +NDKCC=$NDKBIN/aarch64-linux-android21-clang +make CROSS=$NDKCROSS \ + STATIC_CC=$NDKCC DYNAMIC_CC="$NDKCC -fPIC" \ + TARGET_LD=$NDKCC TARGET_AR=$NDKBIN/llvm-ar + TARGET_STRIP=$NDKBIN/llvm-strip -# Android/MIPS, mipsel (MIPS32R1 hard-float), Android 4.0+ (ICS) -NDK=/opt/android/ndk -NDKABI=14 -NDKVER=$NDK/toolchains/mipsel-linux-android-4.9 -NDKP=$NDKVER/prebuilt/linux-x86/bin/mipsel-linux-android- -NDKF="--sysroot $NDK/platforms/android-$NDKABI/arch-mips" -make HOST_CC="gcc -m32" CROSS=$NDKP TARGET_FLAGS="$NDKF" - -# Android/x86, x86 (i686 SSE3), Android 4.0+ (ICS) -NDK=/opt/android/ndk -NDKABI=14 -NDKVER=$NDK/toolchains/x86-4.9 -NDKP=$NDKVER/prebuilt/linux-x86/bin/i686-linux-android- -NDKF="--sysroot $NDK/platforms/android-$NDKABI/arch-x86" -make HOST_CC="gcc -m32" CROSS=$NDKP TARGET_FLAGS="$NDKF" +# Android/ARM, armeabi-v7a (ARMv7 VFP), Android 4.1+ (JB) +NDKDIR=/opt/android/ndk +NDKBIN=$NDKDIR/toolchains/llvm/prebuilt/linux-x86_64/bin +NDKCROSS=$NDKBIN/arm-linux-androideabi- +NDKCC=$NDKBIN/armv7a-linux-androideabi16-clang +make HOST_CC="gcc -m32" CROSS=$NDKCROSS \ + STATIC_CC=$NDKCC DYNAMIC_CC="$NDKCC -fPIC" \ + TARGET_LD=$NDKCC TARGET_AR=$NDKBIN/llvm-ar + TARGET_STRIP=$NDKBIN/llvm-strip
-You can cross-compile for iOS 3.0+ (iPhone/iPad) using the » iOS SDK: +You can cross-compile for iOS 3.0+ (iPhone/iPad) using the » iOS SDK:
Note: the JIT compiler is disabled for iOS, because regular iOS Apps @@ -483,13 +435,6 @@
-# iOS/ARM (32 bit) -ISDKP=$(xcrun --sdk iphoneos --show-sdk-path) -ICC=$(xcrun --sdk iphoneos --find clang) -ISDKF="-arch armv7 -isysroot $ISDKP" -make DEFAULT_CC=clang HOST_CC="clang -m32 -arch i386" \ - CROSS="$(dirname $ICC)/" TARGET_FLAGS="$ISDKF" TARGET_SYS=iOS - # iOS/ARM64 ISDKP=$(xcrun --sdk iphoneos --show-sdk-path) ICC=$(xcrun --sdk iphoneos --find clang) @@ -590,14 +535,6 @@Embedding LuaJIT
intend to load Lua/C modules at runtime. -
--pagezero_size 10000 -image_base 100000000 --
Additional hints for initializing LuaJIT using the C API functions:
LuaJIT is a Just-In-Time Compiler (JIT) for the -» Lua programming language. +» Lua programming language. Lua is a powerful, dynamic and light-weight programming language. It may be embedded or used as a general-purpose, stand-alone language.
-LuaJIT is Copyright © 2005-2017 Mike Pall, released under the -» MIT open source license. +LuaJIT is Copyright © 2005-2021 Mike Pall, released under the +» MIT open source license.
| Windows | Linux | BSD | OSX | POSIX |
| Windows | Linux | BSD | macOS | POSIX |
| Embedded | Android | iOS |