ARROW-5868: [Python] Correctly remove liblz4 shared libraries from manylinux2010 image so lz4 is statically linked - #4828

Closed
wesm wants to merge 1 commit into
apache:masterfrom
wesm:ARROW-5868
Closed

ARROW-5868: [Python] Correctly remove liblz4 shared libraries from manylinux2010 image so lz4 is statically linked#4828
wesm wants to merge 1 commit into
apache:masterfrom
wesm:ARROW-5868

Conversation

@wesm

@wesmwesm commented Jul 9, 2019

Copy link
Copy Markdown
Member

I pushed the image to Docker Hub (it was on quay.io before). I'm not sure what's the best way to test for this -- I checked the produced wheels locally to verify that liblz4.so is no longer required

@codecov-io

codecov-io commented Jul 9, 2019

Copy link
Copy Markdown

Codecov Report

Merging #4828 into master will decrease coverage by 22.25%.
The diff coverage is n/a.

Impacted file tree graph

@@ Coverage Diff @@## master #4828 +/- ##
===========================================
- Coverage 87.43% 65.18% -22.26% 
===========================================
Files 997 487 -510 Lines 139804 64296 -75508 Branches 1418 0 -1418 ===========================================
- Hits 122241 41910 -80331 - Misses 17201 22386 +5185 + Partials 362 0 -362
Impacted FilesCoverage Δ
cpp/src/arrow/util/memory.h0% <0%> (-100%)⬇️
cpp/src/gandiva/date_utils.h0% <0%> (-100%)⬇️
cpp/src/arrow/util/memory.cc0% <0%> (-100%)⬇️
cpp/src/arrow/filesystem/util-internal.cc0% <0%> (-100%)⬇️
cpp/src/arrow/util/sse-util.h0% <0%> (-100%)⬇️
cpp/src/gandiva/decimal_type_util.h0% <0%> (-100%)⬇️
cpp/src/arrow/compute/logical_type.h0% <0%> (-100%)⬇️
cpp/src/parquet/hasher.h0% <0%> (-100%)⬇️
cpp/src/gandiva/basic_decimal_scalar.h0% <0%> (-100%)⬇️
cpp/src/arrow/compute/kernels/boolean.cc0% <0%> (-100%)⬇️
... and 748 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 90affbd...1fb1acb. Read the comment docs.

@pitrou

pitrou commented Jul 9, 2019

Copy link
Copy Markdown
Member

Hmm... auditwheel didn't complain? Perhaps worth reporting as a bug?

@kszucs

kszucs commented Jul 9, 2019

Copy link
Copy Markdown
Member

We can add more docker images to test the produced wheels. Have you reproduced the issue?

@kszucs

kszucs commented Jul 9, 2019

Copy link
Copy Markdown
Member

I cannot really find a linux distribution without lz4 preinstalled.

@kszucs

kszucs commented Jul 9, 2019•
edited
Loading

Copy link
Copy Markdown
Member

So we statically link liblz4 in the manylinux1 wheels

# ldd pyarrow-manylinux1/libarrow.so.14 | grep z
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc28cef4000)

but dynamically in the manylinux2010 wheels

# ldd pyarrow-manylinux2010/libarrow.so.14 | grep z
liblz4.so.1 => not found (already deleted to reproduce the issue)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f56f7440000)

this what this PR resolves.

What I'm finding strange, that auditwheel seems to bundle libz for manylinux1:

# ls -lah pyarrow-manylinux1/*z*so.*
-rwxr-xr-x 1 root root 115K Jun 29 00:14 pyarrow-manylinux1/libz-7f57503f.so.1.2.11

while ldd still uses the system libz:

# ldd pyarrow-manylinux1/libarrow.so.14 | grep z
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f91fcf3f000)

For manylinux2010 we also have liblz4:

# ls -lah pyarrow-manylinux2010/*z*so.*
-rwxr-xr-x 1 root root 191K Jun 28 23:38 pyarrow-manylinux2010/liblz4-8cb8bdde.so.1.8.3
-rwxr-xr-x 1 root root 115K Jun 28 23:38 pyarrow-manylinux2010/libz-c69b9943.so.1.2.11

and ldd similarly tries to load the system libs:

# ldd pyarrow-manylinux2010/libarrow.so.14 | grep z
liblz4.so.1 => not found
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd72764e000)

Inspecting manylinux1 with LD_DEBUG=files,libs ldd libarrow.so.14 it seems like to search the right path, but cannot find the hashed version of libz libz-7f57503f.so.1.2.11

 463: file=libz.so.1 [0]; needed by ./libarrow.so.14 [0]
463: find library=libz.so.1 [0]; searching
463: search path=/tmp/pyarrow-manylinux1/. (RPATH from file ./libarrow.so.14)
463: trying file=/tmp/pyarrow-manylinux1/./libz.so.1
463: search cache=/etc/ld.so.cache
463: trying file=/lib/x86_64-linux-gnu/libz.so.1

There is no libz.so.1 just libz-7f57503f.so.1.2.11.

Similarly for manylinux2010 and libz:

 470: file=libz.so.1 [0]; needed by ./libarrow.so.14 [0]
470: find library=libz.so.1 [0]; searching
470: search path=/tmp/pyarrow-manylinux2010/. (RPATH from file ./libarrow.so.14)
470: trying file=/tmp/pyarrow-manylinux2010/./libz.so.1
470: search cache=/etc/ld.so.cache
470: trying file=/lib/x86_64-linux-gnu/libz.so.1

for liblz4 (again, I've deleted the system one):

 470: file=liblz4.so.1 [0]; needed by ./libarrow.so.14 [0]
470: find library=liblz4.so.1 [0]; searching
470: search path=/tmp/pyarrow-manylinux2010/. (RPATH from file ./libarrow.so.14)
470: trying file=/tmp/pyarrow-manylinux2010/./liblz4.so.1
470: search cache=/etc/ld.so.cache
470: search path=/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/x86_6$
:/usr/lib/x86_64-linux-gnu:/lib/tls/x86_64:/lib/tls:/lib/x86_64:/lib:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/x86_64:/usr/lib (system search path)

There are no libz.so.1 nor liblz4.so.1, just libz-c69b9943.so.1.2.11 and liblz4-8cb8bdde.so.1.8.3

According to https://www.python.org/dev/peps/pep-0571/liblz4 nor libz are part of the whitelist, and while these are bundled with the wheel, seemingly cannot be found - perhaps because of the hash in the library name?

I've tried to inspect the wheels with auditwheel show with version 2 and 1.10, both says the following:

# auditwheel show pyarrow-0.14.0-cp37-cp37m-manylinux2010_x86_64.whl
pyarrow-0.14.0-cp37-cp37m-manylinux2010_x86_64.whl is consistent with
the following platform tag: "linux_x86_64".
The wheel references external versioned symbols in these system-
provided shared libraries: libgcc_s.so.1 with versions {'GCC_3.3',
'GCC_3.4', 'GCC_3.0'}, libpthread.so.0 with versions {'GLIBC_2.3.3',
'GLIBC_2.12', 'GLIBC_2.2.5', 'GLIBC_2.3.2'}, libc.so.6 with versions
{'GLIBC_2.4', 'GLIBC_2.6', 'GLIBC_2.2.5', 'GLIBC_2.7', 'GLIBC_2.3.4',
'GLIBC_2.3.2', 'GLIBC_2.3'}, libstdc++.so.6 with versions
{'CXXABI_1.3', 'GLIBCXX_3.4.10', 'GLIBCXX_3.4.9', 'GLIBCXX_3.4.11',
'GLIBCXX_3.4.5', 'GLIBCXX_3.4', 'CXXABI_1.3.2', 'CXXABI_1.3.3'},
librt.so.1 with versions {'GLIBC_2.2.5'}, libm.so.6 with versions
{'GLIBC_2.2.5'}, libdl.so.2 with versions {'GLIBC_2.2.5'}, libz.so.1
with versions {'ZLIB_1.2.0'}
This constrains the platform tag to "manylinux2010_x86_64". In order
to achieve a more compatible tag, you would need to recompile a new
wheel from source on a system with earlier versions of these
libraries, such as a recent manylinux image.

# auditwheel show pyarrow-0.14.0-cp37-cp37m-manylinux1_x86_64.whl
pyarrow-0.14.0-cp37-cp37m-manylinux1_x86_64.whl is consistent with the
following platform tag: "linux_x86_64".
The wheel references external versioned symbols in these system-
provided shared libraries: libgcc_s.so.1 with versions {'GCC_3.4',
'GCC_3.0', 'GCC_3.3'}, libc.so.6 with versions {'GLIBC_2.3',
'GLIBC_2.2.5', 'GLIBC_2.3.4', 'GLIBC_2.4', 'GLIBC_2.3.2'},
libstdc++.so.6 with versions {'CXXABI_1.3', 'GLIBCXX_3.4.5',
'GLIBCXX_3.4'}, librt.so.1 with versions {'GLIBC_2.2.5'}, libm.so.6
with versions {'GLIBC_2.2.5'}, libpthread.so.0 with versions
{'GLIBC_2.3.3', 'GLIBC_2.3.2', 'GLIBC_2.2.5'}, libdl.so.2 with
versions {'GLIBC_2.2.5'}, libz.so.1 with versions {'ZLIB_1.2.0'}
The following external shared libraries are required by the wheel:
{
"libc.so.6": "/lib/x86_64-linux-gnu/libc-2.24.so",
"libcrypt.so.1": "/lib/x86_64-linux-gnu/libcrypt-2.24.so",
"libdl.so.2": "/lib/x86_64-linux-gnu/libdl-2.24.so",
"libgcc_s.so.1": "/lib/x86_64-linux-gnu/libgcc_s.so.1",
"libm.so.6": "/lib/x86_64-linux-gnu/libm-2.24.so",
"libnsl.so.1": "/lib/x86_64-linux-gnu/libnsl-2.24.so",
"libpthread.so.0": "/lib/x86_64-linux-gnu/libpthread-2.24.so",
"librt.so.1": "/lib/x86_64-linux-gnu/librt-2.24.so",
"libstdc++.so.6": "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22",
"libutil.so.1": "/lib/x86_64-linux-gnu/libutil-2.24.so",
"libz.so.1": "/lib/x86_64-linux-gnu/libz.so.1.2.8"
}
In order to achieve the tag platform tag "manylinux2010_x86_64" the
following shared library dependencies will need to be eliminated:
libz.so.1
In order to achieve the tag platform tag "manylinux1_x86_64" the
following shared library dependencies will need to be eliminated:
libz.so.1

I think there are more todo left with the wheels. IMO the manylinux1 wheels are not compliant because of libz and the manylinux2010 wheels are not compliant because of both libz and liblz4 (but incorrectly reported by auditwheel?).

@kszucs

kszucs commented Jul 9, 2019•
edited
Loading

Copy link
Copy Markdown
Member

Perhaps we should use setup.py::move_shared_libs for libz on linux too? cc @xhochy

@wesm

wesm commented Jul 9, 2019

Copy link
Copy Markdown
MemberAuthor

Can you open a new JIRA about the libz issue with the information from this issue and we can investigate separately? I'm going to merge this for now.

+1

@wesm

wesm commented Jul 9, 2019

Copy link
Copy Markdown
MemberAuthor

Do we know why auditwheel did not raise either the liblz4 or libz issue before?

@kszucs

kszucs commented Jul 9, 2019

Copy link
Copy Markdown
Member

Sure, opening it.

@wesmwesm closed this in 7838886Jul 9, 2019
@kszucs

kszucs commented Jul 9, 2019

Copy link
Copy Markdown
Member

No idea, we only run auditwheel repair though.

@wesm

wesm commented Jul 9, 2019

Copy link
Copy Markdown
MemberAuthor

I see. We should do something about that then

@wesm
wesm deleted the ARROW-5868 branch July 9, 2019 14:23
@kszucs

kszucs commented Jul 9, 2019

Copy link
Copy Markdown
Member

In case of manylinux2010 the report seems faulty, but adding it to the issue.

@xhochy

xhochy commented Jul 9, 2019

Copy link
Copy Markdown
Member

auditwheel repair should package libz.so into the wheel. Only after the repair it should be consistent.

wesm added a commit that referenced this pull request Jul 13, 2019
@wesm
ARROW-5868: [Python] Correctly remove liblz4 shared libraries from ma…
f356184
…nylinux2010 image so lz4 is statically linked
I pushed the image to Docker Hub (it was on quay.io before). I'm not sure what's the best way to test for this -- I checked the produced wheels locally to verify that liblz4.so is no longer required
Author: Wes McKinney <wesm+git@apache.org>
Closes#4828 from wesm/ARROW-5868 and squashes the following commits:
1fb1acb <Wes McKinney> Remove liblz4 shared libraries from /usr/local so static linking occurs
@asfimportasfimport mentioned this pull request Aug 1, 2019
Closed
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

5 participants

@wesm@codecov-io@pitrou@kszucs@xhochy
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
ARROW-5868: [Python] Correctly remove liblz4 shared libraries from manylinux2010 image so lz4 is statically linked - #4828
Closed
wesm wants to merge 1 commit into
apache:masterfrom 
wesm:ARROW-5868
Closed
ARROW-5868: [Python] Correctly remove liblz4 shared libraries from manylinux2010 image so lz4 is statically linked#4828
wesm wants to merge 1 commit into
apache:masterfrom 
wesm:ARROW-5868
Conversation
@wesm
@wesmwesm
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
I pushed the image to Docker Hub (it was on quay.io before). I'm not sure what's the best way to test for this -- I checked the produced wheels locally to verify that liblz4.so is no longer required
@codecov-io
codecov-io
commented
Jul 9, 2019

Copy link


Copy Markdown

Codecov Report
Merging #4828 into master will decrease coverage by 22.25%.

The diff coverage is n/a.
Impacted file tree graph
@@ Coverage Diff @@## master #4828 +/- ##
===========================================
- Coverage 87.43% 65.18% -22.26% 
===========================================
Files 997 487 -510 Lines 139804 64296 -75508 Branches 1418 0 -1418 ===========================================
- Hits 122241 41910 -80331 - Misses 17201 22386 +5185 + Partials 362 0 -362
Impacted FilesCoverage Δ
cpp/src/arrow/util/memory.h0% <0%> (-100%)⬇️
cpp/src/gandiva/date_utils.h0% <0%> (-100%)⬇️
cpp/src/arrow/util/memory.cc0% <0%> (-100%)⬇️
cpp/src/arrow/filesystem/util-internal.cc0% <0%> (-100%)⬇️
cpp/src/arrow/util/sse-util.h0% <0%> (-100%)⬇️
cpp/src/gandiva/decimal_type_util.h0% <0%> (-100%)⬇️
cpp/src/arrow/compute/logical_type.h0% <0%> (-100%)⬇️
cpp/src/parquet/hasher.h0% <0%> (-100%)⬇️
cpp/src/gandiva/basic_decimal_scalar.h0% <0%> (-100%)⬇️
cpp/src/arrow/compute/kernels/boolean.cc0% <0%> (-100%)⬇️
... and 748 more
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data

Powered by Codecov. Last update 90affbd...1fb1acb. Read the comment docs.
@pitrou
pitrou
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
Hmm... auditwheel didn't complain? Perhaps worth reporting as a bug?
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
We can add more docker images to test the produced wheels. Have you reproduced the issue?
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
I cannot really find a linux distribution without lz4 preinstalled.
@kszucs
kszucs
commented
Jul 9, 2019•

edited

Loading

Copy link


Copy Markdown

Member
So we statically link liblz4 in the manylinux1 wheels
# ldd pyarrow-manylinux1/libarrow.so.14 | grep z
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc28cef4000)

but dynamically in the manylinux2010 wheels
# ldd pyarrow-manylinux2010/libarrow.so.14 | grep z
liblz4.so.1 => not found (already deleted to reproduce the issue)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f56f7440000)

this what this PR resolves.
What I'm finding strange, that auditwheel seems to bundle libz for manylinux1:
# ls -lah pyarrow-manylinux1/*z*so.*
-rwxr-xr-x 1 root root 115K Jun 29 00:14 pyarrow-manylinux1/libz-7f57503f.so.1.2.11

while ldd still uses the system libz:
# ldd pyarrow-manylinux1/libarrow.so.14 | grep z
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f91fcf3f000)

For manylinux2010 we also have liblz4:
# ls -lah pyarrow-manylinux2010/*z*so.*
-rwxr-xr-x 1 root root 191K Jun 28 23:38 pyarrow-manylinux2010/liblz4-8cb8bdde.so.1.8.3
-rwxr-xr-x 1 root root 115K Jun 28 23:38 pyarrow-manylinux2010/libz-c69b9943.so.1.2.11

and ldd similarly tries to load the system libs:
# ldd pyarrow-manylinux2010/libarrow.so.14 | grep z
liblz4.so.1 => not found
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd72764e000)

Inspecting manylinux1 with LD_DEBUG=files,libs ldd libarrow.so.14 it seems like to search the right path, but cannot find the hashed version of libz libz-7f57503f.so.1.2.11
 463: file=libz.so.1 [0]; needed by ./libarrow.so.14 [0]
463: find library=libz.so.1 [0]; searching
463: search path=/tmp/pyarrow-manylinux1/. (RPATH from file ./libarrow.so.14)
463: trying file=/tmp/pyarrow-manylinux1/./libz.so.1
463: search cache=/etc/ld.so.cache
463: trying file=/lib/x86_64-linux-gnu/libz.so.1

There is no libz.so.1 just libz-7f57503f.so.1.2.11.
Similarly for manylinux2010 and libz:
 470: file=libz.so.1 [0]; needed by ./libarrow.so.14 [0]
470: find library=libz.so.1 [0]; searching
470: search path=/tmp/pyarrow-manylinux2010/. (RPATH from file ./libarrow.so.14)
470: trying file=/tmp/pyarrow-manylinux2010/./libz.so.1
470: search cache=/etc/ld.so.cache
470: trying file=/lib/x86_64-linux-gnu/libz.so.1

for liblz4 (again, I've deleted the system one):
 470: file=liblz4.so.1 [0]; needed by ./libarrow.so.14 [0]
470: find library=liblz4.so.1 [0]; searching
470: search path=/tmp/pyarrow-manylinux2010/. (RPATH from file ./libarrow.so.14)
470: trying file=/tmp/pyarrow-manylinux2010/./liblz4.so.1
470: search cache=/etc/ld.so.cache
470: search path=/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/x86_6$
:/usr/lib/x86_64-linux-gnu:/lib/tls/x86_64:/lib/tls:/lib/x86_64:/lib:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/x86_64:/usr/lib (system search path)

There are no libz.so.1 nor liblz4.so.1, just libz-c69b9943.so.1.2.11 and liblz4-8cb8bdde.so.1.8.3
According to https://www.python.org/dev/peps/pep-0571/liblz4 nor libz are part of the whitelist, and while these are bundled with the wheel, seemingly cannot be found - perhaps because of the hash in the library name?
I've tried to inspect the wheels with auditwheel show with version 2 and 1.10, both says the following:
# auditwheel show pyarrow-0.14.0-cp37-cp37m-manylinux2010_x86_64.whl
pyarrow-0.14.0-cp37-cp37m-manylinux2010_x86_64.whl is consistent with
the following platform tag: "linux_x86_64".
The wheel references external versioned symbols in these system-
provided shared libraries: libgcc_s.so.1 with versions {'GCC_3.3',
'GCC_3.4', 'GCC_3.0'}, libpthread.so.0 with versions {'GLIBC_2.3.3',
'GLIBC_2.12', 'GLIBC_2.2.5', 'GLIBC_2.3.2'}, libc.so.6 with versions
{'GLIBC_2.4', 'GLIBC_2.6', 'GLIBC_2.2.5', 'GLIBC_2.7', 'GLIBC_2.3.4',
'GLIBC_2.3.2', 'GLIBC_2.3'}, libstdc++.so.6 with versions
{'CXXABI_1.3', 'GLIBCXX_3.4.10', 'GLIBCXX_3.4.9', 'GLIBCXX_3.4.11',
'GLIBCXX_3.4.5', 'GLIBCXX_3.4', 'CXXABI_1.3.2', 'CXXABI_1.3.3'},
librt.so.1 with versions {'GLIBC_2.2.5'}, libm.so.6 with versions
{'GLIBC_2.2.5'}, libdl.so.2 with versions {'GLIBC_2.2.5'}, libz.so.1
with versions {'ZLIB_1.2.0'}
This constrains the platform tag to "manylinux2010_x86_64". In order
to achieve a more compatible tag, you would need to recompile a new
wheel from source on a system with earlier versions of these
libraries, such as a recent manylinux image.

# auditwheel show pyarrow-0.14.0-cp37-cp37m-manylinux1_x86_64.whl
pyarrow-0.14.0-cp37-cp37m-manylinux1_x86_64.whl is consistent with the
following platform tag: "linux_x86_64".
The wheel references external versioned symbols in these system-
provided shared libraries: libgcc_s.so.1 with versions {'GCC_3.4',
'GCC_3.0', 'GCC_3.3'}, libc.so.6 with versions {'GLIBC_2.3',
'GLIBC_2.2.5', 'GLIBC_2.3.4', 'GLIBC_2.4', 'GLIBC_2.3.2'},
libstdc++.so.6 with versions {'CXXABI_1.3', 'GLIBCXX_3.4.5',
'GLIBCXX_3.4'}, librt.so.1 with versions {'GLIBC_2.2.5'}, libm.so.6
with versions {'GLIBC_2.2.5'}, libpthread.so.0 with versions
{'GLIBC_2.3.3', 'GLIBC_2.3.2', 'GLIBC_2.2.5'}, libdl.so.2 with
versions {'GLIBC_2.2.5'}, libz.so.1 with versions {'ZLIB_1.2.0'}
The following external shared libraries are required by the wheel:
{
"libc.so.6": "/lib/x86_64-linux-gnu/libc-2.24.so",
"libcrypt.so.1": "/lib/x86_64-linux-gnu/libcrypt-2.24.so",
"libdl.so.2": "/lib/x86_64-linux-gnu/libdl-2.24.so",
"libgcc_s.so.1": "/lib/x86_64-linux-gnu/libgcc_s.so.1",
"libm.so.6": "/lib/x86_64-linux-gnu/libm-2.24.so",
"libnsl.so.1": "/lib/x86_64-linux-gnu/libnsl-2.24.so",
"libpthread.so.0": "/lib/x86_64-linux-gnu/libpthread-2.24.so",
"librt.so.1": "/lib/x86_64-linux-gnu/librt-2.24.so",
"libstdc++.so.6": "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22",
"libutil.so.1": "/lib/x86_64-linux-gnu/libutil-2.24.so",
"libz.so.1": "/lib/x86_64-linux-gnu/libz.so.1.2.8"
}
In order to achieve the tag platform tag "manylinux2010_x86_64" the
following shared library dependencies will need to be eliminated:
libz.so.1
In order to achieve the tag platform tag "manylinux1_x86_64" the
following shared library dependencies will need to be eliminated:
libz.so.1

I think there are more todo left with the wheels. IMO the manylinux1 wheels are not compliant because of libz and the manylinux2010 wheels are not compliant because of both libz and liblz4 (but incorrectly reported by auditwheel?).
@kszucs
kszucs
commented
Jul 9, 2019•

edited

Loading

Copy link


Copy Markdown

Member
Perhaps we should use setup.py::move_shared_libs for libz on linux too? cc @xhochy
@wesm
wesm
commented
Jul 9, 2019

Copy link


Copy Markdown

MemberAuthor
Can you open a new JIRA about the libz issue with the information from this issue and we can investigate separately? I'm going to merge this for now.
+1
@wesm
wesm
commented
Jul 9, 2019

Copy link


Copy Markdown

MemberAuthor
Do we know why auditwheel did not raise either the liblz4 or libz issue before?
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
Sure, opening it.
@wesmwesm
closed this
in
7838886Jul 9, 2019
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
No idea, we only run auditwheel repair though.
@wesm
wesm
commented
Jul 9, 2019

Copy link


Copy Markdown

MemberAuthor
I see. We should do something about that then
@wesm
wesm
deleted the

ARROW-5868

branch
July 9, 2019 14:23
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
In case of manylinux2010 the report seems faulty, but adding it to the issue.
@xhochy
xhochy
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
auditwheel repair should package libz.so into the wheel. Only after the repair it should be consistent.
wesm added a commit
that referenced
this pull request
Jul 13, 2019
@wesm
ARROW-5868: [Python] Correctly remove liblz4 shared libraries from ma…
f356184
…nylinux2010 image so lz4 is statically linked
I pushed the image to Docker Hub (it was on quay.io before). I'm not sure what's the best way to test for this -- I checked the produced wheels locally to verify that liblz4.so is no longer required
Author: Wes McKinney <wesm+git@apache.org>
Closes#4828 from wesm/ARROW-5868 and squashes the following commits:
1fb1acb <Wes McKinney> Remove liblz4 shared libraries from /usr/local so static linking occurs
@asfimportasfimport
mentioned this pull request
Aug 1, 2019

Closed

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@wesm@codecov-io@pitrou@kszucs@xhochy

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
ARROW-5868: [Python] Correctly remove liblz4 shared libraries from manylinux2010 image so lz4 is statically linked - #4828
Closed
wesm wants to merge 1 commit into
apache:masterfrom 
wesm:ARROW-5868
Closed
ARROW-5868: [Python] Correctly remove liblz4 shared libraries from manylinux2010 image so lz4 is statically linked#4828
wesm wants to merge 1 commit into
apache:masterfrom 
wesm:ARROW-5868
Conversation
@wesm
@wesmwesm
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
I pushed the image to Docker Hub (it was on quay.io before). I'm not sure what's the best way to test for this -- I checked the produced wheels locally to verify that liblz4.so is no longer required
@codecov-io
codecov-io
commented
Jul 9, 2019

Copy link


Copy Markdown

Codecov Report
Merging #4828 into master will decrease coverage by 22.25%.

The diff coverage is n/a.
Impacted file tree graph
@@ Coverage Diff @@## master #4828 +/- ##
===========================================
- Coverage 87.43% 65.18% -22.26% 
===========================================
Files 997 487 -510 Lines 139804 64296 -75508 Branches 1418 0 -1418 ===========================================
- Hits 122241 41910 -80331 - Misses 17201 22386 +5185 + Partials 362 0 -362
Impacted FilesCoverage Δ
cpp/src/arrow/util/memory.h0% <0%> (-100%)⬇️
cpp/src/gandiva/date_utils.h0% <0%> (-100%)⬇️
cpp/src/arrow/util/memory.cc0% <0%> (-100%)⬇️
cpp/src/arrow/filesystem/util-internal.cc0% <0%> (-100%)⬇️
cpp/src/arrow/util/sse-util.h0% <0%> (-100%)⬇️
cpp/src/gandiva/decimal_type_util.h0% <0%> (-100%)⬇️
cpp/src/arrow/compute/logical_type.h0% <0%> (-100%)⬇️
cpp/src/parquet/hasher.h0% <0%> (-100%)⬇️
cpp/src/gandiva/basic_decimal_scalar.h0% <0%> (-100%)⬇️
cpp/src/arrow/compute/kernels/boolean.cc0% <0%> (-100%)⬇️
... and 748 more
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data

Powered by Codecov. Last update 90affbd...1fb1acb. Read the comment docs.
@pitrou
pitrou
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
Hmm... auditwheel didn't complain? Perhaps worth reporting as a bug?
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
We can add more docker images to test the produced wheels. Have you reproduced the issue?
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
I cannot really find a linux distribution without lz4 preinstalled.
@kszucs
kszucs
commented
Jul 9, 2019•

edited

Loading

Copy link


Copy Markdown

Member
So we statically link liblz4 in the manylinux1 wheels
# ldd pyarrow-manylinux1/libarrow.so.14 | grep z
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc28cef4000)

but dynamically in the manylinux2010 wheels
# ldd pyarrow-manylinux2010/libarrow.so.14 | grep z
liblz4.so.1 => not found (already deleted to reproduce the issue)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f56f7440000)

this what this PR resolves.
What I'm finding strange, that auditwheel seems to bundle libz for manylinux1:
# ls -lah pyarrow-manylinux1/*z*so.*
-rwxr-xr-x 1 root root 115K Jun 29 00:14 pyarrow-manylinux1/libz-7f57503f.so.1.2.11

while ldd still uses the system libz:
# ldd pyarrow-manylinux1/libarrow.so.14 | grep z
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f91fcf3f000)

For manylinux2010 we also have liblz4:
# ls -lah pyarrow-manylinux2010/*z*so.*
-rwxr-xr-x 1 root root 191K Jun 28 23:38 pyarrow-manylinux2010/liblz4-8cb8bdde.so.1.8.3
-rwxr-xr-x 1 root root 115K Jun 28 23:38 pyarrow-manylinux2010/libz-c69b9943.so.1.2.11

and ldd similarly tries to load the system libs:
# ldd pyarrow-manylinux2010/libarrow.so.14 | grep z
liblz4.so.1 => not found
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd72764e000)

Inspecting manylinux1 with LD_DEBUG=files,libs ldd libarrow.so.14 it seems like to search the right path, but cannot find the hashed version of libz libz-7f57503f.so.1.2.11
 463: file=libz.so.1 [0]; needed by ./libarrow.so.14 [0]
463: find library=libz.so.1 [0]; searching
463: search path=/tmp/pyarrow-manylinux1/. (RPATH from file ./libarrow.so.14)
463: trying file=/tmp/pyarrow-manylinux1/./libz.so.1
463: search cache=/etc/ld.so.cache
463: trying file=/lib/x86_64-linux-gnu/libz.so.1

There is no libz.so.1 just libz-7f57503f.so.1.2.11.
Similarly for manylinux2010 and libz:
 470: file=libz.so.1 [0]; needed by ./libarrow.so.14 [0]
470: find library=libz.so.1 [0]; searching
470: search path=/tmp/pyarrow-manylinux2010/. (RPATH from file ./libarrow.so.14)
470: trying file=/tmp/pyarrow-manylinux2010/./libz.so.1
470: search cache=/etc/ld.so.cache
470: trying file=/lib/x86_64-linux-gnu/libz.so.1

for liblz4 (again, I've deleted the system one):
 470: file=liblz4.so.1 [0]; needed by ./libarrow.so.14 [0]
470: find library=liblz4.so.1 [0]; searching
470: search path=/tmp/pyarrow-manylinux2010/. (RPATH from file ./libarrow.so.14)
470: trying file=/tmp/pyarrow-manylinux2010/./liblz4.so.1
470: search cache=/etc/ld.so.cache
470: search path=/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/x86_6$
:/usr/lib/x86_64-linux-gnu:/lib/tls/x86_64:/lib/tls:/lib/x86_64:/lib:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/x86_64:/usr/lib (system search path)

There are no libz.so.1 nor liblz4.so.1, just libz-c69b9943.so.1.2.11 and liblz4-8cb8bdde.so.1.8.3
According to https://www.python.org/dev/peps/pep-0571/liblz4 nor libz are part of the whitelist, and while these are bundled with the wheel, seemingly cannot be found - perhaps because of the hash in the library name?
I've tried to inspect the wheels with auditwheel show with version 2 and 1.10, both says the following:
# auditwheel show pyarrow-0.14.0-cp37-cp37m-manylinux2010_x86_64.whl
pyarrow-0.14.0-cp37-cp37m-manylinux2010_x86_64.whl is consistent with
the following platform tag: "linux_x86_64".
The wheel references external versioned symbols in these system-
provided shared libraries: libgcc_s.so.1 with versions {'GCC_3.3',
'GCC_3.4', 'GCC_3.0'}, libpthread.so.0 with versions {'GLIBC_2.3.3',
'GLIBC_2.12', 'GLIBC_2.2.5', 'GLIBC_2.3.2'}, libc.so.6 with versions
{'GLIBC_2.4', 'GLIBC_2.6', 'GLIBC_2.2.5', 'GLIBC_2.7', 'GLIBC_2.3.4',
'GLIBC_2.3.2', 'GLIBC_2.3'}, libstdc++.so.6 with versions
{'CXXABI_1.3', 'GLIBCXX_3.4.10', 'GLIBCXX_3.4.9', 'GLIBCXX_3.4.11',
'GLIBCXX_3.4.5', 'GLIBCXX_3.4', 'CXXABI_1.3.2', 'CXXABI_1.3.3'},
librt.so.1 with versions {'GLIBC_2.2.5'}, libm.so.6 with versions
{'GLIBC_2.2.5'}, libdl.so.2 with versions {'GLIBC_2.2.5'}, libz.so.1
with versions {'ZLIB_1.2.0'}
This constrains the platform tag to "manylinux2010_x86_64". In order
to achieve a more compatible tag, you would need to recompile a new
wheel from source on a system with earlier versions of these
libraries, such as a recent manylinux image.

# auditwheel show pyarrow-0.14.0-cp37-cp37m-manylinux1_x86_64.whl
pyarrow-0.14.0-cp37-cp37m-manylinux1_x86_64.whl is consistent with the
following platform tag: "linux_x86_64".
The wheel references external versioned symbols in these system-
provided shared libraries: libgcc_s.so.1 with versions {'GCC_3.4',
'GCC_3.0', 'GCC_3.3'}, libc.so.6 with versions {'GLIBC_2.3',
'GLIBC_2.2.5', 'GLIBC_2.3.4', 'GLIBC_2.4', 'GLIBC_2.3.2'},
libstdc++.so.6 with versions {'CXXABI_1.3', 'GLIBCXX_3.4.5',
'GLIBCXX_3.4'}, librt.so.1 with versions {'GLIBC_2.2.5'}, libm.so.6
with versions {'GLIBC_2.2.5'}, libpthread.so.0 with versions
{'GLIBC_2.3.3', 'GLIBC_2.3.2', 'GLIBC_2.2.5'}, libdl.so.2 with
versions {'GLIBC_2.2.5'}, libz.so.1 with versions {'ZLIB_1.2.0'}
The following external shared libraries are required by the wheel:
{
"libc.so.6": "/lib/x86_64-linux-gnu/libc-2.24.so",
"libcrypt.so.1": "/lib/x86_64-linux-gnu/libcrypt-2.24.so",
"libdl.so.2": "/lib/x86_64-linux-gnu/libdl-2.24.so",
"libgcc_s.so.1": "/lib/x86_64-linux-gnu/libgcc_s.so.1",
"libm.so.6": "/lib/x86_64-linux-gnu/libm-2.24.so",
"libnsl.so.1": "/lib/x86_64-linux-gnu/libnsl-2.24.so",
"libpthread.so.0": "/lib/x86_64-linux-gnu/libpthread-2.24.so",
"librt.so.1": "/lib/x86_64-linux-gnu/librt-2.24.so",
"libstdc++.so.6": "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22",
"libutil.so.1": "/lib/x86_64-linux-gnu/libutil-2.24.so",
"libz.so.1": "/lib/x86_64-linux-gnu/libz.so.1.2.8"
}
In order to achieve the tag platform tag "manylinux2010_x86_64" the
following shared library dependencies will need to be eliminated:
libz.so.1
In order to achieve the tag platform tag "manylinux1_x86_64" the
following shared library dependencies will need to be eliminated:
libz.so.1

I think there are more todo left with the wheels. IMO the manylinux1 wheels are not compliant because of libz and the manylinux2010 wheels are not compliant because of both libz and liblz4 (but incorrectly reported by auditwheel?).
@kszucs
kszucs
commented
Jul 9, 2019•

edited

Loading

Copy link


Copy Markdown

Member
Perhaps we should use setup.py::move_shared_libs for libz on linux too? cc @xhochy
@wesm
wesm
commented
Jul 9, 2019

Copy link


Copy Markdown

MemberAuthor
Can you open a new JIRA about the libz issue with the information from this issue and we can investigate separately? I'm going to merge this for now.
+1
@wesm
wesm
commented
Jul 9, 2019

Copy link


Copy Markdown

MemberAuthor
Do we know why auditwheel did not raise either the liblz4 or libz issue before?
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
Sure, opening it.
@wesmwesm
closed this
in
7838886Jul 9, 2019
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
No idea, we only run auditwheel repair though.
@wesm
wesm
commented
Jul 9, 2019

Copy link


Copy Markdown

MemberAuthor
I see. We should do something about that then
@wesm
wesm
deleted the

ARROW-5868

branch
July 9, 2019 14:23
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
In case of manylinux2010 the report seems faulty, but adding it to the issue.
@xhochy
xhochy
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
auditwheel repair should package libz.so into the wheel. Only after the repair it should be consistent.
wesm added a commit
that referenced
this pull request
Jul 13, 2019
@wesm
ARROW-5868: [Python] Correctly remove liblz4 shared libraries from ma…
f356184
…nylinux2010 image so lz4 is statically linked
I pushed the image to Docker Hub (it was on quay.io before). I'm not sure what's the best way to test for this -- I checked the produced wheels locally to verify that liblz4.so is no longer required
Author: Wes McKinney <wesm+git@apache.org>
Closes#4828 from wesm/ARROW-5868 and squashes the following commits:
1fb1acb <Wes McKinney> Remove liblz4 shared libraries from /usr/local so static linking occurs
@asfimportasfimport
mentioned this pull request
Aug 1, 2019

Closed

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@wesm@codecov-io@pitrou@kszucs@xhochy

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
ARROW-5868: [Python] Correctly remove liblz4 shared libraries from manylinux2010 image so lz4 is statically linked - #4828
Closed
wesm wants to merge 1 commit into
apache:masterfrom 
wesm:ARROW-5868
Closed
ARROW-5868: [Python] Correctly remove liblz4 shared libraries from manylinux2010 image so lz4 is statically linked#4828
wesm wants to merge 1 commit into
apache:masterfrom 
wesm:ARROW-5868
Conversation
@wesm
@wesmwesm
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
I pushed the image to Docker Hub (it was on quay.io before). I'm not sure what's the best way to test for this -- I checked the produced wheels locally to verify that liblz4.so is no longer required
@codecov-io
codecov-io
commented
Jul 9, 2019

Copy link


Copy Markdown

Codecov Report
Merging #4828 into master will decrease coverage by 22.25%.

The diff coverage is n/a.
Impacted file tree graph
@@ Coverage Diff @@## master #4828 +/- ##
===========================================
- Coverage 87.43% 65.18% -22.26% 
===========================================
Files 997 487 -510 Lines 139804 64296 -75508 Branches 1418 0 -1418 ===========================================
- Hits 122241 41910 -80331 - Misses 17201 22386 +5185 + Partials 362 0 -362
Impacted FilesCoverage Δ
cpp/src/arrow/util/memory.h0% <0%> (-100%)⬇️
cpp/src/gandiva/date_utils.h0% <0%> (-100%)⬇️
cpp/src/arrow/util/memory.cc0% <0%> (-100%)⬇️
cpp/src/arrow/filesystem/util-internal.cc0% <0%> (-100%)⬇️
cpp/src/arrow/util/sse-util.h0% <0%> (-100%)⬇️
cpp/src/gandiva/decimal_type_util.h0% <0%> (-100%)⬇️
cpp/src/arrow/compute/logical_type.h0% <0%> (-100%)⬇️
cpp/src/parquet/hasher.h0% <0%> (-100%)⬇️
cpp/src/gandiva/basic_decimal_scalar.h0% <0%> (-100%)⬇️
cpp/src/arrow/compute/kernels/boolean.cc0% <0%> (-100%)⬇️
... and 748 more
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data

Powered by Codecov. Last update 90affbd...1fb1acb. Read the comment docs.
@pitrou
pitrou
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
Hmm... auditwheel didn't complain? Perhaps worth reporting as a bug?
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
We can add more docker images to test the produced wheels. Have you reproduced the issue?
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
I cannot really find a linux distribution without lz4 preinstalled.
@kszucs
kszucs
commented
Jul 9, 2019•

edited

Loading

Copy link


Copy Markdown

Member
So we statically link liblz4 in the manylinux1 wheels
# ldd pyarrow-manylinux1/libarrow.so.14 | grep z
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc28cef4000)

but dynamically in the manylinux2010 wheels
# ldd pyarrow-manylinux2010/libarrow.so.14 | grep z
liblz4.so.1 => not found (already deleted to reproduce the issue)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f56f7440000)

this what this PR resolves.
What I'm finding strange, that auditwheel seems to bundle libz for manylinux1:
# ls -lah pyarrow-manylinux1/*z*so.*
-rwxr-xr-x 1 root root 115K Jun 29 00:14 pyarrow-manylinux1/libz-7f57503f.so.1.2.11

while ldd still uses the system libz:
# ldd pyarrow-manylinux1/libarrow.so.14 | grep z
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f91fcf3f000)

For manylinux2010 we also have liblz4:
# ls -lah pyarrow-manylinux2010/*z*so.*
-rwxr-xr-x 1 root root 191K Jun 28 23:38 pyarrow-manylinux2010/liblz4-8cb8bdde.so.1.8.3
-rwxr-xr-x 1 root root 115K Jun 28 23:38 pyarrow-manylinux2010/libz-c69b9943.so.1.2.11

and ldd similarly tries to load the system libs:
# ldd pyarrow-manylinux2010/libarrow.so.14 | grep z
liblz4.so.1 => not found
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd72764e000)

Inspecting manylinux1 with LD_DEBUG=files,libs ldd libarrow.so.14 it seems like to search the right path, but cannot find the hashed version of libz libz-7f57503f.so.1.2.11
 463: file=libz.so.1 [0]; needed by ./libarrow.so.14 [0]
463: find library=libz.so.1 [0]; searching
463: search path=/tmp/pyarrow-manylinux1/. (RPATH from file ./libarrow.so.14)
463: trying file=/tmp/pyarrow-manylinux1/./libz.so.1
463: search cache=/etc/ld.so.cache
463: trying file=/lib/x86_64-linux-gnu/libz.so.1

There is no libz.so.1 just libz-7f57503f.so.1.2.11.
Similarly for manylinux2010 and libz:
 470: file=libz.so.1 [0]; needed by ./libarrow.so.14 [0]
470: find library=libz.so.1 [0]; searching
470: search path=/tmp/pyarrow-manylinux2010/. (RPATH from file ./libarrow.so.14)
470: trying file=/tmp/pyarrow-manylinux2010/./libz.so.1
470: search cache=/etc/ld.so.cache
470: trying file=/lib/x86_64-linux-gnu/libz.so.1

for liblz4 (again, I've deleted the system one):
 470: file=liblz4.so.1 [0]; needed by ./libarrow.so.14 [0]
470: find library=liblz4.so.1 [0]; searching
470: search path=/tmp/pyarrow-manylinux2010/. (RPATH from file ./libarrow.so.14)
470: trying file=/tmp/pyarrow-manylinux2010/./liblz4.so.1
470: search cache=/etc/ld.so.cache
470: search path=/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/x86_6$
:/usr/lib/x86_64-linux-gnu:/lib/tls/x86_64:/lib/tls:/lib/x86_64:/lib:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/x86_64:/usr/lib (system search path)

There are no libz.so.1 nor liblz4.so.1, just libz-c69b9943.so.1.2.11 and liblz4-8cb8bdde.so.1.8.3
According to https://www.python.org/dev/peps/pep-0571/liblz4 nor libz are part of the whitelist, and while these are bundled with the wheel, seemingly cannot be found - perhaps because of the hash in the library name?
I've tried to inspect the wheels with auditwheel show with version 2 and 1.10, both says the following:
# auditwheel show pyarrow-0.14.0-cp37-cp37m-manylinux2010_x86_64.whl
pyarrow-0.14.0-cp37-cp37m-manylinux2010_x86_64.whl is consistent with
the following platform tag: "linux_x86_64".
The wheel references external versioned symbols in these system-
provided shared libraries: libgcc_s.so.1 with versions {'GCC_3.3',
'GCC_3.4', 'GCC_3.0'}, libpthread.so.0 with versions {'GLIBC_2.3.3',
'GLIBC_2.12', 'GLIBC_2.2.5', 'GLIBC_2.3.2'}, libc.so.6 with versions
{'GLIBC_2.4', 'GLIBC_2.6', 'GLIBC_2.2.5', 'GLIBC_2.7', 'GLIBC_2.3.4',
'GLIBC_2.3.2', 'GLIBC_2.3'}, libstdc++.so.6 with versions
{'CXXABI_1.3', 'GLIBCXX_3.4.10', 'GLIBCXX_3.4.9', 'GLIBCXX_3.4.11',
'GLIBCXX_3.4.5', 'GLIBCXX_3.4', 'CXXABI_1.3.2', 'CXXABI_1.3.3'},
librt.so.1 with versions {'GLIBC_2.2.5'}, libm.so.6 with versions
{'GLIBC_2.2.5'}, libdl.so.2 with versions {'GLIBC_2.2.5'}, libz.so.1
with versions {'ZLIB_1.2.0'}
This constrains the platform tag to "manylinux2010_x86_64". In order
to achieve a more compatible tag, you would need to recompile a new
wheel from source on a system with earlier versions of these
libraries, such as a recent manylinux image.

# auditwheel show pyarrow-0.14.0-cp37-cp37m-manylinux1_x86_64.whl
pyarrow-0.14.0-cp37-cp37m-manylinux1_x86_64.whl is consistent with the
following platform tag: "linux_x86_64".
The wheel references external versioned symbols in these system-
provided shared libraries: libgcc_s.so.1 with versions {'GCC_3.4',
'GCC_3.0', 'GCC_3.3'}, libc.so.6 with versions {'GLIBC_2.3',
'GLIBC_2.2.5', 'GLIBC_2.3.4', 'GLIBC_2.4', 'GLIBC_2.3.2'},
libstdc++.so.6 with versions {'CXXABI_1.3', 'GLIBCXX_3.4.5',
'GLIBCXX_3.4'}, librt.so.1 with versions {'GLIBC_2.2.5'}, libm.so.6
with versions {'GLIBC_2.2.5'}, libpthread.so.0 with versions
{'GLIBC_2.3.3', 'GLIBC_2.3.2', 'GLIBC_2.2.5'}, libdl.so.2 with
versions {'GLIBC_2.2.5'}, libz.so.1 with versions {'ZLIB_1.2.0'}
The following external shared libraries are required by the wheel:
{
"libc.so.6": "/lib/x86_64-linux-gnu/libc-2.24.so",
"libcrypt.so.1": "/lib/x86_64-linux-gnu/libcrypt-2.24.so",
"libdl.so.2": "/lib/x86_64-linux-gnu/libdl-2.24.so",
"libgcc_s.so.1": "/lib/x86_64-linux-gnu/libgcc_s.so.1",
"libm.so.6": "/lib/x86_64-linux-gnu/libm-2.24.so",
"libnsl.so.1": "/lib/x86_64-linux-gnu/libnsl-2.24.so",
"libpthread.so.0": "/lib/x86_64-linux-gnu/libpthread-2.24.so",
"librt.so.1": "/lib/x86_64-linux-gnu/librt-2.24.so",
"libstdc++.so.6": "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22",
"libutil.so.1": "/lib/x86_64-linux-gnu/libutil-2.24.so",
"libz.so.1": "/lib/x86_64-linux-gnu/libz.so.1.2.8"
}
In order to achieve the tag platform tag "manylinux2010_x86_64" the
following shared library dependencies will need to be eliminated:
libz.so.1
In order to achieve the tag platform tag "manylinux1_x86_64" the
following shared library dependencies will need to be eliminated:
libz.so.1

I think there are more todo left with the wheels. IMO the manylinux1 wheels are not compliant because of libz and the manylinux2010 wheels are not compliant because of both libz and liblz4 (but incorrectly reported by auditwheel?).
@kszucs
kszucs
commented
Jul 9, 2019•

edited

Loading

Copy link


Copy Markdown

Member
Perhaps we should use setup.py::move_shared_libs for libz on linux too? cc @xhochy
@wesm
wesm
commented
Jul 9, 2019

Copy link


Copy Markdown

MemberAuthor
Can you open a new JIRA about the libz issue with the information from this issue and we can investigate separately? I'm going to merge this for now.
+1
@wesm
wesm
commented
Jul 9, 2019

Copy link


Copy Markdown

MemberAuthor
Do we know why auditwheel did not raise either the liblz4 or libz issue before?
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
Sure, opening it.
@wesmwesm
closed this
in
7838886Jul 9, 2019
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
No idea, we only run auditwheel repair though.
@wesm
wesm
commented
Jul 9, 2019

Copy link


Copy Markdown

MemberAuthor
I see. We should do something about that then
@wesm
wesm
deleted the

ARROW-5868

branch
July 9, 2019 14:23
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
In case of manylinux2010 the report seems faulty, but adding it to the issue.
@xhochy
xhochy
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
auditwheel repair should package libz.so into the wheel. Only after the repair it should be consistent.
wesm added a commit
that referenced
this pull request
Jul 13, 2019
@wesm
ARROW-5868: [Python] Correctly remove liblz4 shared libraries from ma…
f356184
…nylinux2010 image so lz4 is statically linked
I pushed the image to Docker Hub (it was on quay.io before). I'm not sure what's the best way to test for this -- I checked the produced wheels locally to verify that liblz4.so is no longer required
Author: Wes McKinney <wesm+git@apache.org>
Closes#4828 from wesm/ARROW-5868 and squashes the following commits:
1fb1acb <Wes McKinney> Remove liblz4 shared libraries from /usr/local so static linking occurs
@asfimportasfimport
mentioned this pull request
Aug 1, 2019

Closed

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@wesm@codecov-io@pitrou@kszucs@xhochy

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
ARROW-5868: [Python] Correctly remove liblz4 shared libraries from manylinux2010 image so lz4 is statically linked - #4828
Closed
wesm wants to merge 1 commit into
apache:masterfrom 
wesm:ARROW-5868
Closed
ARROW-5868: [Python] Correctly remove liblz4 shared libraries from manylinux2010 image so lz4 is statically linked#4828
wesm wants to merge 1 commit into
apache:masterfrom 
wesm:ARROW-5868
Conversation
@wesm
@wesmwesm
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
I pushed the image to Docker Hub (it was on quay.io before). I'm not sure what's the best way to test for this -- I checked the produced wheels locally to verify that liblz4.so is no longer required
@codecov-io
codecov-io
commented
Jul 9, 2019

Copy link


Copy Markdown

Codecov Report
Merging #4828 into master will decrease coverage by 22.25%.

The diff coverage is n/a.
Impacted file tree graph
@@ Coverage Diff @@## master #4828 +/- ##
===========================================
- Coverage 87.43% 65.18% -22.26% 
===========================================
Files 997 487 -510 Lines 139804 64296 -75508 Branches 1418 0 -1418 ===========================================
- Hits 122241 41910 -80331 - Misses 17201 22386 +5185 + Partials 362 0 -362
Impacted FilesCoverage Δ
cpp/src/arrow/util/memory.h0% <0%> (-100%)⬇️
cpp/src/gandiva/date_utils.h0% <0%> (-100%)⬇️
cpp/src/arrow/util/memory.cc0% <0%> (-100%)⬇️
cpp/src/arrow/filesystem/util-internal.cc0% <0%> (-100%)⬇️
cpp/src/arrow/util/sse-util.h0% <0%> (-100%)⬇️
cpp/src/gandiva/decimal_type_util.h0% <0%> (-100%)⬇️
cpp/src/arrow/compute/logical_type.h0% <0%> (-100%)⬇️
cpp/src/parquet/hasher.h0% <0%> (-100%)⬇️
cpp/src/gandiva/basic_decimal_scalar.h0% <0%> (-100%)⬇️
cpp/src/arrow/compute/kernels/boolean.cc0% <0%> (-100%)⬇️
... and 748 more
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data

Powered by Codecov. Last update 90affbd...1fb1acb. Read the comment docs.
@pitrou
pitrou
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
Hmm... auditwheel didn't complain? Perhaps worth reporting as a bug?
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
We can add more docker images to test the produced wheels. Have you reproduced the issue?
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
I cannot really find a linux distribution without lz4 preinstalled.
@kszucs
kszucs
commented
Jul 9, 2019•

edited

Loading

Copy link


Copy Markdown

Member
So we statically link liblz4 in the manylinux1 wheels
# ldd pyarrow-manylinux1/libarrow.so.14 | grep z
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc28cef4000)

but dynamically in the manylinux2010 wheels
# ldd pyarrow-manylinux2010/libarrow.so.14 | grep z
liblz4.so.1 => not found (already deleted to reproduce the issue)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f56f7440000)

this what this PR resolves.
What I'm finding strange, that auditwheel seems to bundle libz for manylinux1:
# ls -lah pyarrow-manylinux1/*z*so.*
-rwxr-xr-x 1 root root 115K Jun 29 00:14 pyarrow-manylinux1/libz-7f57503f.so.1.2.11

while ldd still uses the system libz:
# ldd pyarrow-manylinux1/libarrow.so.14 | grep z
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f91fcf3f000)

For manylinux2010 we also have liblz4:
# ls -lah pyarrow-manylinux2010/*z*so.*
-rwxr-xr-x 1 root root 191K Jun 28 23:38 pyarrow-manylinux2010/liblz4-8cb8bdde.so.1.8.3
-rwxr-xr-x 1 root root 115K Jun 28 23:38 pyarrow-manylinux2010/libz-c69b9943.so.1.2.11

and ldd similarly tries to load the system libs:
# ldd pyarrow-manylinux2010/libarrow.so.14 | grep z
liblz4.so.1 => not found
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd72764e000)

Inspecting manylinux1 with LD_DEBUG=files,libs ldd libarrow.so.14 it seems like to search the right path, but cannot find the hashed version of libz libz-7f57503f.so.1.2.11
 463: file=libz.so.1 [0]; needed by ./libarrow.so.14 [0]
463: find library=libz.so.1 [0]; searching
463: search path=/tmp/pyarrow-manylinux1/. (RPATH from file ./libarrow.so.14)
463: trying file=/tmp/pyarrow-manylinux1/./libz.so.1
463: search cache=/etc/ld.so.cache
463: trying file=/lib/x86_64-linux-gnu/libz.so.1

There is no libz.so.1 just libz-7f57503f.so.1.2.11.
Similarly for manylinux2010 and libz:
 470: file=libz.so.1 [0]; needed by ./libarrow.so.14 [0]
470: find library=libz.so.1 [0]; searching
470: search path=/tmp/pyarrow-manylinux2010/. (RPATH from file ./libarrow.so.14)
470: trying file=/tmp/pyarrow-manylinux2010/./libz.so.1
470: search cache=/etc/ld.so.cache
470: trying file=/lib/x86_64-linux-gnu/libz.so.1

for liblz4 (again, I've deleted the system one):
 470: file=liblz4.so.1 [0]; needed by ./libarrow.so.14 [0]
470: find library=liblz4.so.1 [0]; searching
470: search path=/tmp/pyarrow-manylinux2010/. (RPATH from file ./libarrow.so.14)
470: trying file=/tmp/pyarrow-manylinux2010/./liblz4.so.1
470: search cache=/etc/ld.so.cache
470: search path=/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/x86_6$
:/usr/lib/x86_64-linux-gnu:/lib/tls/x86_64:/lib/tls:/lib/x86_64:/lib:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/x86_64:/usr/lib (system search path)

There are no libz.so.1 nor liblz4.so.1, just libz-c69b9943.so.1.2.11 and liblz4-8cb8bdde.so.1.8.3
According to https://www.python.org/dev/peps/pep-0571/liblz4 nor libz are part of the whitelist, and while these are bundled with the wheel, seemingly cannot be found - perhaps because of the hash in the library name?
I've tried to inspect the wheels with auditwheel show with version 2 and 1.10, both says the following:
# auditwheel show pyarrow-0.14.0-cp37-cp37m-manylinux2010_x86_64.whl
pyarrow-0.14.0-cp37-cp37m-manylinux2010_x86_64.whl is consistent with
the following platform tag: "linux_x86_64".
The wheel references external versioned symbols in these system-
provided shared libraries: libgcc_s.so.1 with versions {'GCC_3.3',
'GCC_3.4', 'GCC_3.0'}, libpthread.so.0 with versions {'GLIBC_2.3.3',
'GLIBC_2.12', 'GLIBC_2.2.5', 'GLIBC_2.3.2'}, libc.so.6 with versions
{'GLIBC_2.4', 'GLIBC_2.6', 'GLIBC_2.2.5', 'GLIBC_2.7', 'GLIBC_2.3.4',
'GLIBC_2.3.2', 'GLIBC_2.3'}, libstdc++.so.6 with versions
{'CXXABI_1.3', 'GLIBCXX_3.4.10', 'GLIBCXX_3.4.9', 'GLIBCXX_3.4.11',
'GLIBCXX_3.4.5', 'GLIBCXX_3.4', 'CXXABI_1.3.2', 'CXXABI_1.3.3'},
librt.so.1 with versions {'GLIBC_2.2.5'}, libm.so.6 with versions
{'GLIBC_2.2.5'}, libdl.so.2 with versions {'GLIBC_2.2.5'}, libz.so.1
with versions {'ZLIB_1.2.0'}
This constrains the platform tag to "manylinux2010_x86_64". In order
to achieve a more compatible tag, you would need to recompile a new
wheel from source on a system with earlier versions of these
libraries, such as a recent manylinux image.

# auditwheel show pyarrow-0.14.0-cp37-cp37m-manylinux1_x86_64.whl
pyarrow-0.14.0-cp37-cp37m-manylinux1_x86_64.whl is consistent with the
following platform tag: "linux_x86_64".
The wheel references external versioned symbols in these system-
provided shared libraries: libgcc_s.so.1 with versions {'GCC_3.4',
'GCC_3.0', 'GCC_3.3'}, libc.so.6 with versions {'GLIBC_2.3',
'GLIBC_2.2.5', 'GLIBC_2.3.4', 'GLIBC_2.4', 'GLIBC_2.3.2'},
libstdc++.so.6 with versions {'CXXABI_1.3', 'GLIBCXX_3.4.5',
'GLIBCXX_3.4'}, librt.so.1 with versions {'GLIBC_2.2.5'}, libm.so.6
with versions {'GLIBC_2.2.5'}, libpthread.so.0 with versions
{'GLIBC_2.3.3', 'GLIBC_2.3.2', 'GLIBC_2.2.5'}, libdl.so.2 with
versions {'GLIBC_2.2.5'}, libz.so.1 with versions {'ZLIB_1.2.0'}
The following external shared libraries are required by the wheel:
{
"libc.so.6": "/lib/x86_64-linux-gnu/libc-2.24.so",
"libcrypt.so.1": "/lib/x86_64-linux-gnu/libcrypt-2.24.so",
"libdl.so.2": "/lib/x86_64-linux-gnu/libdl-2.24.so",
"libgcc_s.so.1": "/lib/x86_64-linux-gnu/libgcc_s.so.1",
"libm.so.6": "/lib/x86_64-linux-gnu/libm-2.24.so",
"libnsl.so.1": "/lib/x86_64-linux-gnu/libnsl-2.24.so",
"libpthread.so.0": "/lib/x86_64-linux-gnu/libpthread-2.24.so",
"librt.so.1": "/lib/x86_64-linux-gnu/librt-2.24.so",
"libstdc++.so.6": "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22",
"libutil.so.1": "/lib/x86_64-linux-gnu/libutil-2.24.so",
"libz.so.1": "/lib/x86_64-linux-gnu/libz.so.1.2.8"
}
In order to achieve the tag platform tag "manylinux2010_x86_64" the
following shared library dependencies will need to be eliminated:
libz.so.1
In order to achieve the tag platform tag "manylinux1_x86_64" the
following shared library dependencies will need to be eliminated:
libz.so.1

I think there are more todo left with the wheels. IMO the manylinux1 wheels are not compliant because of libz and the manylinux2010 wheels are not compliant because of both libz and liblz4 (but incorrectly reported by auditwheel?).
@kszucs
kszucs
commented
Jul 9, 2019•

edited

Loading

Copy link


Copy Markdown

Member
Perhaps we should use setup.py::move_shared_libs for libz on linux too? cc @xhochy
@wesm
wesm
commented
Jul 9, 2019

Copy link


Copy Markdown

MemberAuthor
Can you open a new JIRA about the libz issue with the information from this issue and we can investigate separately? I'm going to merge this for now.
+1
@wesm
wesm
commented
Jul 9, 2019

Copy link


Copy Markdown

MemberAuthor
Do we know why auditwheel did not raise either the liblz4 or libz issue before?
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
Sure, opening it.
@wesmwesm
closed this
in
7838886Jul 9, 2019
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
No idea, we only run auditwheel repair though.
@wesm
wesm
commented
Jul 9, 2019

Copy link


Copy Markdown

MemberAuthor
I see. We should do something about that then
@wesm
wesm
deleted the

ARROW-5868

branch
July 9, 2019 14:23
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
In case of manylinux2010 the report seems faulty, but adding it to the issue.
@xhochy
xhochy
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
auditwheel repair should package libz.so into the wheel. Only after the repair it should be consistent.
wesm added a commit
that referenced
this pull request
Jul 13, 2019
@wesm
ARROW-5868: [Python] Correctly remove liblz4 shared libraries from ma…
f356184
…nylinux2010 image so lz4 is statically linked
I pushed the image to Docker Hub (it was on quay.io before). I'm not sure what's the best way to test for this -- I checked the produced wheels locally to verify that liblz4.so is no longer required
Author: Wes McKinney <wesm+git@apache.org>
Closes#4828 from wesm/ARROW-5868 and squashes the following commits:
1fb1acb <Wes McKinney> Remove liblz4 shared libraries from /usr/local so static linking occurs
@asfimportasfimport
mentioned this pull request
Aug 1, 2019

Closed

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@wesm@codecov-io@pitrou@kszucs@xhochy

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
ARROW-5868: [Python] Correctly remove liblz4 shared libraries from manylinux2010 image so lz4 is statically linked - #4828
Closed
wesm wants to merge 1 commit into
apache:masterfrom 
wesm:ARROW-5868
Closed
ARROW-5868: [Python] Correctly remove liblz4 shared libraries from manylinux2010 image so lz4 is statically linked#4828
wesm wants to merge 1 commit into
apache:masterfrom 
wesm:ARROW-5868
Conversation
@wesm
@wesmwesm
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
I pushed the image to Docker Hub (it was on quay.io before). I'm not sure what's the best way to test for this -- I checked the produced wheels locally to verify that liblz4.so is no longer required
@codecov-io
codecov-io
commented
Jul 9, 2019

Copy link


Copy Markdown

Codecov Report
Merging #4828 into master will decrease coverage by 22.25%.

The diff coverage is n/a.
Impacted file tree graph
@@ Coverage Diff @@## master #4828 +/- ##
===========================================
- Coverage 87.43% 65.18% -22.26% 
===========================================
Files 997 487 -510 Lines 139804 64296 -75508 Branches 1418 0 -1418 ===========================================
- Hits 122241 41910 -80331 - Misses 17201 22386 +5185 + Partials 362 0 -362
Impacted FilesCoverage Δ
cpp/src/arrow/util/memory.h0% <0%> (-100%)⬇️
cpp/src/gandiva/date_utils.h0% <0%> (-100%)⬇️
cpp/src/arrow/util/memory.cc0% <0%> (-100%)⬇️
cpp/src/arrow/filesystem/util-internal.cc0% <0%> (-100%)⬇️
cpp/src/arrow/util/sse-util.h0% <0%> (-100%)⬇️
cpp/src/gandiva/decimal_type_util.h0% <0%> (-100%)⬇️
cpp/src/arrow/compute/logical_type.h0% <0%> (-100%)⬇️
cpp/src/parquet/hasher.h0% <0%> (-100%)⬇️
cpp/src/gandiva/basic_decimal_scalar.h0% <0%> (-100%)⬇️
cpp/src/arrow/compute/kernels/boolean.cc0% <0%> (-100%)⬇️
... and 748 more
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data

Powered by Codecov. Last update 90affbd...1fb1acb. Read the comment docs.
@pitrou
pitrou
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
Hmm... auditwheel didn't complain? Perhaps worth reporting as a bug?
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
We can add more docker images to test the produced wheels. Have you reproduced the issue?
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
I cannot really find a linux distribution without lz4 preinstalled.
@kszucs
kszucs
commented
Jul 9, 2019•

edited

Loading

Copy link


Copy Markdown

Member
So we statically link liblz4 in the manylinux1 wheels
# ldd pyarrow-manylinux1/libarrow.so.14 | grep z
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc28cef4000)

but dynamically in the manylinux2010 wheels
# ldd pyarrow-manylinux2010/libarrow.so.14 | grep z
liblz4.so.1 => not found (already deleted to reproduce the issue)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f56f7440000)

this what this PR resolves.
What I'm finding strange, that auditwheel seems to bundle libz for manylinux1:
# ls -lah pyarrow-manylinux1/*z*so.*
-rwxr-xr-x 1 root root 115K Jun 29 00:14 pyarrow-manylinux1/libz-7f57503f.so.1.2.11

while ldd still uses the system libz:
# ldd pyarrow-manylinux1/libarrow.so.14 | grep z
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f91fcf3f000)

For manylinux2010 we also have liblz4:
# ls -lah pyarrow-manylinux2010/*z*so.*
-rwxr-xr-x 1 root root 191K Jun 28 23:38 pyarrow-manylinux2010/liblz4-8cb8bdde.so.1.8.3
-rwxr-xr-x 1 root root 115K Jun 28 23:38 pyarrow-manylinux2010/libz-c69b9943.so.1.2.11

and ldd similarly tries to load the system libs:
# ldd pyarrow-manylinux2010/libarrow.so.14 | grep z
liblz4.so.1 => not found
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd72764e000)

Inspecting manylinux1 with LD_DEBUG=files,libs ldd libarrow.so.14 it seems like to search the right path, but cannot find the hashed version of libz libz-7f57503f.so.1.2.11
 463: file=libz.so.1 [0]; needed by ./libarrow.so.14 [0]
463: find library=libz.so.1 [0]; searching
463: search path=/tmp/pyarrow-manylinux1/. (RPATH from file ./libarrow.so.14)
463: trying file=/tmp/pyarrow-manylinux1/./libz.so.1
463: search cache=/etc/ld.so.cache
463: trying file=/lib/x86_64-linux-gnu/libz.so.1

There is no libz.so.1 just libz-7f57503f.so.1.2.11.
Similarly for manylinux2010 and libz:
 470: file=libz.so.1 [0]; needed by ./libarrow.so.14 [0]
470: find library=libz.so.1 [0]; searching
470: search path=/tmp/pyarrow-manylinux2010/. (RPATH from file ./libarrow.so.14)
470: trying file=/tmp/pyarrow-manylinux2010/./libz.so.1
470: search cache=/etc/ld.so.cache
470: trying file=/lib/x86_64-linux-gnu/libz.so.1

for liblz4 (again, I've deleted the system one):
 470: file=liblz4.so.1 [0]; needed by ./libarrow.so.14 [0]
470: find library=liblz4.so.1 [0]; searching
470: search path=/tmp/pyarrow-manylinux2010/. (RPATH from file ./libarrow.so.14)
470: trying file=/tmp/pyarrow-manylinux2010/./liblz4.so.1
470: search cache=/etc/ld.so.cache
470: search path=/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/x86_6$
:/usr/lib/x86_64-linux-gnu:/lib/tls/x86_64:/lib/tls:/lib/x86_64:/lib:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/x86_64:/usr/lib (system search path)

There are no libz.so.1 nor liblz4.so.1, just libz-c69b9943.so.1.2.11 and liblz4-8cb8bdde.so.1.8.3
According to https://www.python.org/dev/peps/pep-0571/liblz4 nor libz are part of the whitelist, and while these are bundled with the wheel, seemingly cannot be found - perhaps because of the hash in the library name?
I've tried to inspect the wheels with auditwheel show with version 2 and 1.10, both says the following:
# auditwheel show pyarrow-0.14.0-cp37-cp37m-manylinux2010_x86_64.whl
pyarrow-0.14.0-cp37-cp37m-manylinux2010_x86_64.whl is consistent with
the following platform tag: "linux_x86_64".
The wheel references external versioned symbols in these system-
provided shared libraries: libgcc_s.so.1 with versions {'GCC_3.3',
'GCC_3.4', 'GCC_3.0'}, libpthread.so.0 with versions {'GLIBC_2.3.3',
'GLIBC_2.12', 'GLIBC_2.2.5', 'GLIBC_2.3.2'}, libc.so.6 with versions
{'GLIBC_2.4', 'GLIBC_2.6', 'GLIBC_2.2.5', 'GLIBC_2.7', 'GLIBC_2.3.4',
'GLIBC_2.3.2', 'GLIBC_2.3'}, libstdc++.so.6 with versions
{'CXXABI_1.3', 'GLIBCXX_3.4.10', 'GLIBCXX_3.4.9', 'GLIBCXX_3.4.11',
'GLIBCXX_3.4.5', 'GLIBCXX_3.4', 'CXXABI_1.3.2', 'CXXABI_1.3.3'},
librt.so.1 with versions {'GLIBC_2.2.5'}, libm.so.6 with versions
{'GLIBC_2.2.5'}, libdl.so.2 with versions {'GLIBC_2.2.5'}, libz.so.1
with versions {'ZLIB_1.2.0'}
This constrains the platform tag to "manylinux2010_x86_64". In order
to achieve a more compatible tag, you would need to recompile a new
wheel from source on a system with earlier versions of these
libraries, such as a recent manylinux image.

# auditwheel show pyarrow-0.14.0-cp37-cp37m-manylinux1_x86_64.whl
pyarrow-0.14.0-cp37-cp37m-manylinux1_x86_64.whl is consistent with the
following platform tag: "linux_x86_64".
The wheel references external versioned symbols in these system-
provided shared libraries: libgcc_s.so.1 with versions {'GCC_3.4',
'GCC_3.0', 'GCC_3.3'}, libc.so.6 with versions {'GLIBC_2.3',
'GLIBC_2.2.5', 'GLIBC_2.3.4', 'GLIBC_2.4', 'GLIBC_2.3.2'},
libstdc++.so.6 with versions {'CXXABI_1.3', 'GLIBCXX_3.4.5',
'GLIBCXX_3.4'}, librt.so.1 with versions {'GLIBC_2.2.5'}, libm.so.6
with versions {'GLIBC_2.2.5'}, libpthread.so.0 with versions
{'GLIBC_2.3.3', 'GLIBC_2.3.2', 'GLIBC_2.2.5'}, libdl.so.2 with
versions {'GLIBC_2.2.5'}, libz.so.1 with versions {'ZLIB_1.2.0'}
The following external shared libraries are required by the wheel:
{
"libc.so.6": "/lib/x86_64-linux-gnu/libc-2.24.so",
"libcrypt.so.1": "/lib/x86_64-linux-gnu/libcrypt-2.24.so",
"libdl.so.2": "/lib/x86_64-linux-gnu/libdl-2.24.so",
"libgcc_s.so.1": "/lib/x86_64-linux-gnu/libgcc_s.so.1",
"libm.so.6": "/lib/x86_64-linux-gnu/libm-2.24.so",
"libnsl.so.1": "/lib/x86_64-linux-gnu/libnsl-2.24.so",
"libpthread.so.0": "/lib/x86_64-linux-gnu/libpthread-2.24.so",
"librt.so.1": "/lib/x86_64-linux-gnu/librt-2.24.so",
"libstdc++.so.6": "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22",
"libutil.so.1": "/lib/x86_64-linux-gnu/libutil-2.24.so",
"libz.so.1": "/lib/x86_64-linux-gnu/libz.so.1.2.8"
}
In order to achieve the tag platform tag "manylinux2010_x86_64" the
following shared library dependencies will need to be eliminated:
libz.so.1
In order to achieve the tag platform tag "manylinux1_x86_64" the
following shared library dependencies will need to be eliminated:
libz.so.1

I think there are more todo left with the wheels. IMO the manylinux1 wheels are not compliant because of libz and the manylinux2010 wheels are not compliant because of both libz and liblz4 (but incorrectly reported by auditwheel?).
@kszucs
kszucs
commented
Jul 9, 2019•

edited

Loading

Copy link


Copy Markdown

Member
Perhaps we should use setup.py::move_shared_libs for libz on linux too? cc @xhochy
@wesm
wesm
commented
Jul 9, 2019

Copy link


Copy Markdown

MemberAuthor
Can you open a new JIRA about the libz issue with the information from this issue and we can investigate separately? I'm going to merge this for now.
+1
@wesm
wesm
commented
Jul 9, 2019

Copy link


Copy Markdown

MemberAuthor
Do we know why auditwheel did not raise either the liblz4 or libz issue before?
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
Sure, opening it.
@wesmwesm
closed this
in
7838886Jul 9, 2019
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
No idea, we only run auditwheel repair though.
@wesm
wesm
commented
Jul 9, 2019

Copy link


Copy Markdown

MemberAuthor
I see. We should do something about that then
@wesm
wesm
deleted the

ARROW-5868

branch
July 9, 2019 14:23
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
In case of manylinux2010 the report seems faulty, but adding it to the issue.
@xhochy
xhochy
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
auditwheel repair should package libz.so into the wheel. Only after the repair it should be consistent.
wesm added a commit
that referenced
this pull request
Jul 13, 2019
@wesm
ARROW-5868: [Python] Correctly remove liblz4 shared libraries from ma…
f356184
…nylinux2010 image so lz4 is statically linked
I pushed the image to Docker Hub (it was on quay.io before). I'm not sure what's the best way to test for this -- I checked the produced wheels locally to verify that liblz4.so is no longer required
Author: Wes McKinney <wesm+git@apache.org>
Closes#4828 from wesm/ARROW-5868 and squashes the following commits:
1fb1acb <Wes McKinney> Remove liblz4 shared libraries from /usr/local so static linking occurs
@asfimportasfimport
mentioned this pull request
Aug 1, 2019

Closed

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@wesm@codecov-io@pitrou@kszucs@xhochy

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
ARROW-5868: [Python] Correctly remove liblz4 shared libraries from manylinux2010 image so lz4 is statically linked - #4828
Closed
wesm wants to merge 1 commit into
apache:masterfrom 
wesm:ARROW-5868
Closed
ARROW-5868: [Python] Correctly remove liblz4 shared libraries from manylinux2010 image so lz4 is statically linked#4828
wesm wants to merge 1 commit into
apache:masterfrom 
wesm:ARROW-5868
Conversation
@wesm
@wesmwesm
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
I pushed the image to Docker Hub (it was on quay.io before). I'm not sure what's the best way to test for this -- I checked the produced wheels locally to verify that liblz4.so is no longer required
@codecov-io
codecov-io
commented
Jul 9, 2019

Copy link


Copy Markdown

Codecov Report
Merging #4828 into master will decrease coverage by 22.25%.

The diff coverage is n/a.
Impacted file tree graph
@@ Coverage Diff @@## master #4828 +/- ##
===========================================
- Coverage 87.43% 65.18% -22.26% 
===========================================
Files 997 487 -510 Lines 139804 64296 -75508 Branches 1418 0 -1418 ===========================================
- Hits 122241 41910 -80331 - Misses 17201 22386 +5185 + Partials 362 0 -362
Impacted FilesCoverage Δ
cpp/src/arrow/util/memory.h0% <0%> (-100%)⬇️
cpp/src/gandiva/date_utils.h0% <0%> (-100%)⬇️
cpp/src/arrow/util/memory.cc0% <0%> (-100%)⬇️
cpp/src/arrow/filesystem/util-internal.cc0% <0%> (-100%)⬇️
cpp/src/arrow/util/sse-util.h0% <0%> (-100%)⬇️
cpp/src/gandiva/decimal_type_util.h0% <0%> (-100%)⬇️
cpp/src/arrow/compute/logical_type.h0% <0%> (-100%)⬇️
cpp/src/parquet/hasher.h0% <0%> (-100%)⬇️
cpp/src/gandiva/basic_decimal_scalar.h0% <0%> (-100%)⬇️
cpp/src/arrow/compute/kernels/boolean.cc0% <0%> (-100%)⬇️
... and 748 more
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data

Powered by Codecov. Last update 90affbd...1fb1acb. Read the comment docs.
@pitrou
pitrou
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
Hmm... auditwheel didn't complain? Perhaps worth reporting as a bug?
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
We can add more docker images to test the produced wheels. Have you reproduced the issue?
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
I cannot really find a linux distribution without lz4 preinstalled.
@kszucs
kszucs
commented
Jul 9, 2019•

edited

Loading

Copy link


Copy Markdown

Member
So we statically link liblz4 in the manylinux1 wheels
# ldd pyarrow-manylinux1/libarrow.so.14 | grep z
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc28cef4000)

but dynamically in the manylinux2010 wheels
# ldd pyarrow-manylinux2010/libarrow.so.14 | grep z
liblz4.so.1 => not found (already deleted to reproduce the issue)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f56f7440000)

this what this PR resolves.
What I'm finding strange, that auditwheel seems to bundle libz for manylinux1:
# ls -lah pyarrow-manylinux1/*z*so.*
-rwxr-xr-x 1 root root 115K Jun 29 00:14 pyarrow-manylinux1/libz-7f57503f.so.1.2.11

while ldd still uses the system libz:
# ldd pyarrow-manylinux1/libarrow.so.14 | grep z
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f91fcf3f000)

For manylinux2010 we also have liblz4:
# ls -lah pyarrow-manylinux2010/*z*so.*
-rwxr-xr-x 1 root root 191K Jun 28 23:38 pyarrow-manylinux2010/liblz4-8cb8bdde.so.1.8.3
-rwxr-xr-x 1 root root 115K Jun 28 23:38 pyarrow-manylinux2010/libz-c69b9943.so.1.2.11

and ldd similarly tries to load the system libs:
# ldd pyarrow-manylinux2010/libarrow.so.14 | grep z
liblz4.so.1 => not found
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd72764e000)

Inspecting manylinux1 with LD_DEBUG=files,libs ldd libarrow.so.14 it seems like to search the right path, but cannot find the hashed version of libz libz-7f57503f.so.1.2.11
 463: file=libz.so.1 [0]; needed by ./libarrow.so.14 [0]
463: find library=libz.so.1 [0]; searching
463: search path=/tmp/pyarrow-manylinux1/. (RPATH from file ./libarrow.so.14)
463: trying file=/tmp/pyarrow-manylinux1/./libz.so.1
463: search cache=/etc/ld.so.cache
463: trying file=/lib/x86_64-linux-gnu/libz.so.1

There is no libz.so.1 just libz-7f57503f.so.1.2.11.
Similarly for manylinux2010 and libz:
 470: file=libz.so.1 [0]; needed by ./libarrow.so.14 [0]
470: find library=libz.so.1 [0]; searching
470: search path=/tmp/pyarrow-manylinux2010/. (RPATH from file ./libarrow.so.14)
470: trying file=/tmp/pyarrow-manylinux2010/./libz.so.1
470: search cache=/etc/ld.so.cache
470: trying file=/lib/x86_64-linux-gnu/libz.so.1

for liblz4 (again, I've deleted the system one):
 470: file=liblz4.so.1 [0]; needed by ./libarrow.so.14 [0]
470: find library=liblz4.so.1 [0]; searching
470: search path=/tmp/pyarrow-manylinux2010/. (RPATH from file ./libarrow.so.14)
470: trying file=/tmp/pyarrow-manylinux2010/./liblz4.so.1
470: search cache=/etc/ld.so.cache
470: search path=/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/x86_6$
:/usr/lib/x86_64-linux-gnu:/lib/tls/x86_64:/lib/tls:/lib/x86_64:/lib:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/x86_64:/usr/lib (system search path)

There are no libz.so.1 nor liblz4.so.1, just libz-c69b9943.so.1.2.11 and liblz4-8cb8bdde.so.1.8.3
According to https://www.python.org/dev/peps/pep-0571/liblz4 nor libz are part of the whitelist, and while these are bundled with the wheel, seemingly cannot be found - perhaps because of the hash in the library name?
I've tried to inspect the wheels with auditwheel show with version 2 and 1.10, both says the following:
# auditwheel show pyarrow-0.14.0-cp37-cp37m-manylinux2010_x86_64.whl
pyarrow-0.14.0-cp37-cp37m-manylinux2010_x86_64.whl is consistent with
the following platform tag: "linux_x86_64".
The wheel references external versioned symbols in these system-
provided shared libraries: libgcc_s.so.1 with versions {'GCC_3.3',
'GCC_3.4', 'GCC_3.0'}, libpthread.so.0 with versions {'GLIBC_2.3.3',
'GLIBC_2.12', 'GLIBC_2.2.5', 'GLIBC_2.3.2'}, libc.so.6 with versions
{'GLIBC_2.4', 'GLIBC_2.6', 'GLIBC_2.2.5', 'GLIBC_2.7', 'GLIBC_2.3.4',
'GLIBC_2.3.2', 'GLIBC_2.3'}, libstdc++.so.6 with versions
{'CXXABI_1.3', 'GLIBCXX_3.4.10', 'GLIBCXX_3.4.9', 'GLIBCXX_3.4.11',
'GLIBCXX_3.4.5', 'GLIBCXX_3.4', 'CXXABI_1.3.2', 'CXXABI_1.3.3'},
librt.so.1 with versions {'GLIBC_2.2.5'}, libm.so.6 with versions
{'GLIBC_2.2.5'}, libdl.so.2 with versions {'GLIBC_2.2.5'}, libz.so.1
with versions {'ZLIB_1.2.0'}
This constrains the platform tag to "manylinux2010_x86_64". In order
to achieve a more compatible tag, you would need to recompile a new
wheel from source on a system with earlier versions of these
libraries, such as a recent manylinux image.

# auditwheel show pyarrow-0.14.0-cp37-cp37m-manylinux1_x86_64.whl
pyarrow-0.14.0-cp37-cp37m-manylinux1_x86_64.whl is consistent with the
following platform tag: "linux_x86_64".
The wheel references external versioned symbols in these system-
provided shared libraries: libgcc_s.so.1 with versions {'GCC_3.4',
'GCC_3.0', 'GCC_3.3'}, libc.so.6 with versions {'GLIBC_2.3',
'GLIBC_2.2.5', 'GLIBC_2.3.4', 'GLIBC_2.4', 'GLIBC_2.3.2'},
libstdc++.so.6 with versions {'CXXABI_1.3', 'GLIBCXX_3.4.5',
'GLIBCXX_3.4'}, librt.so.1 with versions {'GLIBC_2.2.5'}, libm.so.6
with versions {'GLIBC_2.2.5'}, libpthread.so.0 with versions
{'GLIBC_2.3.3', 'GLIBC_2.3.2', 'GLIBC_2.2.5'}, libdl.so.2 with
versions {'GLIBC_2.2.5'}, libz.so.1 with versions {'ZLIB_1.2.0'}
The following external shared libraries are required by the wheel:
{
"libc.so.6": "/lib/x86_64-linux-gnu/libc-2.24.so",
"libcrypt.so.1": "/lib/x86_64-linux-gnu/libcrypt-2.24.so",
"libdl.so.2": "/lib/x86_64-linux-gnu/libdl-2.24.so",
"libgcc_s.so.1": "/lib/x86_64-linux-gnu/libgcc_s.so.1",
"libm.so.6": "/lib/x86_64-linux-gnu/libm-2.24.so",
"libnsl.so.1": "/lib/x86_64-linux-gnu/libnsl-2.24.so",
"libpthread.so.0": "/lib/x86_64-linux-gnu/libpthread-2.24.so",
"librt.so.1": "/lib/x86_64-linux-gnu/librt-2.24.so",
"libstdc++.so.6": "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22",
"libutil.so.1": "/lib/x86_64-linux-gnu/libutil-2.24.so",
"libz.so.1": "/lib/x86_64-linux-gnu/libz.so.1.2.8"
}
In order to achieve the tag platform tag "manylinux2010_x86_64" the
following shared library dependencies will need to be eliminated:
libz.so.1
In order to achieve the tag platform tag "manylinux1_x86_64" the
following shared library dependencies will need to be eliminated:
libz.so.1

I think there are more todo left with the wheels. IMO the manylinux1 wheels are not compliant because of libz and the manylinux2010 wheels are not compliant because of both libz and liblz4 (but incorrectly reported by auditwheel?).
@kszucs
kszucs
commented
Jul 9, 2019•

edited

Loading

Copy link


Copy Markdown

Member
Perhaps we should use setup.py::move_shared_libs for libz on linux too? cc @xhochy
@wesm
wesm
commented
Jul 9, 2019

Copy link


Copy Markdown

MemberAuthor
Can you open a new JIRA about the libz issue with the information from this issue and we can investigate separately? I'm going to merge this for now.
+1
@wesm
wesm
commented
Jul 9, 2019

Copy link


Copy Markdown

MemberAuthor
Do we know why auditwheel did not raise either the liblz4 or libz issue before?
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
Sure, opening it.
@wesmwesm
closed this
in
7838886Jul 9, 2019
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
No idea, we only run auditwheel repair though.
@wesm
wesm
commented
Jul 9, 2019

Copy link


Copy Markdown

MemberAuthor
I see. We should do something about that then
@wesm
wesm
deleted the

ARROW-5868

branch
July 9, 2019 14:23
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
In case of manylinux2010 the report seems faulty, but adding it to the issue.
@xhochy
xhochy
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
auditwheel repair should package libz.so into the wheel. Only after the repair it should be consistent.
wesm added a commit
that referenced
this pull request
Jul 13, 2019
@wesm
ARROW-5868: [Python] Correctly remove liblz4 shared libraries from ma…
f356184
…nylinux2010 image so lz4 is statically linked
I pushed the image to Docker Hub (it was on quay.io before). I'm not sure what's the best way to test for this -- I checked the produced wheels locally to verify that liblz4.so is no longer required
Author: Wes McKinney <wesm+git@apache.org>
Closes#4828 from wesm/ARROW-5868 and squashes the following commits:
1fb1acb <Wes McKinney> Remove liblz4 shared libraries from /usr/local so static linking occurs
@asfimportasfimport
mentioned this pull request
Aug 1, 2019

Closed

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@wesm@codecov-io@pitrou@kszucs@xhochy

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
ARROW-5868: [Python] Correctly remove liblz4 shared libraries from manylinux2010 image so lz4 is statically linked - #4828
Closed
wesm wants to merge 1 commit into
apache:masterfrom 
wesm:ARROW-5868
Closed
ARROW-5868: [Python] Correctly remove liblz4 shared libraries from manylinux2010 image so lz4 is statically linked#4828
wesm wants to merge 1 commit into
apache:masterfrom 
wesm:ARROW-5868
Conversation
@wesm
@wesmwesm
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
I pushed the image to Docker Hub (it was on quay.io before). I'm not sure what's the best way to test for this -- I checked the produced wheels locally to verify that liblz4.so is no longer required
@codecov-io
codecov-io
commented
Jul 9, 2019

Copy link


Copy Markdown

Codecov Report
Merging #4828 into master will decrease coverage by 22.25%.

The diff coverage is n/a.
Impacted file tree graph
@@ Coverage Diff @@## master #4828 +/- ##
===========================================
- Coverage 87.43% 65.18% -22.26% 
===========================================
Files 997 487 -510 Lines 139804 64296 -75508 Branches 1418 0 -1418 ===========================================
- Hits 122241 41910 -80331 - Misses 17201 22386 +5185 + Partials 362 0 -362
Impacted FilesCoverage Δ
cpp/src/arrow/util/memory.h0% <0%> (-100%)⬇️
cpp/src/gandiva/date_utils.h0% <0%> (-100%)⬇️
cpp/src/arrow/util/memory.cc0% <0%> (-100%)⬇️
cpp/src/arrow/filesystem/util-internal.cc0% <0%> (-100%)⬇️
cpp/src/arrow/util/sse-util.h0% <0%> (-100%)⬇️
cpp/src/gandiva/decimal_type_util.h0% <0%> (-100%)⬇️
cpp/src/arrow/compute/logical_type.h0% <0%> (-100%)⬇️
cpp/src/parquet/hasher.h0% <0%> (-100%)⬇️
cpp/src/gandiva/basic_decimal_scalar.h0% <0%> (-100%)⬇️
cpp/src/arrow/compute/kernels/boolean.cc0% <0%> (-100%)⬇️
... and 748 more
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data

Powered by Codecov. Last update 90affbd...1fb1acb. Read the comment docs.
@pitrou
pitrou
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
Hmm... auditwheel didn't complain? Perhaps worth reporting as a bug?
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
We can add more docker images to test the produced wheels. Have you reproduced the issue?
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
I cannot really find a linux distribution without lz4 preinstalled.
@kszucs
kszucs
commented
Jul 9, 2019•

edited

Loading

Copy link


Copy Markdown

Member
So we statically link liblz4 in the manylinux1 wheels
# ldd pyarrow-manylinux1/libarrow.so.14 | grep z
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc28cef4000)

but dynamically in the manylinux2010 wheels
# ldd pyarrow-manylinux2010/libarrow.so.14 | grep z
liblz4.so.1 => not found (already deleted to reproduce the issue)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f56f7440000)

this what this PR resolves.
What I'm finding strange, that auditwheel seems to bundle libz for manylinux1:
# ls -lah pyarrow-manylinux1/*z*so.*
-rwxr-xr-x 1 root root 115K Jun 29 00:14 pyarrow-manylinux1/libz-7f57503f.so.1.2.11

while ldd still uses the system libz:
# ldd pyarrow-manylinux1/libarrow.so.14 | grep z
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f91fcf3f000)

For manylinux2010 we also have liblz4:
# ls -lah pyarrow-manylinux2010/*z*so.*
-rwxr-xr-x 1 root root 191K Jun 28 23:38 pyarrow-manylinux2010/liblz4-8cb8bdde.so.1.8.3
-rwxr-xr-x 1 root root 115K Jun 28 23:38 pyarrow-manylinux2010/libz-c69b9943.so.1.2.11

and ldd similarly tries to load the system libs:
# ldd pyarrow-manylinux2010/libarrow.so.14 | grep z
liblz4.so.1 => not found
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd72764e000)

Inspecting manylinux1 with LD_DEBUG=files,libs ldd libarrow.so.14 it seems like to search the right path, but cannot find the hashed version of libz libz-7f57503f.so.1.2.11
 463: file=libz.so.1 [0]; needed by ./libarrow.so.14 [0]
463: find library=libz.so.1 [0]; searching
463: search path=/tmp/pyarrow-manylinux1/. (RPATH from file ./libarrow.so.14)
463: trying file=/tmp/pyarrow-manylinux1/./libz.so.1
463: search cache=/etc/ld.so.cache
463: trying file=/lib/x86_64-linux-gnu/libz.so.1

There is no libz.so.1 just libz-7f57503f.so.1.2.11.
Similarly for manylinux2010 and libz:
 470: file=libz.so.1 [0]; needed by ./libarrow.so.14 [0]
470: find library=libz.so.1 [0]; searching
470: search path=/tmp/pyarrow-manylinux2010/. (RPATH from file ./libarrow.so.14)
470: trying file=/tmp/pyarrow-manylinux2010/./libz.so.1
470: search cache=/etc/ld.so.cache
470: trying file=/lib/x86_64-linux-gnu/libz.so.1

for liblz4 (again, I've deleted the system one):
 470: file=liblz4.so.1 [0]; needed by ./libarrow.so.14 [0]
470: find library=liblz4.so.1 [0]; searching
470: search path=/tmp/pyarrow-manylinux2010/. (RPATH from file ./libarrow.so.14)
470: trying file=/tmp/pyarrow-manylinux2010/./liblz4.so.1
470: search cache=/etc/ld.so.cache
470: search path=/lib/x86_64-linux-gnu/tls/x86_64:/lib/x86_64-linux-gnu/tls:/lib/x86_64-linux-gnu/x86_64:/lib/x86_64-linux-gnu:/usr/lib/x86_64-linux-gnu/tls/x86_64:/usr/lib/x86_64-linux-gnu/tls:/usr/lib/x86_64-linux-gnu/x86_6$
:/usr/lib/x86_64-linux-gnu:/lib/tls/x86_64:/lib/tls:/lib/x86_64:/lib:/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/x86_64:/usr/lib (system search path)

There are no libz.so.1 nor liblz4.so.1, just libz-c69b9943.so.1.2.11 and liblz4-8cb8bdde.so.1.8.3
According to https://www.python.org/dev/peps/pep-0571/liblz4 nor libz are part of the whitelist, and while these are bundled with the wheel, seemingly cannot be found - perhaps because of the hash in the library name?
I've tried to inspect the wheels with auditwheel show with version 2 and 1.10, both says the following:
# auditwheel show pyarrow-0.14.0-cp37-cp37m-manylinux2010_x86_64.whl
pyarrow-0.14.0-cp37-cp37m-manylinux2010_x86_64.whl is consistent with
the following platform tag: "linux_x86_64".
The wheel references external versioned symbols in these system-
provided shared libraries: libgcc_s.so.1 with versions {'GCC_3.3',
'GCC_3.4', 'GCC_3.0'}, libpthread.so.0 with versions {'GLIBC_2.3.3',
'GLIBC_2.12', 'GLIBC_2.2.5', 'GLIBC_2.3.2'}, libc.so.6 with versions
{'GLIBC_2.4', 'GLIBC_2.6', 'GLIBC_2.2.5', 'GLIBC_2.7', 'GLIBC_2.3.4',
'GLIBC_2.3.2', 'GLIBC_2.3'}, libstdc++.so.6 with versions
{'CXXABI_1.3', 'GLIBCXX_3.4.10', 'GLIBCXX_3.4.9', 'GLIBCXX_3.4.11',
'GLIBCXX_3.4.5', 'GLIBCXX_3.4', 'CXXABI_1.3.2', 'CXXABI_1.3.3'},
librt.so.1 with versions {'GLIBC_2.2.5'}, libm.so.6 with versions
{'GLIBC_2.2.5'}, libdl.so.2 with versions {'GLIBC_2.2.5'}, libz.so.1
with versions {'ZLIB_1.2.0'}
This constrains the platform tag to "manylinux2010_x86_64". In order
to achieve a more compatible tag, you would need to recompile a new
wheel from source on a system with earlier versions of these
libraries, such as a recent manylinux image.

# auditwheel show pyarrow-0.14.0-cp37-cp37m-manylinux1_x86_64.whl
pyarrow-0.14.0-cp37-cp37m-manylinux1_x86_64.whl is consistent with the
following platform tag: "linux_x86_64".
The wheel references external versioned symbols in these system-
provided shared libraries: libgcc_s.so.1 with versions {'GCC_3.4',
'GCC_3.0', 'GCC_3.3'}, libc.so.6 with versions {'GLIBC_2.3',
'GLIBC_2.2.5', 'GLIBC_2.3.4', 'GLIBC_2.4', 'GLIBC_2.3.2'},
libstdc++.so.6 with versions {'CXXABI_1.3', 'GLIBCXX_3.4.5',
'GLIBCXX_3.4'}, librt.so.1 with versions {'GLIBC_2.2.5'}, libm.so.6
with versions {'GLIBC_2.2.5'}, libpthread.so.0 with versions
{'GLIBC_2.3.3', 'GLIBC_2.3.2', 'GLIBC_2.2.5'}, libdl.so.2 with
versions {'GLIBC_2.2.5'}, libz.so.1 with versions {'ZLIB_1.2.0'}
The following external shared libraries are required by the wheel:
{
"libc.so.6": "/lib/x86_64-linux-gnu/libc-2.24.so",
"libcrypt.so.1": "/lib/x86_64-linux-gnu/libcrypt-2.24.so",
"libdl.so.2": "/lib/x86_64-linux-gnu/libdl-2.24.so",
"libgcc_s.so.1": "/lib/x86_64-linux-gnu/libgcc_s.so.1",
"libm.so.6": "/lib/x86_64-linux-gnu/libm-2.24.so",
"libnsl.so.1": "/lib/x86_64-linux-gnu/libnsl-2.24.so",
"libpthread.so.0": "/lib/x86_64-linux-gnu/libpthread-2.24.so",
"librt.so.1": "/lib/x86_64-linux-gnu/librt-2.24.so",
"libstdc++.so.6": "/usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.22",
"libutil.so.1": "/lib/x86_64-linux-gnu/libutil-2.24.so",
"libz.so.1": "/lib/x86_64-linux-gnu/libz.so.1.2.8"
}
In order to achieve the tag platform tag "manylinux2010_x86_64" the
following shared library dependencies will need to be eliminated:
libz.so.1
In order to achieve the tag platform tag "manylinux1_x86_64" the
following shared library dependencies will need to be eliminated:
libz.so.1

I think there are more todo left with the wheels. IMO the manylinux1 wheels are not compliant because of libz and the manylinux2010 wheels are not compliant because of both libz and liblz4 (but incorrectly reported by auditwheel?).
@kszucs
kszucs
commented
Jul 9, 2019•

edited

Loading

Copy link


Copy Markdown

Member
Perhaps we should use setup.py::move_shared_libs for libz on linux too? cc @xhochy
@wesm
wesm
commented
Jul 9, 2019

Copy link


Copy Markdown

MemberAuthor
Can you open a new JIRA about the libz issue with the information from this issue and we can investigate separately? I'm going to merge this for now.
+1
@wesm
wesm
commented
Jul 9, 2019

Copy link


Copy Markdown

MemberAuthor
Do we know why auditwheel did not raise either the liblz4 or libz issue before?
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
Sure, opening it.
@wesmwesm
closed this
in
7838886Jul 9, 2019
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
No idea, we only run auditwheel repair though.
@wesm
wesm
commented
Jul 9, 2019

Copy link


Copy Markdown

MemberAuthor
I see. We should do something about that then
@wesm
wesm
deleted the

ARROW-5868

branch
July 9, 2019 14:23
@kszucs
kszucs
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
In case of manylinux2010 the report seems faulty, but adding it to the issue.
@xhochy
xhochy
commented
Jul 9, 2019

Copy link


Copy Markdown

Member
auditwheel repair should package libz.so into the wheel. Only after the repair it should be consistent.
wesm added a commit
that referenced
this pull request
Jul 13, 2019
@wesm
ARROW-5868: [Python] Correctly remove liblz4 shared libraries from ma…
f356184
…nylinux2010 image so lz4 is statically linked
I pushed the image to Docker Hub (it was on quay.io before). I'm not sure what's the best way to test for this -- I checked the produced wheels locally to verify that liblz4.so is no longer required
Author: Wes McKinney <wesm+git@apache.org>
Closes#4828 from wesm/ARROW-5868 and squashes the following commits:
1fb1acb <Wes McKinney> Remove liblz4 shared libraries from /usr/local so static linking occurs
@asfimportasfimport
mentioned this pull request
Aug 1, 2019

Closed

Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment

Reviewers


No reviews


Assignees


No one assigned


Labels


None yet


Projects


None yet


Milestone


No milestone


Development

Successfully merging this pull request may close these issues.

5 participants

@wesm@codecov-io@pitrou@kszucs@xhochy