Error on opening file via FileDialog

[pirogronian]

When opening selected file via FileDialog, I got

Error: thirdparty/Slab/Internal/Core/FileSystem.lua:277: /usr/lib/libluajit-5.1.so.2: undefined symbol: stat64
stack traceback:
[string "boot.lua"]:777: in function <[string "boot.lua"]:773>
[C]: in function '__index'
thirdparty/Slab/Internal/Core/FileSystem.lua:277: in function 'IsDirectory'
thirdparty/Slab/Internal/UI/Dialog.lua:564: in function 'FileDialog'
main.lua:87: in function 'AddFilepathDialog'
main.lua:57: in function 'update'
[string "boot.lua"]:612: in function <[string "boot.lua"]:594>
[C]: in function 'xpcall'

I invoked FileDialog these way:

local result = Slab.FileDialog({ Type = "openfile" })

My system: ArchLinux, updated yesterday.

What's interesting (and confusing) yesterday it worked fine. The only difference was update Slab in my project from version of ~21.07.2020 but I cannot find in commit logs any substantial changes, that could do that.
Maybe using FFI on Linux is not so good idea?

Edit:
To work on with my project, I forked Slab and do a workaround using love api:
pirogronian@9ecb1c8

[coding-jackalope]

Hi @pirogronian, thanks for reporting this issue and providing a work around. I'll take a look and include this fix in a patch release.

[pirogronian]

By the way, as Slab is written for LOVE, why not to use LOVE API, instead of using standard Lua packages and even external libs? I think it would make things much simpler and make mobiles support much easier.

[flamendless]

Do you mean the usage of ffi? There are restrictions to some löve api where ffi could be used as it can provide for power and functionality.

[pirogronian]

Well, if love api is insufficient, then there is no choice than use something different. But I'd use it as really last choice. Even now I see my workaround as kind of dirty hack. Are you sure ffi is really needed there?

[coding-jackalope]

Hi @pirogronian, as @flamendless has mentioned, FFI is very helpful in providing features that Love restricts. For example, the love.filesystem documentation mentions that it will only give access to the root folder (source directory), the game's save directory, or the folder containing the game's .love archive or source directory. This is sufficient and recommended when shipping a game for end users as the game shouldn't need access to any other part of the filesystem.

However, Slab is meant to provide functionality to help build out tools or applications for people using Love that may need access to other parts of the filesystem that Love doesn't provide. There may be files needed during development of a game that won't be shipped to end users to allow for quicker or more streamlined development. Others may want to create a tool or application using Love that may want to allow the user to save/load files outside of Love. The file dialog is meant to mimic the standard Open/Save dialog found in operating systems with a GUI.

Linux is not my primary development platform so this slipped through the cracks unfortunately, as I mainly work on OSX. I am in the process of getting a Linux environment set up so that this won't happen again in the future. Hope this answers the question.

[pirogronian]

Hi @coding-jackalope , thank you for detailed explanation. As FFI appears to have some unexpected restrictions as well, I'd provide LOVE as another backend and let user to choose which one to use.

By the way, I'm able to access any file on my filesystem using love.filesystem.getInfo. Probably the only restriction love.filesystem have is write access limited to save directory.

Indeed, LOVE refuses to open any file by its absolute path. Only path relative to mentioned places is accepted. LOVE is great but this is really annoying.

[coding-jackalope]

Hi @pirogronian, what version of ArchLinux are you running? I have tried using the file dialog in both Ubuntu and Manjaro which is a ArchLinux based system, and both worked fine when browsing files. Are you just using a base Arch system or combining a desktop?

[pirogronian]

Hi @coding-jackalope .

Edit:
Now I see luajit 2.0.5-3 was updated 24-th july, so around the moment problem started. Most probably it contains a bug or something.
End edit.

ArchLinux is a rolling distro, so only install images are versioned. I have some custom packages, but all base and devel are standard and fresh. Exact versions:

glibc 2.31-5
gcc-libs 10.1.0-2

I could't find stat64 nor stat or lstat symbols among certain shared objects of these packages, though.

As I stated, at first everything worked fine, but just next day it stopped. I did system update meanwhile, but no devel package was updated, at least I couldnt find it.