自己的解决办法：
我的报错是lib中缺少.so.56，于是我从
https://anaconda.org/conda-forge/icu/files
里面下载了放到lib中，python就能正常import cv2了。
再放上比较靠谱的其他人的办法：
https://github.com/conda-forge/geopandas-feedstock/issues/21
It looks like you have the usual "multiple channes" problem. Please take a look at http://conda-forge.github.io/docs/conda-forge_gotchas.html#using-multiple-channels and let us know if that fixes it for you. (Closing this for now but feel free to ask further questions here in case you are in doubt.)
https://conda-forge.org/docs/conda-forge_gotchas.html#using-multiple-channels
Using multiple channels
It is quite common to install a package from conda-forge and,when trying to use it,see an error like (OS X example):
ImportError: dlopen(.../site-packages/rpy2/rinterface/_rinterface.so, 2): Library not loaded: @rpath/libicuuc.54.dylibReferenced from: .../site-packages/rpy2/rinterface/_rinterface.soReason: image not found
That happens because either the correct version of icu,or any other package in the error,is not present or the package is missing altogether.
Once can confirm by issuing the command conda list and searching for the package in question.
Why that happens?
The conda-forge and defaults are not 100% compatible.In the example above it is known that defaults uses icu 54.* while conda-forge relies on icu 56.*,that mismatch can lead to errors when the install environment is mixing packages from multiple channels.
Note: All of conda-forge software pinning can be found at: https://github.com/conda-forge/staged-recipes/wiki/Pinned-dependencies
How to fix it?
Newer conda versions introduced a channel priority feature.See https://conda.io/docs/channels.html for more information.
One possible solution is to add the conda-forge channel on top of defaults in your condarc file when using conda-forge packages.This will ensuring that all the dependencies will come from the conda-forge channel.Here is how a .condarc file would look like:
$ cat .condarc
channels:- conda-forge- defaults
In addition to the channel priority we recommend to always install your packages inside a new environment instead the root environment from anaconda/miniconda.Using envs make it easier to debug problems with packages and ensure the stability of your root env.
Managing channels
Different channels can have the same package, so conda must handle thesechannel collisions.
There will be no channel collisions if you use only the defaults channel.There will also be no channel collisions if all of the channels you use onlycontain packages that do not exist in any of the other channels in your list.The way conda resolves these collisions matters only when you have multiplechannels in your channel list that host the same package.
Before conda 4.1.0
Before conda 4.1.0 was released on June 14, 2016, when two channelshosted packages with the same name, conda installed the packagewith the highest version number. If there were two packageswith the same version number, conda installed the one with thehighest build number. Only if both the version numbers and buildnumbers were identical did the channel ordering make adifference. This approach had 3 problems:
- Build numbers from different channels are not comparable.Channel A could do nightly builds while Channel B does weeklybuilds, so build 2 from Channel B could be newer than build 4from Channel A.
- Users could not specify a preferred channel. You might considerChannel B more reliable than Channel A and prefer to getpackages from that channel even if the B version is older thanthe package in Channel A. Conda provided no way to choose thatbehavior. Only version and build numbers mattered.
- Build numbers conflicted. This is an effect of the other 2problems. Assume you were happily using package Alpha fromChannel A and package Bravo from Channel B. The provider fromChannel B then added a version of Alpha with a very high buildnumber. Your conda updates would start installing new versionsof Alpha from Channel B whether you wanted that or not. Thiscould cause unintentional problems and a risk of deliberateattacks.
After conda 4.1.0
By default, conda now prefers packages from a higher prioritychannel over any version from a lower priority channel.Therefore, you can now safely put channels at the bottom of yourchannel list to provide additional packages that are not in thedefault channels, and still be confident that these channels willnot override the core package set.
Conda collects all of the packages with the same name across alllisted channels and processes them as follows:
- Sorts packages from highest to lowest channel priority.
- Sorts tied packages—same channel priority—from highest tolowest version number.
- Sorts still-tied packages—same channel priority and sameversion—from highest to lowest build number.
- Installs the first package on the sorted list that satisfiesthe installation specifications.
To make conda use the old method and install the newest versionof a package in any listed channel:
-
Add
channel_priority: falseto your.condarcfile.OR
-
Run the equivalent command:
conda config --set channel_priority false
Conda then sorts as follows:
- Sorts the package list from highest to lowest version number.
- Sorts tied packages from highest to lowest channel priority.
- Sorts tied packages from highest to lowest build number.
Because build numbers from different channels are notcomparable, build number still comes after channel priority.
The following command adds the channel “new_channel” to the topof the channel list, making it the highest priority:
conda config --add channels new_channel
Conda now has an equivalent command:
conda config --prepend channels new_channel
Conda also now has a command that adds the new channel to thebottom of the channel list, making it the lowest priority:
conda config --append channels new_channel
另外icu的开源库在：
https://github.com/conda-forge/icu-feedstock
