Re-open the library with `RTLD_GLOBAL`

[gudzpoz]

Currently Lua scripts won't be able to load external binary libraries on platforms with dlopen. This is probably because the library itself is open with the RTLD_LOCAL flag.

       dlopen(RTLD_LOCAL)
JVM -----------------------> liblua**.so
     symbols visible to JVM   /|\    | dlopen(...)
                               |     | symbols visible to us
                            (*)|    \|/
                               lfs.so

As is illustrated in the diagram, lfs.so is actually expecting to see symbols from the Lua library liblua**.so. However, JVM initially opened the library with RTLD_LOCAL, making the library symbols only visible to the JVM, so loading lfs.so will fail.

A workaround is just to re-open the library with the RTLD_GLOBAL flag.

This might bring another problem: it pollutes the global symbol space. Consider running Lua 5.1 and Lua JIT at the same time, there is just no way to distinguish between their symbols. (I have no idea if the current implementation works under this situation through.) But certainly you will not be able to load lfs.so from multiple versions of Lua.

• [x] Re-open the library with RTLD_GLOBAL
• [x] Add warnings if the user is trying to use multiple versions of Lua at the same time
• [x] Enable dynamic libraries in Lua 5.N
• [ ] Add tests (it can be a pain to add tests for all dlopen platforms)
  • [ ] Android
  • [ ] Linux
  • [ ] macOS

fixes #94

[gudzpoz]

Unfortunately, this breaks our current tests, since we do use multiple versions of Lua in our tests. I'm going to make this behavior optional.

[gudzpoz]

No, I don't think I will be ever able to test this. Considering I am going to test this against:

• 5 Lua versions
• At least 3 platforms And binary libraries to test for may differ between platforms and versions, which will require manual preparation (or at least tweaks in the build process). So, I am going to just document this a bit and "it works on my machine".