Open cmarquardt opened 5 years ago
+1
@cmarquardt we can reproduce the same. Is there a fix coming for this?
To be honest, probably not. I never managed to find out in detail what is causing the problem and how to fix it.
In my case, binaries produced on one version of a Linux distribution/system run fine on that OS version but fail on some (not all) other versions or distributions. I remember that loading some shared library failed upon startup (OpenSSL, I believe due to a version mismatch). I guess that I would need to include these libs in the executable built by PyInstaller somehow. But my knowledge of and experience with PyInstaller is minimal. In practice, I ended up rebuilding the binaries on a machine running the target OS and then distributing the binaries to other boxes with the same version of Linux.
But if you know how to fix it, I'd be grateful - and a pull request would be even better;-)
Thank you for your answer! Unfortunately my python skills are down to a bare minimum. I need to run this on an old Ubuntu 14.04 and can not (because of dependencies) update the OS or even python.
Thats why I wanted to try your pre-compiled binary. Do you think it is safe using it then? I can dispense the use of --version
if the rest is still working.
Thanks in advance
I'm not familiar with PyInstaller, but this looks to be a similar issue (including a possible solution): https://github.com/pyinstaller/pyinstaller/issues/1713
One potential difference is that borgmatic --version
in particular relies on pkg_resources
to pull in borgmatic's package metadata:
if global_arguments.version:
print(pkg_resources.require('borgmatic')[0].version)
sys.exit(0)
So if that package metadata is not fetchable with PyInstaller, then that approach of course won't work.
Also relevant: https://stackoverflow.com/questions/458550/standard-way-to-embed-version-into-python-package
I'm open to other ways of determining the borgmatic version at runtime if it leads to better results with PyInstaller.