From ddae8878786a310f2e6cbe2a1d602a17ea28bb11 Mon Sep 17 00:00:00 2001
From: Mike Pall
-LuaJIT currently builds out-of-the box on most x86 or x64 systems.
+LuaJIT currently builds out-of-the box on most systems.
Here's the compatibility matrix for the supported combinations of
operating system, CPU and compilers:
-This always builds a native x86 or x64 binary, depending on your OS.
+This always builds a native x86, x64 or PPC binary, depending on the host OS
+you're running this command on. Check the section on
+cross-compilation for more options.
-By default modules are only searched under the prefix /usr/local.
+By default, modules are only searched under the prefix /usr/local.
You can add an extra prefix to the search paths by appending the
PREFIX option, e.g.:
@@ -147,10 +156,12 @@ which is probably the default on your system, anyway. Simply run:
make
-
Operating system
+OS / CPU
x86 (32 bit)
x64 (64 bit)
+PPC/e500v2
-
Linux
+Linux
GCC 4.x
GCC 3.4GCC 4.x
+GCC 4.3+
-
Windows 98/XP/Vista/7
+Windows
98/XP/Vista/7MSVC (EE)
Windows SDK
MinGW (GCC)
Cygwin (GCC)MSVC + SDK v7.0
+
Windows SDK v7.0
-
OSX 10.3-10.6
+OSX 10.3-10.6
GCC 4.x
GCC 3.4GCC 4.x
+
-
*BSD, other
+*BSD, other
GCC 4.x
GCC 3.4(not supported)
+
The build system has limited support for cross-compilation. For details check the comments in src/Makefile. Here are some popular examples: @@ -303,36 +314,130 @@ installing the mingw32 package and running:
make HOST_CC="gcc -m32" CROSS=i586-mingw32msvc- TARGET_SYS=Windows+
+You can cross-compile for a PPC/e500v2 target on an x86 or x64 host system +using a standard GNU cross-compile toolchain (Binutils, GCC, EGLIBC). +The CROSS prefix may vary depending on the --target +of the toolchain: +
++make HOST_CC="gcc -m32" CROSS=powerpc-e500v2-linux-gnuspe- TARGET=ppcspe +-
LuaJIT is API-compatible with Lua 5.1. If you've already embedded Lua into your application, you probably don't need to do anything to switch -to LuaJIT, except link with a different library. Additional hints: +to LuaJIT, except link with a different library:
+-pagezero_size 10000 -image_base 100000000 ++Also, it's recommended to rebase all (self-compiled) shared libraries +which are loaded at runtime on OSX/x64 (e.g. C extension modules for Lua). +See: man rebase +
Additional hints for initializing LuaJIT using the C API functions:
++The LuaJIT build system has extra provisions for the needs of most +POSIX-based distributions. If you're a package maintainer for +a distribution, please make use of these features and +avoid patching, subverting, autotoolizing or messing up the build system +in unspeakable ways. +
++There should be absolutely no need to patch luaconf.h or any +of the Makefiles. And please do not hand-pick files for your packages — +simply use whatever make install creates. There's a reason +for all of the files and directories it creates. +
++The build system uses GNU make and autodetects most settings based on +the host you're building it on. This should work fine for native builds, +even when sandboxed. You may need to pass some of the following flags to +both the make and the make install command lines +for a regular distribution build: +
++The build system has a special target for an amalgamated build, i.e. +make amalg. This compiles the LuaJIT core as one huge C file +and allows GCC to generate faster and shorter code. Alas, this requires +lots of memory during the build. This may be a problem for some users, +that's why it's not enabled by default. But it shouldn't be a problem for +most build farms. It's recommended that binary distributions use this +target for their LuaJIT builds. +
-64 bit applications on OSX must be linked with these options -(only the main executable): +The tl;dr version of the above:
--pagezero_size 10000 -image_base 100000000 +make amalg PREFIX=/usr && \ +make install PREFIX=/usr DESTDIR=/tmp/buildroot
-It's recommended to rebase all (self-compiled) shared libraries -which are loaded at runtime on OSX/x64 (e.g. C extension modules for Lua). -See: man rebase +Finally, if you encounter any difficulties, please +contact me first, instead of releasing a broken +package onto unsuspecting users. Because they'll usually gonna complain +to me (the upstream) and not you (the package maintainer), anyway.