ffi.C
This is the default C library namespace — note the uppercase 'C'. It binds to the default set of symbols or libraries on the target system. These are more or less the same as a C compiler would offer by default, without specifying extra link libraries.
On POSIX systems, this binds to symbols in the default or global namespace. This includes all exported symbols from the executable and any libraries loaded into the global namespace. This includes at least libc, libm, libdl (on Linux), libgcc (if compiled with GCC), as well as any exported symbols from the Lua/C API provided by LuaJIT itself.
On Windows systems, this binds to symbols exported from the *.exe, the lua51.dll (i.e. the Lua/C API provided by LuaJIT itself), the C runtime library LuaJIT was linked with (msvcrt*.dll), kernel32.dll, user32.dll and gdi32.dll.
This semantics is probably related to the fact that "Windows symbols are bound to a specific DLL name", while symbols in POSIX systems aren't.
I think the best practice is to always use ffi.load("love"). It's an already loaded dynamic library, and each dynamic library is loaded at most one time for one executable. Therefore ffi.load("love") does no actual loading.
Last edited by coffeecat on Fri Feb 16, 2018 3:11 am, edited 1 time in total.
modiX wrote: ↑Thu Feb 15, 2018 7:56 pm
EDIT: So here is my working function. I could not use isDirectory, because it was always returning false. I think this is an issue with PhysFS. I solved it by calling recursion in any case and trying to get directory items of files, too.
isDirectory may also be coded in such a way to insta-return false if the directory isn't one of the "sanctioned" ones, but i haven't checked the source, just guessing.
modiX wrote: ↑Thu Feb 15, 2018 7:56 pmDisclaimer: I know it can be improved, but this won't be used in a game anyways.
Leave that to me :p
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
coffeecat wrote: ↑Fri Feb 16, 2018 3:08 amI think the best practice is to always use ffi.load("love"). It's an already loaded dynamic library, and each dynamic library is loaded at most one time for one executable. Therefore ffi.load("love") does no actual loading.
Oops, sorry. It doesn't work because it can't find the liblove.so. This can be fixed by using ffi.load("path/to/liblove.so"), or add the path to liblove.so in LD_LIBRARY_PATH. Now I think a conditional as suggested by grump is the best way to do this.
The best thing would be that Löve can mount any directory without limitation.
Why do you need this feature? I am genuinely asking.
I can see that a set of mount points statically specified in love.conf() for development purposes may be helpful. These mount points should be writeable via love.filesystem for soundness of LOVE API design, and the current semantics needs to be revised somehow (otherwise all writes goes to the save directory).
coffeecat wrote: ↑Fri Feb 16, 2018 11:47 am
Oops, sorry. It doesn't work because it can't find the liblove.so. This can be fixed by using ffi.load("path/to/liblove.so"), or add the path of liblove.so to LD_LIBRARY_PATH. Now I think a conditional as suggested by grump is the best way to do this.
I would need to ffi.load('liblove.so.0'). There is no liblove.so.
The best thing would be that Löve can mount any directory without limitation.
Why do you need this feature? I am genuinely asking.
People are not only making games, they're making tools for their games too. Every toolset needs a way to import data, and drag & drop is not a viable substitute for a file selection dialog. I also want to save stuff anywhere on occasion, when I don't wanna make my users go find the magic hidden location where the data was saved on their system.
The current state of things requires a bunch of work to get a very basic thing working. It's a major pain in the ass for no good reason at all.
coffeecat wrote: ↑Fri Feb 16, 2018 3:08 amI think the best practice is to always use ffi.load("love"). It's an already loaded dynamic library, and each dynamic library is loaded at most one time for one executable. Therefore ffi.load("love") does no actual loading.
local l = ffi.os == 'Windows' and ffi.load('love') or ffi.C
Me and my stuff True Neutral Aspirant. Why, yes, i do indeed enjoy sarcastically correcting others when they make the most blatant of spelling mistakes. No bullying or trolling the innocent tho.
coffeecat wrote: ↑Fri Feb 16, 2018 12:04 pm
Just for your information, I have a liblove.so on my system. This is probably Linux distribution-dependent.
It probably is. Is there a liblove.so.0 on your system?
zorg wrote: ↑Fri Feb 16, 2018 12:05 pmIf this only happens because you tried to do ffi.load("love") then you missed the fact that on linux, you don't do that.
I was just objecting to coffeecat's proposal to always load love:
coffeecat wrote: ↑Fri Feb 16, 2018 3:08 amThis semantics is probably related to the fact that "Windows symbols are bound to a specific DLL name", while symbols in POSIX systems aren't.
I think the best practice is to always use ffi.load("love"). It's an already loaded dynamic library, and each dynamic library is loaded at most one time for one executable. Therefore ffi.load("love") does no actual loading.
My Löve binaries are statically linked anyway (because I compiled them that way), therefore there's no liblove.so to load.
The best thing to do may be to pcall ffi.C.PHYSFS_mount and try to load love only if that fails.
