强制 conda 安装的可执行文件在 运行 时间使用 conda 共享库
Force conda-installed executable to use the conda shared libraries at run time
我想使用 conda
使 C++ 程序的编译和分发变得可移植和简单,所以我编写了一个 conda 配方。构建依赖于一些库来处理图像 I/O,例如 libpng
和 libtiff
。这些库的 conda
版本在 the recipe 中指定,摘录如下:
requirements:
run_exports:
strong:
- libpng
- libtiff
- jpeg
- fftw
- eigen
host:
- {{ compiler('cxx') }}
- cmake
- python
- libpng
- libtiff
- jpeg
- fftw
- eigen
run:
- libtiff
- libpng
- jpeg
- fftw
我的理解是host
对应编译时使用的conda库,而run
和run_exports
指定运行时机器上的库主机或其他机器。
在 OS X 上,cmake 编译 运行 正常,特别是针对图像库的 conda 版本成功编译。 conda build .
操作中的安装摘录如下所示:
-- The C compiler identification is Clang 12.0.1
-- The CXX compiler identification is Clang 12.0.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: $PREFIX/bin/x86_64-apple-darwin13.4.0-clang - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: $PREFIX/bin/x86_64-apple-darwin13.4.0-clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found OpenMP_C: -fopenmp=libomp (found version "5.0")
-- Found OpenMP_CXX: -fopenmp=libomp (found version "5.0")
-- Found OpenMP: TRUE (found version "5.0")
-- Found TIFF: $PREFIX/lib/libtiff.dylib (found version "4.0.9")
-- Found JPEG: $PREFIX/lib/libjpeg.dylib (found version "80")
-- Found ZLIB: $PREFIX/lib/libz.dylib (found version "1.2.11")
-- Found PNG: $PREFIX/lib/libpng.dylib (found version "1.4.12")
-- Configuring done
-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:
CMAKE_INSTALL_LIBDIR
CMAKE_LIBTOOL
-- Build files have been written to: $SRC_DIR/build
Scanning dependencies of target bm3d
[ 16%] Building CXX object CMakeFiles/bm3d.dir/bm3d.cpp.o
[ 33%] Building C object CMakeFiles/bm3d.dir/iio.c.o
[ 50%] Building CXX object CMakeFiles/bm3d.dir/lib_transforms.cpp.o
[ 66%] Building CXX object CMakeFiles/bm3d.dir/main.cpp.o
[ 83%] Building CXX object CMakeFiles/bm3d.dir/utilities.cpp.o
[100%] Linking CXX executable bm3d
[100%] Built target bm3d
Consolidate compiler generated dependencies of target bm3d
[100%] Built target bm3d
Install the project...
-- Install configuration: "Release"
-- Installing: $PREFIX/bin/bm3d
在 conda 构建过程结束时,我将包上传到 anaconda
商店,并安装它 (conda install -c efmkoene bm3d
)。但是经过测试,事实证明可执行文件正在为图像 I/O 使用一组不同的库——在我的例子中造成了麻烦。程序 运行 针对图像(例如 bm3d ~/Downloads/example.png 10 out.png
)的示例给出
libpng warning: Application built with libpng-1.4.12 but running with 1.6.37
ERROR(""): png_create_read_struct fail
因此请注意 运行 时间的 libpng
(在本例中,brew install libpng
的结果)与用于编译的结果不同,即使我与用于编译的环境处于相同的 运行 时间环境中。这个问题有解决办法吗?
供将来参考,错误确实在 cmake
过程中检测到关于 libpng
的错误信息。在 CMakeLists.txt
中添加 set(CMAKE_FIND_FRAMEWORK LAST)
解决了问题!据 Kikaxa 在 OSX + homebrew + CMake + libpng version mismatch issue 报道:
The problem is that classical cmake-style Find*.cmake search for the
headers and libraries separately - and the results MAY and WILL
mismatch in some cases. MacOS exaggerates the problem by having
special case of frameworks, being searched BEFORE other locations by
default.
我想使用 conda
使 C++ 程序的编译和分发变得可移植和简单,所以我编写了一个 conda 配方。构建依赖于一些库来处理图像 I/O,例如 libpng
和 libtiff
。这些库的 conda
版本在 the recipe 中指定,摘录如下:
requirements:
run_exports:
strong:
- libpng
- libtiff
- jpeg
- fftw
- eigen
host:
- {{ compiler('cxx') }}
- cmake
- python
- libpng
- libtiff
- jpeg
- fftw
- eigen
run:
- libtiff
- libpng
- jpeg
- fftw
我的理解是host
对应编译时使用的conda库,而run
和run_exports
指定运行时机器上的库主机或其他机器。
在 OS X 上,cmake 编译 运行 正常,特别是针对图像库的 conda 版本成功编译。 conda build .
操作中的安装摘录如下所示:
-- The C compiler identification is Clang 12.0.1
-- The CXX compiler identification is Clang 12.0.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: $PREFIX/bin/x86_64-apple-darwin13.4.0-clang - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: $PREFIX/bin/x86_64-apple-darwin13.4.0-clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found OpenMP_C: -fopenmp=libomp (found version "5.0")
-- Found OpenMP_CXX: -fopenmp=libomp (found version "5.0")
-- Found OpenMP: TRUE (found version "5.0")
-- Found TIFF: $PREFIX/lib/libtiff.dylib (found version "4.0.9")
-- Found JPEG: $PREFIX/lib/libjpeg.dylib (found version "80")
-- Found ZLIB: $PREFIX/lib/libz.dylib (found version "1.2.11")
-- Found PNG: $PREFIX/lib/libpng.dylib (found version "1.4.12")
-- Configuring done
-- Generating done
CMake Warning:
Manually-specified variables were not used by the project:
CMAKE_INSTALL_LIBDIR
CMAKE_LIBTOOL
-- Build files have been written to: $SRC_DIR/build
Scanning dependencies of target bm3d
[ 16%] Building CXX object CMakeFiles/bm3d.dir/bm3d.cpp.o
[ 33%] Building C object CMakeFiles/bm3d.dir/iio.c.o
[ 50%] Building CXX object CMakeFiles/bm3d.dir/lib_transforms.cpp.o
[ 66%] Building CXX object CMakeFiles/bm3d.dir/main.cpp.o
[ 83%] Building CXX object CMakeFiles/bm3d.dir/utilities.cpp.o
[100%] Linking CXX executable bm3d
[100%] Built target bm3d
Consolidate compiler generated dependencies of target bm3d
[100%] Built target bm3d
Install the project...
-- Install configuration: "Release"
-- Installing: $PREFIX/bin/bm3d
在 conda 构建过程结束时,我将包上传到 anaconda
商店,并安装它 (conda install -c efmkoene bm3d
)。但是经过测试,事实证明可执行文件正在为图像 I/O 使用一组不同的库——在我的例子中造成了麻烦。程序 运行 针对图像(例如 bm3d ~/Downloads/example.png 10 out.png
)的示例给出
libpng warning: Application built with libpng-1.4.12 but running with 1.6.37
ERROR(""): png_create_read_struct fail
因此请注意 运行 时间的 libpng
(在本例中,brew install libpng
的结果)与用于编译的结果不同,即使我与用于编译的环境处于相同的 运行 时间环境中。这个问题有解决办法吗?
供将来参考,错误确实在 cmake
过程中检测到关于 libpng
的错误信息。在 CMakeLists.txt
中添加 set(CMAKE_FIND_FRAMEWORK LAST)
解决了问题!据 Kikaxa 在 OSX + homebrew + CMake + libpng version mismatch issue 报道:
The problem is that classical cmake-style Find*.cmake search for the headers and libraries separately - and the results MAY and WILL mismatch in some cases. MacOS exaggerates the problem by having special case of frameworks, being searched BEFORE other locations by default.