Implement VFS functions to load shared libraries from within LUAZIP archives #562
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rdw-software
force-pushed
the
488-vfs-dlopen-dlname
branch
from
9c3b6bc to
cc38255
Compare
|
Needs a design review. Not too happy with the API as well; holding off on completing this work. Maybe postpone to next release? Update: This seems OK, pending a future redesign of the VFS caching that can help eliminate the first argument. |
rdw-software
force-pushed
the
488-vfs-dlopen-dlname
branch
5 times, most recently
from
ca20ea8 to
5521113
Compare
rdw-software
force-pushed
the
488-vfs-dlopen-dlname
branch
from
5521113 to
dbb7970
Compare
rdw-software
force-pushed
the
488-vfs-dlopen-dlname
branch
5 times, most recently
from
c14036d to
48f8496
Compare
When using ffi.load this is seemingly handled by the underlying platform, but when attempting to load libraries from the VFS that isn't going to work. There's no way around resolving names manually, since the files have to be extracted to a temporary directory and then loaded from disk (using the fully-qualified file name). Providing a separate function for the lookup makes it easier to test and also allows users to check that resolution works as expected.
zlib is unlikely to ever be removed and quick to build, so there's no drawbacks to generating a shared library version as well. Although this variant won't be used by the runtime itself, it does come in handy for testing vfs.dlopen in a real-world scenario.
Relying on a shared library that's created by a build script removes some complexity from the test suite, at the cost of depending on this specific library always being built. While certainly not ideal, in the case of zlib it's probably safe to assume that this will always be the case.
This is just the first step towards a more flexible VFS interface. No tests because I don't want to lock in on the approach just yet.
There's a number of questionable things here that should likely be improved upon. Some may require redesigning the vfs and CLI library interfaces, so I'll save it for later.
Doesn't cover the main functionality; which is just too involved for a mere unit test.
This makes it possible to chain the function with ffi.load, so that the same code will work both during local development and when bundled as a self-contained LUAZIP application.
rdw-software
force-pushed
the
488-vfs-dlopen-dlname
branch
from
48f8496 to
c584d3a
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Things left to do:
.dllsuffix instead of.so?).soshould be fine, but what about.dylib?)I don't like the ergonomics of having to manually(separate issue)vfs.decodebeforevfs.dlopencan be usedResolves #488.