portable release: prefer distro supplied shared objects #83
Conversation
This file contains hidden or 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
Until now we always used our supplied 3rd party shared objects dependencies over the distro supplied ones. But ours are likely older which causes problems. E.g. issue 41: we load a thirdparty distro library compiled against a newer zlib but it's loading our supplied older version which fails. This patch changes the search order to use our supplied .so's only as fallback if the dist ones are not available. This is noticable e.g. running `pyston -c "import sqlite3; print(sqlite3.sqlite_version)"` will output 3.31.1 (on my ubuntu 20.04 system) instead of 3.11.0. Why do we even supply this libraries?: We do have to supply this libraries in case the user does not have the library installed or it's not available in the required major version. E.g. if you use the portable release on latest fedora and ubuntu openssl 1.0.x is not available anymore (it uses 1.1.x) so pip will not work if we don't supply 1.0. Which means in order to have only one release which works on as much distros as possible we need to supply this files but should make sure they are only used as fallback. I verified that this fixes the problems in #41 and #76 on ubuntu, fedora and archlinux. BTW: patchelf v0.10 supplied in ubuntu 20.04 contains a bug which corrupts files when modifying already previously via patchelf modified executables.
|
👍 |
This was referenced Sep 7, 2021
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.
Until now we always used our supplied 3rd party shared objects dependencies over
the distro supplied ones. But ours are likely older which causes problems.
E.g. issue #41: we load a thirdparty distro library compiled against a newer zlib but it's loading
our supplied older version which fails.
This patch changes the search order to use our supplied .so's only as fallback if the dist ones are not available.
This is noticable e.g. running
pyston -c "import sqlite3; print(sqlite3.sqlite_version)"will output 3.31.1 (on my ubuntu 20.04 system) instead of 3.11.0.
Why do we even supply this libraries?:
We do have to supply this libraries in case the user does not have the library installed
or it's not available in the required major version. E.g. if you use the portable release on latest fedora and ubuntu
openssl 1.0.x is not available anymore (it uses 1.1.x) so pip will fail with a SSL not available error if we don't supply 1.0.
Which means in order to have only one release which works on as much distros as possible we need to supply this
files but should make sure they are only used as fallback.
I verified that this fixes the problems in #41 and #76 on ubuntu, fedora and archlinux.
BTW: patchelf v0.10 supplied in ubuntu 20.04 contains a bug which corrupts files when modifying
already previously via patchelf modified executables. Not an issue for this script because it's not running patchelf twice on the same file but something to lookout if manually changing rpaths. Newer and older version seem to work fine.