PyOxidizer support

[jayvdb]

PyOxidizer breaks on distorm as

1. it doesnt provide __file__ See indygreg/PyOxidizer#69 for more info about why, but the tl;dr version is __file__ is an optional attribute and should not be relied upon.
2. it builds libs statically, so the external lib search is unnecessary. it is compiled in. It can be detected using sys.oxidized

[gdabah]

Hi @jayvdb So what are you suggesting the code should do, as it looks for the .so/.dll to load?

[jayvdb]

Hi @gdabah , the only approach that I know will work for the second problem I mentioned is having a cython or cffi shim that exposes the library functions that are needed.

However, it would still be useful if distorm solved the first problem I mentioned, the use of __file__, as there are ways to hack PyOxidizer so that it can access shared libraries outside of the static binary, which works around the second problem. At the moment, the __file__ problem means that distorm fails during import with a NameError, which is really difficult to workaround (I am working around it by injecting a fake __file__ value into the stub which loads distorm, but that hack is horrid).

Having an optional envvar for locating the libs might be a suitable fallback if __file__ is missing?

[gdabah]

I am willing to change it to whatever. What I don’t understand is what the fallback should be. Cause eventually I have to load the dynamic library.

On Mon, Nov 25, 2019 at 06:31 John Vandenberg notifications@github.com wrote:

Hi @gdabah https://github.com/gdabah , the only approach that I know will work for the second problem I mentioned is having a cython or cffi shim that exposes the library functions that are needed.

However, it would still be useful if distorm solved the first problem I mentioned, the use of file, as there are ways to hack PyOxidizer so that it can access shared libraries outside of the static binary, which works around the second problem. At the moment, the file problem means that distorm fails during import with a NameError, which is really difficult to workaround (I am working around it by injecting a fake file value into the stub which loads distorm, but that hack is horrid).

Having an optional envvar for locating the libs might be a suitable fallback if file is missing?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/gdabah/distorm/issues/142?email_source=notifications&email_token=AADMEWRQJCH4EBIGQVIMXQLQVNIJLA5CNFSM4JMQJMZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFBCM6Q#issuecomment-557983354, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADMEWV45GNXLWHWYL2D4GLQVNIJLANCNFSM4JMQJMZQ .

[jayvdb]

Could distorm load the dynamic libraries from a path specified in an environment variable? e.g. DISTORM_LIBS ?

The code would still use __file__ when it is present, so normal usage doesnt require the envvar. And the loading could fail with an ImportError if neither __file__ nor the envvar are available.

[gdabah]

Yep, but I rather use a generic envar.

On Mon, Nov 25, 2019 at 12:16 John Vandenberg notifications@github.com wrote:

Could distorm load the dynamic libraries from a path specified in an environment variable? e.g. DISTORM_LIBS ?

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/gdabah/distorm/issues/142?email_source=notifications&email_token=AADMEWWQXEO3656NBKKRDRDQVOQXPA5CNFSM4JMQJMZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFB3SCI#issuecomment-558086409, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADMEWR7KNZ2YRV5PVHKWV3QVOQXPANCNFSM4JMQJMZQ .

[gdabah]

@jayvdb Where are we standing on this? I want to make the change. if FILE isn't there, what's a good way to fetch the self-file-path?

[jayvdb]

ZipApps, PyOxidizer, Nuitka standalone, etc all have only one file residing on a filesystem: sys.executable. Everything else is either converted into object code, or is embedded inside sys.executable.

Loading extra libs from the same path as sys.executable would be a quite sensible approach.

[gdabah]

I will take a look at that. Thanks for the very quick response.

[gdabah]

@jayvdb I pushed something so if it detects oxidizer it won't set any path and just try to load the library without any prefixed directory. Can you please run it to test?

[gdabah]

@jayvdb Perhaps it's now fixed with latest setup.py.