#569 Support for Lua 5.2 (feature request)



Lua 5.2.1 is the default version of Lua on Arch Linux. Fceux only seems to support Lua 5.1. Would it be possible to support 5.2 as well?

Thanks. And thanks for developing fceux in the first place!

Best regards,
Alexander Rødseth


  • zeromus

    zeromus - 2013-01-07

    its ridiculous to support two different versions of lua. that isnt gonna happen.

    but we need to know what the problems really are: are you even able to get the old lua installed concurrently and safely with 5.2? are you having trouble getting lua working in fceux consequently, or is this just a wish list item?

  • A R

    A R - 2013-01-08


    The subject of the feature request is "Support for Lua 5.2 (feature request)". This is what I'm requesting. When I said "as well", I meant it in a loose sense, where either both "lua 5.1 and lua 5.2" or just "lua 5.2" support would be fine. Here there's room for interpretation. Feel free to select the interpretation that makes the request the least ridiculous to you (not that supporting more than one library version is ridiculous in general, even though it may be problematic for Lua 5.1/5.2). A more generous interpretation may have made the request seem less ridiculous.

    This is a feature request, and it's clearly marked as such. Call it a "wish list item" if you like.

    I'll try to answer your questions and implications as best as I can:

    Q: We need to know what the problems really are.
    A: There isn't a particular problem, fceux works fine with Lua 5.1. However, Lua 5.2 is the default on Arch Linux now, and most of the other packages have already transitioned to Lua 5.2. This was handled by a huge TODO-list a bit over a month ago, for all official packages that are using lua.

    Q: Are you even able to get the old lua installed concurrently and safely with 5.2?
    A: I'm not entirely sure what you're asking here. Both Lua 5.1 (the "lua51" package) and Lua 5.2 (the "lua" package) installs fine on Arch Linux. Everything seems in order.

    Q: Are you having trouble getting lua working in fceux concequently?
    A: No, fceux and Lua 5.1 works fine, for now.

    Q: Is this just a wish list item?
    A: Yes.

    Alexander Rødseth
    Maintainer of the Arch Linux fceux package

  • zeromus

    zeromus - 2013-01-11

    n.b. we are using unmodified lua 5.1.4 sources

  • A R

    A R - 2013-02-23

    In that case, I would like to change my feature request to a wish that fceux would use Lua 5.2 from the libraries that are already installed on the system.

  • Lukas Sabota

    Lukas Sabota - 2013-02-25
  • Lukas Sabota

    Lukas Sabota - 2013-02-25

    Thanks for your update. Currently, fceux-sdl (by default) uses the lua5.1 libraries on the system, and can use the lua5.1 library in the fceux source tree by flipping the SYSTEM_LUA bit in the SConstruct off. I will look into using lua 5.2 from the system for fceux-sdl and update this bug when I have more information to provide.

  • Lukas Sabota

    Lukas Sabota - 2013-02-26

    I've tried tweaking the build scripts to use lua5.2, but forwhatever reason I'm getting undefined references to lua functions:


    AFAIK the only linker flags clua needs are -lm -ldl and -llua

  • zeromus

    zeromus - 2013-03-02

    I'm thinking about whether we want to have different emulators (or the same emulator on different platforms, or the same emulator on the same platform built under different circumstances) using incompatible luas, and being incompatible with scripts.

    The whole concept of using a system-provided lua is crap. It's built to be embedded in apps. So we have to pick which version we're 'embedding' in fceux even if we happen to use the system provided version to make people stop complaining.

  • A R

    A R - 2013-03-04

    Other projects have no difficulty using system-provided libraries.

    Whether to use Lua 5.1 or 5.2 from the system or Lua 5.1 or 5.2 from a provided library can be determined at compile-time by using ./configure, cmake, qmake or another build-system.

    Two of the advantages of shared libraries are memory savings and the possibility of performing minor security-related upgrades without having to recompile every application that depends on the shared library. It's also the norm for Linux applications.

  • Ryan W. Moore

    Ryan W. Moore - 2014-08-04

    Attached (via a patch) are the changes I made in order to get Lua 5.2 to work. Changes were relatively minor:

    1. I had to enable some Lua-specific backward-compatibility defines
    2. I had to implement 2 functions due to Lua changes (see src/lua-compatibility.cpp)
    3. SConscript support/detection for lua 5.2.
    4. Some code unrelated to Lua just didn't compile for me. So I had to make some hacks (i.e., #define KEYBOARDTRANSFORMER_SPECIFIC, commenting out a line about fps_scale, changing the root SConscript to do "-Isrc").

    It now builds fine for me (Ubuntu 14.04 with Lua 5.2). I tested out some Lua scripts and they seem to work fine (e.g., the SMB snow script, the SMB jetpack script).

  • Lukas Sabota

    Lukas Sabota - 2014-08-07

    Thank you for taking the time to look into this and submit this patch, Ryan. I will look into this patch and the possibility of adding an optional build-time option to compile using the system's lua5.2 library. I do have a concern of whether using lua5.2 will have incompatibilities with existing lua5.1 (fceux's target lua version) scripts, but the build-time option can remain optional. I will update this bug once I have looked into this further, but I wanted to assure you that your patch did not fall upon deaf ears and I will look into this further when I get an opportunity


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks