Menu

#2058 Default build on Linux has dynamic libraries disabled

Bug
closed-fixed
5
2019-01-11
2018-10-25
jj5
No

No Lua module which is in the dynamic library can be loaded by SciTE on Linux since >=4.0 (when it started using Lua 5.3).

The culprit is -DLUA_USE_POSIX in scite/gtk/makefile which should be changed to -DLUA_USE_LINUX for the builds on Linux.

(#2052 should be removed or closed as a clearly confusing and flawed example of this problem)

Related

Bugs: #2052

Discussion

  • jj5

    jj5 - 2018-10-25

    To illustrate the problem on Ubuntu 18.04 an unimportant but small and simple Lua module implemented in the dynamic library will be used:

    Installing the module:

    sudo apt -y install lua-system
    sudo mkdir -p /usr/local/lib/lua/5.3/system
    sudo ln -s /usr/lib/x86_64-linux-gnu/lua/5.3/system/core.so /usr/local/lib/lua/5.3/system/core.so
    

    Then editing Lua Startup Script to demonstrate the problem:

    local system = require 'system.core'
    print( "System.Gettime is", system.gettime() )
    

    Gives in the output window:

    error loading module 'system.core' from file '/usr/local/lib/lua/5.3/system/core.so':
        dynamic libraries not enabled; check your Lua installation
    >Lua: error occurred while running startup script
    

    Solution:

    Downloading scite sources, changing in scite/gtk/makefile from -DLUA_USE_POSIX to -DLUA_USE_LINUX and then executing the locally built SciTE gives in the output window:

    System.Gettime is   1540462135,1342
    
     

    Last edit: jj5 2018-10-25
    • jj5

      jj5 - 2018-10-25

      I've recognized thatthe #2052 is flawed and confusing because
      1) I've pasted the wrong line to make the link to the .so in the "first" or "main" post and I can't edit that post. I'm really sorry! The responses have the correct ln line but the damage was already done.
      2) The problem is more general than only some specific Lua module implemented with the dynamic library, like lfs, so this title and the description should reflect this. The specific example is now in the comments which can be edited.

       
    • jj5

      jj5 - 2018-10-25

      The alternative solution to -DLUA_USE_LINUX would be to define at least both -DLUA_USE_POSIX and -DLUA_USE_DLOPEN for all the builds which don't target Windows. Without either -DLUA_USE_DLOPEN or -DLUA_DL_DLL the loading of the dynamic libraries resolves to the message "dynamic libraries not enabled; check your Lua installation". At the moment all target systems of SciTE have either one (dlopen) or another (DLL).

       
      • jj5

        jj5 - 2018-10-25

        The scite/gtk/makefile already has to recognize the case of targeting dlopen-based or DLL-based system . The former includes all -ldl targets and Darwin targets (see checks for the UNAME) and exactly all these targets should be compiled with -DLUA_USE_DLOPEN. The Darwin target doesn't have to link with -ldl but it also needs to use the dlopen call, so in all -ldl cases and in Darwin case the -DLUA_USE_DLOPEN should be defined when compiling the Lua .c files to allow the Lua interpreter to load its modules which are implemented as the dynamic libraries.

         

        Last edit: jj5 2018-10-25
        • jj5

          jj5 - 2018-10-25

          Attached:

          Passing -DLUA_USE_DLOPEN to all dlopen-based (on the C level, that includes Darwin) targets when compiling the Lua sources from the makefile in the gtk folder.

          Diff -u to scite 4.1.2

           

          Last edit: jj5 2018-10-25
  • Neil Hodgson

    Neil Hodgson - 2018-11-20
    • labels: --> scite, lua
    • status: open --> open-fixed
    • assigned_to: Neil Hodgson
     
  • Neil Hodgson

    Neil Hodgson - 2018-11-20

    OK, committed as [2b22af].

    Currently credited to "jj5" so, if you would prefer a different name, reply with your preferred name.

     

    Related

    Commit: [2b22af]

    • jj5

      jj5 - 2018-11-22

      It's fine as it is, thanks a lot for creating SciTE, my programming work would be much harder without it, I consider it better than any alternative, in the sense how minimal it is and how much it still allows me to do. Having the Lua extensions functioning is part of that feature set, especially since starting of external programs from Lua by default is not satisfacory. That's why being able to use Lua File System (I can have the same routines on Linux and Windows) and other Lua extensions is important to me.

       
  • Andreas Rönnquist

    Thanks for the investigation and fix! On 4.1.0-1 and later I have (I am one of the Debian maintainers) packaged building using the Debian-packaged Lua, so there this shouldn't be a problem. This leaves 4.0.0 in Ubuntu 18.04, where I have suggested a patch and a stable update. See https://bugs.launchpad.net/ubuntu/+source/scite/+bug/1804865

     
  • Neil Hodgson

    Neil Hodgson - 2019-01-11
    • status: open-fixed --> closed-fixed
     

Log in to post a comment.