snappy-1.2.0 provides libsnappy.so.1.1.10 with different function signatures.

[chebee7i]

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

Is it expected that snappy-1.2.0 would be based on libsnappy.so.1.1.10? Wondering if it is an error that it is named libsnappy.so.1.10 instead of libsnappy.so.1.2.0.

What seems problematic is that it is not really the same underlying version of libsnappy.so.

When I look at libsnappy.so.1.1.10 from snappy-1.2.0, I see:

$ nm -s libsnappy.so.1.1.10 | c++filt | grep RawCompress
00000000000065d0 T snappy::RawCompress(char const*, unsigned long, char*, unsigned long*, snappy::CompressionOptions)
0000000000006680 T snappy::RawCompressFromIOVec(iovec const*, unsigned long, char*, unsigned long*, snappy::CompressionOptions)

When I look at libsnappy.so.1.1.10 from snappy-1.1.10, I see:

$ nm -s libsnappy.so.1.1.10 | c++filt | grep RawCompress
00000000000049b0 T snappy::RawCompress(char const*, unsigned long, char*, unsigned long*)
0000000000004a50 T snappy::RawCompressFromIOVec(iovec const*, unsigned long, char*, unsigned long*)

Anything expecting the latter will fail a symbol lookup with the newer version.

Installed packages

N/A

Environment info

N/A

[chebee7i]

https://conda-metadata-app.streamlit.app/?q=conda-forge%2Flinux-64%2Fsnappy-1.1.10-h9fff704_0.conda
https://conda-metadata-app.streamlit.app/?q=conda-forge%2Flinux-64%2Fsnappy-1.2.0-hdb0a2a9_0.conda

[lidavidm]

I am seeing this too. I suppose we should request for the packages to be marked broken? https://conda-forge.org/docs/maintainer/updating_pkgs/#maint-fix-broken-packages

[erykoff]

This completely breaks pyarrow, leading to segfaults.

[erykoff]

cc @xhochy who merged #34. I'm guessing something in the patches rebase went wrong.

[btschroer]

I am too observing an ImportError with Symbol not found: __ZN6snappy11RawCompress... when importing pyarrow. I also believe that the snappy-1.2.0 package should be marked as broken.

[jjerphan]

#36 has been opened to fix the runtime requirements accordingly.

[jorisvandenbossche]

I just opened conda-forge/admin-requests#973 to mark it as broken. Should that still happen if updating the runtime requirements in #36? (I would think so given that results in new builds, and the packages with build 0 would still give the problems described here?)

[jjerphan]

If #36 is merged, a repodata patch also has to be added for the already-published builds of snappy-dependent projects to depend on snappy <1.2.0.

[xhochy]

The package has been marked as broken. I think the next steps are:

1. Rebuild 1.1.10 with a x.x run_exports
2. Adjust conda-forge-pinning
3. Understand why the library is still called libsnappy.so.1.1.10
4. Build 1.2 with the same run_exports
5. Start a migration for the new snappy.

[jjerphan]

conda-forge/conda-forge-repodata-patches-feedstock#699 is ready for review.

[jjerphan]

3. Understand why the library is still called libsnappy.so.1.1.10

google/snappy#178 fixes it.

[xhochy]

google/snappy@766d24c broke the ABI

[xhochy]

#37 and conda-forge/conda-forge-pinning-feedstock#5730 fixe further things.

[jorisvandenbossche]

Should those PRs in this repo have already been merged? Because that now again results in the original issue, i.e. creating a fresh environment installs pyarrow with snappy which then gives an ImportError (because the new build 1 for snappy 1.2.0 is not marked as broken)

[jorisvandenbossche]

Or does it take a while before the repodata-patches are propagated?

[xhochy]

The initial repodata patch was faulty but should be fixed since 30min but probably not yet fully migrated through the CDN.

[xhochy]

Everything seems fine now.

[asvishnyakov]

Looks like issue is still isn't resolved and Google released 1.2.1: https://github.com/google/snappy/releases/tag/1.2.1 Can someone update package for conda too, please?