Issues trying to use the Anaconda compiler tools with CMake

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Issues trying to use the Anaconda compiler tools with CMake

Sebastián Mancilla
I am trying to use Conda as a package manager for isolated C++ development
environments. But unfortunately, when using CMake with the Anaconda-provided
compilers [1] (which are used to compile the binary packages in the Anaconda
repositories), things do not work as expected.

I have a small test case available here [2], with an executable calling a
shared library and a third-party dependency installed with Conda.


--------------------------------------------------

First, when using the system compiler, all works fine (but I am not sure of the
binary compatibility with the Conda packages, that's why I want to use the
Anaconda compilers):

    # create the environment and install XercesC
    $ conda create -n test-system xerces-c
    ...
    environment location: /Users/smancill/.local/share/miniconda3/envs/test-system
    ...
    The following NEW packages will be INSTALLED:

    icu:       58.2-h4b95b61_1
    libcxx:    4.0.1-h579ed51_0
    libcxxabi: 4.0.1-hebd6815_0
    xerces-c:  3.2.1-h44e365a_0
    ...

    # activate the environment
    $ conda activate test-system

    $ mkdir build-osx-system
    $ cd build-osx-system
    $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
    -- The CXX compiler identification is AppleClang 9.0.0.9000039
    -- Check for working CXX compiler: /usr/bin/c++
    -- Check for working CXX compiler: /usr/bin/c++ -- works
    ...
    -- Found XercesC: /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib (found version "3.2.1")
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /Users/smancill/src/conda-test/build-osx-system

    $ make -j1 VERBOSE=1
    ...
    [100%] Linking CXX executable bar
    /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
    /usr/bin/c++   -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -mmacosx-version-min=10.12 -Wl,-search_paths_first -Wl,-headerpad_max_install_names  CMakeFiles/bar.dir/bar.cpp.o  -o bar -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-system -Wl,-rpath,/Users/smancill/.local/share/miniconda3/envs/test-system/lib libfoo.dylib /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
    ...

The build directory (~/src/conda-test/build-osx-system) and the conda
environment lib directory (~/.local/share/miniconda3/envs/test-system/lib)
are correctly added to the RPATH in the build tree by the link command:

    $ ./bar
    Hello, world!

    $ otool -L ./bar
    ./bar:
        @rpath/libfoo.dylib (compatibility version 1.0.0, current version 0.0.0)
        @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)

    $ otool -l ./bar | grep -A2 LC_RPATH
            cmd LC_RPATH
        cmdsize 56
            path /Users/smancill/src/conda-test/build-osx-system (offset 12)
    --
            cmd LC_RPATH
        cmdsize 80
            path /Users/smancill/.local/share/miniconda3/envs/test-system/lib (offset 12)

If I install the binary, it fails because I haven't configured CMake to set the install RPATH:

    $ make install
    ...
    Install the project...
    -- Install configuration: ""
    -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libfoo.dylib
    -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/include/foo.hpp
    -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar

    $ bar
    dyld: Library not loaded: @rpath/libfoo.dylib
      Referenced from: /Users/smancill/.local/share/miniconda4/envs/test-system/bin/bar
      Reason: image not found
    [1]    84611 abort      bar

    $ otool -L $CONDA_PREFIX/bin/bar
    /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar:
        @rpath/libfoo.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)

    $ otool -l $CONDA_PREFIX/bin/bar | grep -A2 LC_RPATH
    # empty

    # deactivate the environment to start again
    $ conda deactivate

The same can be observed on Linux. Everything works as it should.

--------------------------------------------------

If I try to use Anaconda compilers on macOS, the build RPATH is not set
properly anymore:

    # create the environment and install the Anaconda compiler for macOS, and XercesC
    $ conda create -n test-conda clangxx_osx-64 xerces-c
    ...
    environment location: /Users/smancill/.local/share/miniconda3/envs/test-conda
    ...
    The following NEW packages will be INSTALLED:

        cctools:        895-h7512d6f_0
        clang:          4.0.1-h662ec87_0
        clang_osx-64:   4.0.1-h1ce6c1d_11
        clangxx:        4.0.1-hc9b4283_0
        clangxx_osx-64: 4.0.1-h22b1bf0_11
        compiler-rt:    4.0.1-h5487866_0
        icu:            58.2-h4b95b61_1
        ld64:           274.2-h7c2db76_0
        libcxx:         4.0.1-h579ed51_0
        libcxxabi:      4.0.1-hebd6815_0
        llvm:           4.0.1-hc748206_0
        llvm-lto-tapi:  4.0.1-h6701bc3_0
        xerces-c:       3.2.1-h44e365a_0
    ...

    # activate the environment (which sets the variables to use the Anaconda compiler)
    $ conda activate test-conda

    $ mkdir build-osx-conda
    $ cd build-osx-conda
    $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
    -- The CXX compiler identification is Clang 4.0.1
    -- Check for working CXX compiler: /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
    -- Check for working CXX compiler: /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++ -- works
    ...
    -- Found XercesC: /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib (found version "3.2.1")
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /Users/smancill/src/conda-test/build-osx-conda

    $ make -j1 VERBOSE=1
    ...
    [100%] Linking CXX executable bar
    /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
    /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++  -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O2 -pipe -stdlib=libc++ -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -mmacosx-version-min=10.12 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -Wl,-pie -Wl,-headerpad_max_install_names -Wl,-dead_strip_dylibs CMakeFiles/bar.dir/bar.cpp.o  -o bar -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-conda libfoo.dylib /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
    ...

You can see that the environment lib path is not added to the RPATH by the link command,
which in turns result in the executable not running from the build tree anymore:

    $ ./bar
    dyld: Library not loaded: @rpath/libxerces-c-3.2.dylib
      Referenced from: /Users/smancill/src/conda-test/build-osx-conda/./bar
      Reason: image not found
    [1]    89350 abort      ./bar

    $ otool -L ./bar
    ./bar:
        @rpath/libfoo.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)

    $ otool -l ./bar | grep -A2 LC_RPATH
          cmd LC_RPATH
      cmdsize 56
         path /Users/smancill/src/conda-test/build-osx-conda (offset 12)

    # deactivate the environment
    $ conda deactivate

--------------------------------------------------

If I try the Anaconda compilers on Linux, there are strange results too:

    # create the environment and install the Anaconda compiler for Linux, and XercesC
    $ conda create -n test-conda gxx_linux-64 xerces-c
    ...
    environment location: /home/vagrant/miniconda3/envs/test-conda
    ...
    The following NEW packages will be INSTALLED:

        binutils_impl_linux-64: 2.28.1-had2808c_3
        binutils_linux-64:      7.2.0-had2808c_27
        gcc_impl_linux-64:      7.2.0-habb00fd_3
        gcc_linux-64:           7.2.0-h550dcbe_27
        gxx_impl_linux-64:      7.2.0-hdf63c60_3
        gxx_linux-64:           7.2.0-h550dcbe_27
        icu:                    58.2-h9c2bf20_1
        libgcc-ng:              7.2.0-hdf63c60_3
        libstdcxx-ng:           7.2.0-hdf63c60_3
        xerces-c:               3.2.1-hac72e42_0

    # activate the environment (which sets the variables to use the Anaconda compiler)
    $ conda activate test-conda

    $ mkdir build-linux-conda
    $ cd build-linux-conda
    $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
    -- The CXX compiler identification is GNU 7.2.0
    -- Check for working CXX compiler: /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
    -- Check for working CXX compiler: /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++ -- works
    ...
    -- Found XercesC: /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so (found version "3.2.1")
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /vagrant/conda-test/build-linux-conda

    $ make -j1 VERBOSE=1
    ...
    [100%] Linking CXX executable bar
    /usr/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
    /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++   -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe    -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now CMakeFiles/bar.dir/bar.cpp.o  -o bar libfoo.so /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so -Wl,-rpath,/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:
    ...

You can see that the environment lib path is added to the RPATH by the link
command (unlike macOS):

    $ ./bar
    Hello World!

But when inspecting the dependencies, the environment lib path appears twice:

    $ readelf -d ./bar
    ...
     0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
     0x0000000000000001 (NEEDED)             Shared library: [libxerces-c-3.2.so]
     0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
     0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
     0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
     0x000000000000000f (RPATH)              Library rpath: [/home/vagrant/miniconda3/envs/test-conda/lib:/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:]
    ...

Which is wrong. Now the build tree binary will pick first any old version of
the foo library installed in the environment instead of the version in the
build tree.

It seems that the Anaconda toolchain is setting the environment lib path into
the RPATH by its own. It is also set when installing the binaries, even when
CMake is not configured to set the install RPATH:

    $ make install
    ...
    Install the project...
    -- Install configuration: ""
    -- Installing: /home/vagrant/miniconda3/envs/test-conda/lib/libfoo.so
    -- Installing: /home/vagrant/miniconda3/envs/test-conda/include/foo.hpp
    -- Installing: /home/vagrant/miniconda3/envs/test-conda/bin/bar
    -- Set runtime path of "/home/vagrant/miniconda3/envs/test-conda/bin/bar" to ""

    $ bar
    Hello World!

    $ readelf -d $CONDA_PREFIX/bin/bar
    ...
     0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
     0x0000000000000001 (NEEDED)             Shared library: [libxerces-c-3.2.so]
     0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
     0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
     0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
     0x000000000000000f (RPATH)              Library rpath: [/home/vagrant/miniconda3/envs/test-conda/lib]
    ...

    # deactivate the environment
    $ conda deactivate

--------------------------------------------------

TL;DR I cannot get CMake and the Anaconda compilers and packages working
correctly.

- On macOS, the Conda environment library path is not added to the build RPATH.
- On Linux, the Conda environment library path is always added to the RPATH
  (in both build and install) independently of CMake.

Any advice or workarounds?

--
Sebastian Mancilla

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Issues trying to use the Anaconda compiler tools with CMake

Isaiah Norton
The RPATH is not included when using Anaconda because CMake considers the Anaconda lib path to be an implicit link directory (as reported by the compiler). Look at `$build_dir/CMakeFiles/CMakeOutput.log` in the section about "implicit link info".

The simplest work-around is to set BUILD_RPATH manually, and possibly also INSTALL_RPATH, depending on what conda-build's fixup routine expects.

For example, adding this line near the top of your example CMakeList fixed the resulting binary, at least in the build directory:

set(CMAKE_BUILD_RPATH "$ENV{CONDA_PREFIX}/lib")

On Fri, Aug 10, 2018 at 5:55 PM Sebastián Mancilla <[hidden email]> wrote:
I am trying to use Conda as a package manager for isolated C++ development
environments. But unfortunately, when using CMake with the Anaconda-provided
compilers [1] (which are used to compile the binary packages in the Anaconda
repositories), things do not work as expected.

I have a small test case available here [2], with an executable calling a
shared library and a third-party dependency installed with Conda.


--------------------------------------------------

First, when using the system compiler, all works fine (but I am not sure of the
binary compatibility with the Conda packages, that's why I want to use the
Anaconda compilers):

    # create the environment and install XercesC
    $ conda create -n test-system xerces-c
    ...
    environment location: /Users/smancill/.local/share/miniconda3/envs/test-system
    ...
    The following NEW packages will be INSTALLED:

    icu:       58.2-h4b95b61_1
    libcxx:    4.0.1-h579ed51_0
    libcxxabi: 4.0.1-hebd6815_0
    xerces-c:  3.2.1-h44e365a_0
    ...

    # activate the environment
    $ conda activate test-system

    $ mkdir build-osx-system
    $ cd build-osx-system
    $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
    -- The CXX compiler identification is AppleClang 9.0.0.9000039
    -- Check for working CXX compiler: /usr/bin/c++
    -- Check for working CXX compiler: /usr/bin/c++ -- works
    ...
    -- Found XercesC: /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib (found version "3.2.1")
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /Users/smancill/src/conda-test/build-osx-system

    $ make -j1 VERBOSE=1
    ...
    [100%] Linking CXX executable bar
    /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
    /usr/bin/c++   -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -mmacosx-version-min=10.12 -Wl,-search_paths_first -Wl,-headerpad_max_install_names  CMakeFiles/bar.dir/bar.cpp.o  -o bar -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-system -Wl,-rpath,/Users/smancill/.local/share/miniconda3/envs/test-system/lib libfoo.dylib /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
    ...

The build directory (~/src/conda-test/build-osx-system) and the conda
environment lib directory (~/.local/share/miniconda3/envs/test-system/lib)
are correctly added to the RPATH in the build tree by the link command:

    $ ./bar
    Hello, world!

    $ otool -L ./bar
    ./bar:
        @rpath/libfoo.dylib (compatibility version 1.0.0, current version 0.0.0)
        @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)

    $ otool -l ./bar | grep -A2 LC_RPATH
            cmd LC_RPATH
        cmdsize 56
            path /Users/smancill/src/conda-test/build-osx-system (offset 12)
    --
            cmd LC_RPATH
        cmdsize 80
            path /Users/smancill/.local/share/miniconda3/envs/test-system/lib (offset 12)

If I install the binary, it fails because I haven't configured CMake to set the install RPATH:

    $ make install
    ...
    Install the project...
    -- Install configuration: ""
    -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libfoo.dylib
    -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/include/foo.hpp
    -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar

    $ bar
    dyld: Library not loaded: @rpath/libfoo.dylib
      Referenced from: /Users/smancill/.local/share/miniconda4/envs/test-system/bin/bar
      Reason: image not found
    [1]    84611 abort      bar

    $ otool -L $CONDA_PREFIX/bin/bar
    /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar:
        @rpath/libfoo.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)

    $ otool -l $CONDA_PREFIX/bin/bar | grep -A2 LC_RPATH
    # empty

    # deactivate the environment to start again
    $ conda deactivate

The same can be observed on Linux. Everything works as it should.

--------------------------------------------------

If I try to use Anaconda compilers on macOS, the build RPATH is not set
properly anymore:

    # create the environment and install the Anaconda compiler for macOS, and XercesC
    $ conda create -n test-conda clangxx_osx-64 xerces-c
    ...
    environment location: /Users/smancill/.local/share/miniconda3/envs/test-conda
    ...
    The following NEW packages will be INSTALLED:

        cctools:        895-h7512d6f_0
        clang:          4.0.1-h662ec87_0
        clang_osx-64:   4.0.1-h1ce6c1d_11
        clangxx:        4.0.1-hc9b4283_0
        clangxx_osx-64: 4.0.1-h22b1bf0_11
        compiler-rt:    4.0.1-h5487866_0
        icu:            58.2-h4b95b61_1
        ld64:           274.2-h7c2db76_0
        libcxx:         4.0.1-h579ed51_0
        libcxxabi:      4.0.1-hebd6815_0
        llvm:           4.0.1-hc748206_0
        llvm-lto-tapi:  4.0.1-h6701bc3_0
        xerces-c:       3.2.1-h44e365a_0
    ...

    # activate the environment (which sets the variables to use the Anaconda compiler)
    $ conda activate test-conda

    $ mkdir build-osx-conda
    $ cd build-osx-conda
    $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
    -- The CXX compiler identification is Clang 4.0.1
    -- Check for working CXX compiler: /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
    -- Check for working CXX compiler: /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++ -- works
    ...
    -- Found XercesC: /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib (found version "3.2.1")
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /Users/smancill/src/conda-test/build-osx-conda

    $ make -j1 VERBOSE=1
    ...
    [100%] Linking CXX executable bar
    /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
    /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++  -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O2 -pipe -stdlib=libc++ -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -mmacosx-version-min=10.12 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -Wl,-pie -Wl,-headerpad_max_install_names -Wl,-dead_strip_dylibs CMakeFiles/bar.dir/bar.cpp.o  -o bar -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-conda libfoo.dylib /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
    ...

You can see that the environment lib path is not added to the RPATH by the link command,
which in turns result in the executable not running from the build tree anymore:

    $ ./bar
    dyld: Library not loaded: @rpath/libxerces-c-3.2.dylib
      Referenced from: /Users/smancill/src/conda-test/build-osx-conda/./bar
      Reason: image not found
    [1]    89350 abort      ./bar

    $ otool -L ./bar
    ./bar:
        @rpath/libfoo.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)

    $ otool -l ./bar | grep -A2 LC_RPATH
          cmd LC_RPATH
      cmdsize 56
         path /Users/smancill/src/conda-test/build-osx-conda (offset 12)

    # deactivate the environment
    $ conda deactivate

--------------------------------------------------

If I try the Anaconda compilers on Linux, there are strange results too:

    # create the environment and install the Anaconda compiler for Linux, and XercesC
    $ conda create -n test-conda gxx_linux-64 xerces-c
    ...
    environment location: /home/vagrant/miniconda3/envs/test-conda
    ...
    The following NEW packages will be INSTALLED:

        binutils_impl_linux-64: 2.28.1-had2808c_3
        binutils_linux-64:      7.2.0-had2808c_27
        gcc_impl_linux-64:      7.2.0-habb00fd_3
        gcc_linux-64:           7.2.0-h550dcbe_27
        gxx_impl_linux-64:      7.2.0-hdf63c60_3
        gxx_linux-64:           7.2.0-h550dcbe_27
        icu:                    58.2-h9c2bf20_1
        libgcc-ng:              7.2.0-hdf63c60_3
        libstdcxx-ng:           7.2.0-hdf63c60_3
        xerces-c:               3.2.1-hac72e42_0

    # activate the environment (which sets the variables to use the Anaconda compiler)
    $ conda activate test-conda

    $ mkdir build-linux-conda
    $ cd build-linux-conda
    $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
    -- The CXX compiler identification is GNU 7.2.0
    -- Check for working CXX compiler: /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
    -- Check for working CXX compiler: /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++ -- works
    ...
    -- Found XercesC: /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so (found version "3.2.1")
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /vagrant/conda-test/build-linux-conda

    $ make -j1 VERBOSE=1
    ...
    [100%] Linking CXX executable bar
    /usr/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
    /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++   -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe    -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now CMakeFiles/bar.dir/bar.cpp.o  -o bar libfoo.so /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so -Wl,-rpath,/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:
    ...

You can see that the environment lib path is added to the RPATH by the link
command (unlike macOS):

    $ ./bar
    Hello World!

But when inspecting the dependencies, the environment lib path appears twice:

    $ readelf -d ./bar
    ...
     0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
     0x0000000000000001 (NEEDED)             Shared library: [libxerces-c-3.2.so]
     0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
     0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
     0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
     0x000000000000000f (RPATH)              Library rpath: [/home/vagrant/miniconda3/envs/test-conda/lib:/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:]
    ...

Which is wrong. Now the build tree binary will pick first any old version of
the foo library installed in the environment instead of the version in the
build tree.

It seems that the Anaconda toolchain is setting the environment lib path into
the RPATH by its own. It is also set when installing the binaries, even when
CMake is not configured to set the install RPATH:

    $ make install
    ...
    Install the project...
    -- Install configuration: ""
    -- Installing: /home/vagrant/miniconda3/envs/test-conda/lib/libfoo.so
    -- Installing: /home/vagrant/miniconda3/envs/test-conda/include/foo.hpp
    -- Installing: /home/vagrant/miniconda3/envs/test-conda/bin/bar
    -- Set runtime path of "/home/vagrant/miniconda3/envs/test-conda/bin/bar" to ""

    $ bar
    Hello World!

    $ readelf -d $CONDA_PREFIX/bin/bar
    ...
     0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
     0x0000000000000001 (NEEDED)             Shared library: [libxerces-c-3.2.so]
     0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
     0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
     0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
     0x000000000000000f (RPATH)              Library rpath: [/home/vagrant/miniconda3/envs/test-conda/lib]
    ...

    # deactivate the environment
    $ conda deactivate

--------------------------------------------------

TL;DR I cannot get CMake and the Anaconda compilers and packages working
correctly.

- On macOS, the Conda environment library path is not added to the build RPATH.
- On Linux, the Conda environment library path is always added to the RPATH
  (in both build and install) independently of CMake.

Any advice or workarounds?

--
Sebastian Mancilla
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Issues trying to use the Anaconda compiler tools with CMake

Isaiah Norton
See also:

Ray Donnelly, who filed those issues, maintains the Anaconda compiler toolchain -- so you are in good company hitting this issue. It looks like some conda recipes explicitly define INSTALL_RPATH, likely for this reason:


On Mon, Aug 13, 2018 at 11:54 AM Isaiah Norton <[hidden email]> wrote:
The RPATH is not included when using Anaconda because CMake considers the Anaconda lib path to be an implicit link directory (as reported by the compiler). Look at `$build_dir/CMakeFiles/CMakeOutput.log` in the section about "implicit link info".

The simplest work-around is to set BUILD_RPATH manually, and possibly also INSTALL_RPATH, depending on what conda-build's fixup routine expects.

For example, adding this line near the top of your example CMakeList fixed the resulting binary, at least in the build directory:

set(CMAKE_BUILD_RPATH "$ENV{CONDA_PREFIX}/lib")

On Fri, Aug 10, 2018 at 5:55 PM Sebastián Mancilla <[hidden email]> wrote:
I am trying to use Conda as a package manager for isolated C++ development
environments. But unfortunately, when using CMake with the Anaconda-provided
compilers [1] (which are used to compile the binary packages in the Anaconda
repositories), things do not work as expected.

I have a small test case available here [2], with an executable calling a
shared library and a third-party dependency installed with Conda.


--------------------------------------------------

First, when using the system compiler, all works fine (but I am not sure of the
binary compatibility with the Conda packages, that's why I want to use the
Anaconda compilers):

    # create the environment and install XercesC
    $ conda create -n test-system xerces-c
    ...
    environment location: /Users/smancill/.local/share/miniconda3/envs/test-system
    ...
    The following NEW packages will be INSTALLED:

    icu:       58.2-h4b95b61_1
    libcxx:    4.0.1-h579ed51_0
    libcxxabi: 4.0.1-hebd6815_0
    xerces-c:  3.2.1-h44e365a_0
    ...

    # activate the environment
    $ conda activate test-system

    $ mkdir build-osx-system
    $ cd build-osx-system
    $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
    -- The CXX compiler identification is AppleClang 9.0.0.9000039
    -- Check for working CXX compiler: /usr/bin/c++
    -- Check for working CXX compiler: /usr/bin/c++ -- works
    ...
    -- Found XercesC: /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib (found version "3.2.1")
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /Users/smancill/src/conda-test/build-osx-system

    $ make -j1 VERBOSE=1
    ...
    [100%] Linking CXX executable bar
    /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
    /usr/bin/c++   -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -mmacosx-version-min=10.12 -Wl,-search_paths_first -Wl,-headerpad_max_install_names  CMakeFiles/bar.dir/bar.cpp.o  -o bar -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-system -Wl,-rpath,/Users/smancill/.local/share/miniconda3/envs/test-system/lib libfoo.dylib /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
    ...

The build directory (~/src/conda-test/build-osx-system) and the conda
environment lib directory (~/.local/share/miniconda3/envs/test-system/lib)
are correctly added to the RPATH in the build tree by the link command:

    $ ./bar
    Hello, world!

    $ otool -L ./bar
    ./bar:
        @rpath/libfoo.dylib (compatibility version 1.0.0, current version 0.0.0)
        @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)

    $ otool -l ./bar | grep -A2 LC_RPATH
            cmd LC_RPATH
        cmdsize 56
            path /Users/smancill/src/conda-test/build-osx-system (offset 12)
    --
            cmd LC_RPATH
        cmdsize 80
            path /Users/smancill/.local/share/miniconda3/envs/test-system/lib (offset 12)

If I install the binary, it fails because I haven't configured CMake to set the install RPATH:

    $ make install
    ...
    Install the project...
    -- Install configuration: ""
    -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libfoo.dylib
    -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/include/foo.hpp
    -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar

    $ bar
    dyld: Library not loaded: @rpath/libfoo.dylib
      Referenced from: /Users/smancill/.local/share/miniconda4/envs/test-system/bin/bar
      Reason: image not found
    [1]    84611 abort      bar

    $ otool -L $CONDA_PREFIX/bin/bar
    /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar:
        @rpath/libfoo.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
        /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)

    $ otool -l $CONDA_PREFIX/bin/bar | grep -A2 LC_RPATH
    # empty

    # deactivate the environment to start again
    $ conda deactivate

The same can be observed on Linux. Everything works as it should.

--------------------------------------------------

If I try to use Anaconda compilers on macOS, the build RPATH is not set
properly anymore:

    # create the environment and install the Anaconda compiler for macOS, and XercesC
    $ conda create -n test-conda clangxx_osx-64 xerces-c
    ...
    environment location: /Users/smancill/.local/share/miniconda3/envs/test-conda
    ...
    The following NEW packages will be INSTALLED:

        cctools:        895-h7512d6f_0
        clang:          4.0.1-h662ec87_0
        clang_osx-64:   4.0.1-h1ce6c1d_11
        clangxx:        4.0.1-hc9b4283_0
        clangxx_osx-64: 4.0.1-h22b1bf0_11
        compiler-rt:    4.0.1-h5487866_0
        icu:            58.2-h4b95b61_1
        ld64:           274.2-h7c2db76_0
        libcxx:         4.0.1-h579ed51_0
        libcxxabi:      4.0.1-hebd6815_0
        llvm:           4.0.1-hc748206_0
        llvm-lto-tapi:  4.0.1-h6701bc3_0
        xerces-c:       3.2.1-h44e365a_0
    ...

    # activate the environment (which sets the variables to use the Anaconda compiler)
    $ conda activate test-conda

    $ mkdir build-osx-conda
    $ cd build-osx-conda
    $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
    -- The CXX compiler identification is Clang 4.0.1
    -- Check for working CXX compiler: /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
    -- Check for working CXX compiler: /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++ -- works
    ...
    -- Found XercesC: /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib (found version "3.2.1")
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /Users/smancill/src/conda-test/build-osx-conda

    $ make -j1 VERBOSE=1
    ...
    [100%] Linking CXX executable bar
    /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
    /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++  -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O2 -pipe -stdlib=libc++ -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -mmacosx-version-min=10.12 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -Wl,-pie -Wl,-headerpad_max_install_names -Wl,-dead_strip_dylibs CMakeFiles/bar.dir/bar.cpp.o  -o bar -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-conda libfoo.dylib /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
    ...

You can see that the environment lib path is not added to the RPATH by the link command,
which in turns result in the executable not running from the build tree anymore:

    $ ./bar
    dyld: Library not loaded: @rpath/libxerces-c-3.2.dylib
      Referenced from: /Users/smancill/src/conda-test/build-osx-conda/./bar
      Reason: image not found
    [1]    89350 abort      ./bar

    $ otool -L ./bar
    ./bar:
        @rpath/libfoo.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
        @rpath/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)

    $ otool -l ./bar | grep -A2 LC_RPATH
          cmd LC_RPATH
      cmdsize 56
         path /Users/smancill/src/conda-test/build-osx-conda (offset 12)

    # deactivate the environment
    $ conda deactivate

--------------------------------------------------

If I try the Anaconda compilers on Linux, there are strange results too:

    # create the environment and install the Anaconda compiler for Linux, and XercesC
    $ conda create -n test-conda gxx_linux-64 xerces-c
    ...
    environment location: /home/vagrant/miniconda3/envs/test-conda
    ...
    The following NEW packages will be INSTALLED:

        binutils_impl_linux-64: 2.28.1-had2808c_3
        binutils_linux-64:      7.2.0-had2808c_27
        gcc_impl_linux-64:      7.2.0-habb00fd_3
        gcc_linux-64:           7.2.0-h550dcbe_27
        gxx_impl_linux-64:      7.2.0-hdf63c60_3
        gxx_linux-64:           7.2.0-h550dcbe_27
        icu:                    58.2-h9c2bf20_1
        libgcc-ng:              7.2.0-hdf63c60_3
        libstdcxx-ng:           7.2.0-hdf63c60_3
        xerces-c:               3.2.1-hac72e42_0

    # activate the environment (which sets the variables to use the Anaconda compiler)
    $ conda activate test-conda

    $ mkdir build-linux-conda
    $ cd build-linux-conda
    $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
    -- The CXX compiler identification is GNU 7.2.0
    -- Check for working CXX compiler: /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
    -- Check for working CXX compiler: /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++ -- works
    ...
    -- Found XercesC: /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so (found version "3.2.1")
    -- Configuring done
    -- Generating done
    -- Build files have been written to: /vagrant/conda-test/build-linux-conda

    $ make -j1 VERBOSE=1
    ...
    [100%] Linking CXX executable bar
    /usr/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
    /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++   -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe    -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now CMakeFiles/bar.dir/bar.cpp.o  -o bar libfoo.so /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so -Wl,-rpath,/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:
    ...

You can see that the environment lib path is added to the RPATH by the link
command (unlike macOS):

    $ ./bar
    Hello World!

But when inspecting the dependencies, the environment lib path appears twice:

    $ readelf -d ./bar
    ...
     0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
     0x0000000000000001 (NEEDED)             Shared library: [libxerces-c-3.2.so]
     0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
     0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
     0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
     0x000000000000000f (RPATH)              Library rpath: [/home/vagrant/miniconda3/envs/test-conda/lib:/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:]
    ...

Which is wrong. Now the build tree binary will pick first any old version of
the foo library installed in the environment instead of the version in the
build tree.

It seems that the Anaconda toolchain is setting the environment lib path into
the RPATH by its own. It is also set when installing the binaries, even when
CMake is not configured to set the install RPATH:

    $ make install
    ...
    Install the project...
    -- Install configuration: ""
    -- Installing: /home/vagrant/miniconda3/envs/test-conda/lib/libfoo.so
    -- Installing: /home/vagrant/miniconda3/envs/test-conda/include/foo.hpp
    -- Installing: /home/vagrant/miniconda3/envs/test-conda/bin/bar
    -- Set runtime path of "/home/vagrant/miniconda3/envs/test-conda/bin/bar" to ""

    $ bar
    Hello World!

    $ readelf -d $CONDA_PREFIX/bin/bar
    ...
     0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
     0x0000000000000001 (NEEDED)             Shared library: [libxerces-c-3.2.so]
     0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
     0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
     0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
     0x000000000000000f (RPATH)              Library rpath: [/home/vagrant/miniconda3/envs/test-conda/lib]
    ...

    # deactivate the environment
    $ conda deactivate

--------------------------------------------------

TL;DR I cannot get CMake and the Anaconda compilers and packages working
correctly.

- On macOS, the Conda environment library path is not added to the build RPATH.
- On Linux, the Conda environment library path is always added to the RPATH
  (in both build and install) independently of CMake.

Any advice or workarounds?

--
Sebastian Mancilla
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Issues trying to use the Anaconda compiler tools with CMake

Sebastián Mancilla
Thanks for the links.

The problem of setting CMAKE_BUILD_RPATH to $CONDA_PREFIX/lib is that
for binaries and libraries in the build tree, the list of RPATH
locations will be in the wrong order: the dependencies library path
will be first, and then the build tree. This will break the unit tests
if the library was installed previously (for example, to check the
library by running other installed programs), and then modified as
part of normal development, because the installed version will be
loaded instead of the version in the build tree. CMake supports this
use case out of the box and it works great (when not using Anaconda).

Note that in Linux the $CONDA_PREFIX/lib seems to be added to the
RPATH by the Anaconda toolchain itself, and it will appear first, so
there is nothing that can be done about that with CMake.

It seems that the workarounds when using Anaconda compilers, and doing
development, are:

- Always install before unit testing changes to the library being
developed (and set CMAKE_BUILD_RPATH).
- Never install the library (so the build tree not being first in the
RPATH is not an issue, and set CMAKE_BUILD_RPATH), create a different
environment to test installation.
- Don't use the build RPATH and set the proper environment variables
([DY]LD_LIBRARY_PATH) with the right path order when running from the
build tree.
- Manipulate the RPATH manually (with patchelf or similar).
- Don't use Anaconda compilers (will there be binary issues with
Anaconda dependencies?)

But they are not ideal.


If the Conda environment is not being used for development and someone
wants to just build and use some binary/library, setting
CMAKE_INSTALL_RPATH to $CONDA_PREFIX/lib and then installing will work
fine. And it looks that is not even necessary on Linux, because the
RPATH is already set by the toolchain.

El lun., 13 de ago. de 2018 a la(s) 13:35, Isaiah Norton
([hidden email]) escribió:

>
> See also:
>
> https://gitlab.kitware.com/cmake/cmake/merge_requests/207
>
>
> https://gitlab.kitware.com/cmake/cmake/issues/17483 (looks semi-related)
>
> Ray Donnelly, who filed those issues, maintains the Anaconda compiler toolchain -- so you are in good company hitting this issue. It looks like some conda recipes explicitly define INSTALL_RPATH, likely for this reason:
>
> https://github.com/AnacondaRecipes/vtk-feedstock/blob/791a1db9026fa2c81d171c38835b512adf221794/recipe/build.sh#L30
>
>
>
> On Mon, Aug 13, 2018 at 11:54 AM Isaiah Norton <[hidden email]> wrote:
>>
>> The RPATH is not included when using Anaconda because CMake considers the Anaconda lib path to be an implicit link directory (as reported by the compiler). Look at `$build_dir/CMakeFiles/CMakeOutput.log` in the section about "implicit link info".
>>
>> The simplest work-around is to set BUILD_RPATH manually, and possibly also INSTALL_RPATH, depending on what conda-build's fixup routine expects.
>>
>> For example, adding this line near the top of your example CMakeList fixed the resulting binary, at least in the build directory:
>>
>> set(CMAKE_BUILD_RPATH "$ENV{CONDA_PREFIX}/lib")
>>
>>
>> On Fri, Aug 10, 2018 at 5:55 PM Sebastián Mancilla <[hidden email]> wrote:
>>>
>>> I am trying to use Conda as a package manager for isolated C++ development
>>> environments. But unfortunately, when using CMake with the Anaconda-provided
>>> compilers [1] (which are used to compile the binary packages in the Anaconda
>>> repositories), things do not work as expected.
>>>
>>> I have a small test case available here [2], with an executable calling a
>>> shared library and a third-party dependency installed with Conda.
>>>
>>> [1]: https://conda.io/docs/user-guide/tasks/build-packages/compiler-tools.html
>>> [2]: https://gist.github.com/smancill/b28ca07ac11fdf285b4d559545a1630b
>>>
>>> --------------------------------------------------
>>>
>>> First, when using the system compiler, all works fine (but I am not sure of the
>>> binary compatibility with the Conda packages, that's why I want to use the
>>> Anaconda compilers):
>>>
>>>     # create the environment and install XercesC
>>>     $ conda create -n test-system xerces-c
>>>     ...
>>>     environment location: /Users/smancill/.local/share/miniconda3/envs/test-system
>>>     ...
>>>     The following NEW packages will be INSTALLED:
>>>
>>>     icu:       58.2-h4b95b61_1
>>>     libcxx:    4.0.1-h579ed51_0
>>>     libcxxabi: 4.0.1-hebd6815_0
>>>     xerces-c:  3.2.1-h44e365a_0
>>>     ...
>>>
>>>     # activate the environment
>>>     $ conda activate test-system
>>>
>>>     $ mkdir build-osx-system
>>>     $ cd build-osx-system
>>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>>     -- The CXX compiler identification is AppleClang 9.0.0.9000039
>>>     -- Check for working CXX compiler: /usr/bin/c++
>>>     -- Check for working CXX compiler: /usr/bin/c++ -- works
>>>     ...
>>>     -- Found XercesC: /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib (found version "3.2.1")
>>>     -- Configuring done
>>>     -- Generating done
>>>     -- Build files have been written to: /Users/smancill/src/conda-test/build-osx-system
>>>
>>>     $ make -j1 VERBOSE=1
>>>     ...
>>>     [100%] Linking CXX executable bar
>>>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
>>>     /usr/bin/c++   -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -mmacosx-version-min=10.12 -Wl,-search_paths_first -Wl,-headerpad_max_install_names  CMakeFiles/bar.dir/bar.cpp.o  -o bar -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-system -Wl,-rpath,/Users/smancill/.local/share/miniconda3/envs/test-system/lib libfoo.dylib /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
>>>     ...
>>>
>>> The build directory (~/src/conda-test/build-osx-system) and the conda
>>> environment lib directory (~/.local/share/miniconda3/envs/test-system/lib)
>>> are correctly added to the RPATH in the build tree by the link command:
>>>
>>>     $ ./bar
>>>     Hello, world!
>>>
>>>     $ otool -L ./bar
>>>     ./bar:
>>>         @rpath/libfoo.dylib (compatibility version 1.0.0, current version 0.0.0)
>>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
>>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
>>>
>>>     $ otool -l ./bar | grep -A2 LC_RPATH
>>>             cmd LC_RPATH
>>>         cmdsize 56
>>>             path /Users/smancill/src/conda-test/build-osx-system (offset 12)
>>>     --
>>>             cmd LC_RPATH
>>>         cmdsize 80
>>>             path /Users/smancill/.local/share/miniconda3/envs/test-system/lib (offset 12)
>>>
>>> If I install the binary, it fails because I haven't configured CMake to set the install RPATH:
>>>
>>>     $ make install
>>>     ...
>>>     Install the project...
>>>     -- Install configuration: ""
>>>     -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libfoo.dylib
>>>     -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/include/foo.hpp
>>>     -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar
>>>
>>>     $ bar
>>>     dyld: Library not loaded: @rpath/libfoo.dylib
>>>       Referenced from: /Users/smancill/.local/share/miniconda4/envs/test-system/bin/bar
>>>       Reason: image not found
>>>     [1]    84611 abort      bar
>>>
>>>     $ otool -L $CONDA_PREFIX/bin/bar
>>>     /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar:
>>>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
>>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
>>>
>>>     $ otool -l $CONDA_PREFIX/bin/bar | grep -A2 LC_RPATH
>>>     # empty
>>>
>>>     # deactivate the environment to start again
>>>     $ conda deactivate
>>>
>>> The same can be observed on Linux. Everything works as it should.
>>>
>>> --------------------------------------------------
>>>
>>> If I try to use Anaconda compilers on macOS, the build RPATH is not set
>>> properly anymore:
>>>
>>>     # create the environment and install the Anaconda compiler for macOS, and XercesC
>>>     $ conda create -n test-conda clangxx_osx-64 xerces-c
>>>     ...
>>>     environment location: /Users/smancill/.local/share/miniconda3/envs/test-conda
>>>     ...
>>>     The following NEW packages will be INSTALLED:
>>>
>>>         cctools:        895-h7512d6f_0
>>>         clang:          4.0.1-h662ec87_0
>>>         clang_osx-64:   4.0.1-h1ce6c1d_11
>>>         clangxx:        4.0.1-hc9b4283_0
>>>         clangxx_osx-64: 4.0.1-h22b1bf0_11
>>>         compiler-rt:    4.0.1-h5487866_0
>>>         icu:            58.2-h4b95b61_1
>>>         ld64:           274.2-h7c2db76_0
>>>         libcxx:         4.0.1-h579ed51_0
>>>         libcxxabi:      4.0.1-hebd6815_0
>>>         llvm:           4.0.1-hc748206_0
>>>         llvm-lto-tapi:  4.0.1-h6701bc3_0
>>>         xerces-c:       3.2.1-h44e365a_0
>>>     ...
>>>
>>>     # activate the environment (which sets the variables to use the Anaconda compiler)
>>>     $ conda activate test-conda
>>>
>>>     $ mkdir build-osx-conda
>>>     $ cd build-osx-conda
>>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>>     -- The CXX compiler identification is Clang 4.0.1
>>>     -- Check for working CXX compiler: /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
>>>     -- Check for working CXX compiler: /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++ -- works
>>>     ...
>>>     -- Found XercesC: /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib (found version "3.2.1")
>>>     -- Configuring done
>>>     -- Generating done
>>>     -- Build files have been written to: /Users/smancill/src/conda-test/build-osx-conda
>>>
>>>     $ make -j1 VERBOSE=1
>>>     ...
>>>     [100%] Linking CXX executable bar
>>>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
>>>     /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++  -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O2 -pipe -stdlib=libc++ -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -mmacosx-version-min=10.12 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -Wl,-pie -Wl,-headerpad_max_install_names -Wl,-dead_strip_dylibs CMakeFiles/bar.dir/bar.cpp.o  -o bar -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-conda libfoo.dylib /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
>>>     ...
>>>
>>> You can see that the environment lib path is not added to the RPATH by the link command,
>>> which in turns result in the executable not running from the build tree anymore:
>>>
>>>     $ ./bar
>>>     dyld: Library not loaded: @rpath/libxerces-c-3.2.dylib
>>>       Referenced from: /Users/smancill/src/conda-test/build-osx-conda/./bar
>>>       Reason: image not found
>>>     [1]    89350 abort      ./bar
>>>
>>>     $ otool -L ./bar
>>>     ./bar:
>>>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>         @rpath/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
>>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
>>>
>>>     $ otool -l ./bar | grep -A2 LC_RPATH
>>>           cmd LC_RPATH
>>>       cmdsize 56
>>>          path /Users/smancill/src/conda-test/build-osx-conda (offset 12)
>>>
>>>     # deactivate the environment
>>>     $ conda deactivate
>>>
>>> --------------------------------------------------
>>>
>>> If I try the Anaconda compilers on Linux, there are strange results too:
>>>
>>>     # create the environment and install the Anaconda compiler for Linux, and XercesC
>>>     $ conda create -n test-conda gxx_linux-64 xerces-c
>>>     ...
>>>     environment location: /home/vagrant/miniconda3/envs/test-conda
>>>     ...
>>>     The following NEW packages will be INSTALLED:
>>>
>>>         binutils_impl_linux-64: 2.28.1-had2808c_3
>>>         binutils_linux-64:      7.2.0-had2808c_27
>>>         gcc_impl_linux-64:      7.2.0-habb00fd_3
>>>         gcc_linux-64:           7.2.0-h550dcbe_27
>>>         gxx_impl_linux-64:      7.2.0-hdf63c60_3
>>>         gxx_linux-64:           7.2.0-h550dcbe_27
>>>         icu:                    58.2-h9c2bf20_1
>>>         libgcc-ng:              7.2.0-hdf63c60_3
>>>         libstdcxx-ng:           7.2.0-hdf63c60_3
>>>         xerces-c:               3.2.1-hac72e42_0
>>>
>>>     # activate the environment (which sets the variables to use the Anaconda compiler)
>>>     $ conda activate test-conda
>>>
>>>     $ mkdir build-linux-conda
>>>     $ cd build-linux-conda
>>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>>     -- The CXX compiler identification is GNU 7.2.0
>>>     -- Check for working CXX compiler: /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>>>     -- Check for working CXX compiler: /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++ -- works
>>>     ...
>>>     -- Found XercesC: /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so (found version "3.2.1")
>>>     -- Configuring done
>>>     -- Generating done
>>>     -- Build files have been written to: /vagrant/conda-test/build-linux-conda
>>>
>>>     $ make -j1 VERBOSE=1
>>>     ...
>>>     [100%] Linking CXX executable bar
>>>     /usr/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
>>>     /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++   -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe    -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now CMakeFiles/bar.dir/bar.cpp.o  -o bar libfoo.so /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so -Wl,-rpath,/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:
>>>     ...
>>>
>>> You can see that the environment lib path is added to the RPATH by the link
>>> command (unlike macOS):
>>>
>>>     $ ./bar
>>>     Hello World!
>>>
>>> But when inspecting the dependencies, the environment lib path appears twice:
>>>
>>>     $ readelf -d ./bar
>>>     ...
>>>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>>>      0x0000000000000001 (NEEDED)             Shared library: [libxerces-c-3.2.so]
>>>      0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
>>>      0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
>>>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>>>      0x000000000000000f (RPATH)              Library rpath: [/home/vagrant/miniconda3/envs/test-conda/lib:/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:]
>>>     ...
>>>
>>> Which is wrong. Now the build tree binary will pick first any old version of
>>> the foo library installed in the environment instead of the version in the
>>> build tree.
>>>
>>> It seems that the Anaconda toolchain is setting the environment lib path into
>>> the RPATH by its own. It is also set when installing the binaries, even when
>>> CMake is not configured to set the install RPATH:
>>>
>>>     $ make install
>>>     ...
>>>     Install the project...
>>>     -- Install configuration: ""
>>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/lib/libfoo.so
>>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/include/foo.hpp
>>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/bin/bar
>>>     -- Set runtime path of "/home/vagrant/miniconda3/envs/test-conda/bin/bar" to ""
>>>
>>>     $ bar
>>>     Hello World!
>>>
>>>     $ readelf -d $CONDA_PREFIX/bin/bar
>>>     ...
>>>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>>>      0x0000000000000001 (NEEDED)             Shared library: [libxerces-c-3.2.so]
>>>      0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
>>>      0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
>>>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>>>      0x000000000000000f (RPATH)              Library rpath: [/home/vagrant/miniconda3/envs/test-conda/lib]
>>>     ...
>>>
>>>     # deactivate the environment
>>>     $ conda deactivate
>>>
>>> --------------------------------------------------
>>>
>>> TL;DR I cannot get CMake and the Anaconda compilers and packages working
>>> correctly.
>>>
>>> - On macOS, the Conda environment library path is not added to the build RPATH.
>>> - On Linux, the Conda environment library path is always added to the RPATH
>>>   (in both build and install) independently of CMake.
>>>
>>> Any advice or workarounds?
>>>
>>> --
>>> Sebastian Mancilla
>>> --
>>>
>>> Powered by www.kitware.com
>>>
>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>>
>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>>>
>>> CMake Support: http://cmake.org/cmake/help/support.html
>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>
>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> https://cmake.org/mailman/listinfo/cmake



--
Sebastian Mancilla Matta
CCTVal, UTFSM
Valparaíso, Chile
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Issues trying to use the Anaconda compiler tools with CMake

Ray Donnelly
Why are you not using conda-build here? Anaconda Distro and
conda-forge build countless CMake projects. It handles so much extra
stuff on top of building (DSO verification, rpath rewriting, more). If
your end goal is not conda packages then you can untar most sets of
conda-packages to make working software installations (caveat for most
being that some software requires what we call 'prefix replacament'
and those aren't trivially relocatable).

IMHO CMake's handling of RPATHs is broken, as per my "determine
implicit linker directories" PR which there seems to be little to no
interest in instead preferring toolchain cmake files for something
that *clearly* should be queried from the link as it is imperative
when building software that CMake and the toolchain agree on things as
fundamental as this.

RPATH is never set by a toolchain except through being passed to it
(by CMake's logic, fixed by
https://gitlab.kitware.com/cmake/cmake/merge_requests/207).

I would again request that this pretty trivial, obvious and important
PR gets some consideration. Without it CMake asks anyone trying to
build a software distro with more than simple system prefix-based
compilation will run into needing this fix or needing to provide a
toolchain just to tell CMake what it should figure out for itself.

On Tue, Aug 14, 2018 at 2:12 AM, Sebastián Mancilla <[hidden email]> wrote:

> Thanks for the links.
>
> The problem of setting CMAKE_BUILD_RPATH to $CONDA_PREFIX/lib is that
> for binaries and libraries in the build tree, the list of RPATH
> locations will be in the wrong order: the dependencies library path
> will be first, and then the build tree. This will break the unit tests
> if the library was installed previously (for example, to check the
> library by running other installed programs), and then modified as
> part of normal development, because the installed version will be
> loaded instead of the version in the build tree. CMake supports this
> use case out of the box and it works great (when not using Anaconda).
>
> Note that in Linux the $CONDA_PREFIX/lib seems to be added to the
> RPATH by the Anaconda toolchain itself, and it will appear first, so
> there is nothing that can be done about that with CMake.
>
> It seems that the workarounds when using Anaconda compilers, and doing
> development, are:
>
> - Always install before unit testing changes to the library being
> developed (and set CMAKE_BUILD_RPATH).
> - Never install the library (so the build tree not being first in the
> RPATH is not an issue, and set CMAKE_BUILD_RPATH), create a different
> environment to test installation.
> - Don't use the build RPATH and set the proper environment variables
> ([DY]LD_LIBRARY_PATH) with the right path order when running from the
> build tree.
> - Manipulate the RPATH manually (with patchelf or similar).
> - Don't use Anaconda compilers (will there be binary issues with
> Anaconda dependencies?)
>
> But they are not ideal.
>
>
> If the Conda environment is not being used for development and someone
> wants to just build and use some binary/library, setting
> CMAKE_INSTALL_RPATH to $CONDA_PREFIX/lib and then installing will work
> fine. And it looks that is not even necessary on Linux, because the
> RPATH is already set by the toolchain.
>
> El lun., 13 de ago. de 2018 a la(s) 13:35, Isaiah Norton
> ([hidden email]) escribió:
>>
>> See also:
>>
>> https://gitlab.kitware.com/cmake/cmake/merge_requests/207
>>
>>
>> https://gitlab.kitware.com/cmake/cmake/issues/17483 (looks semi-related)
>>
>> Ray Donnelly, who filed those issues, maintains the Anaconda compiler toolchain -- so you are in good company hitting this issue. It looks like some conda recipes explicitly define INSTALL_RPATH, likely for this reason:
>>
>> https://github.com/AnacondaRecipes/vtk-feedstock/blob/791a1db9026fa2c81d171c38835b512adf221794/recipe/build.sh#L30
>>
>>
>>
>> On Mon, Aug 13, 2018 at 11:54 AM Isaiah Norton <[hidden email]> wrote:
>>>
>>> The RPATH is not included when using Anaconda because CMake considers the Anaconda lib path to be an implicit link directory (as reported by the compiler). Look at `$build_dir/CMakeFiles/CMakeOutput.log` in the section about "implicit link info".
>>>
>>> The simplest work-around is to set BUILD_RPATH manually, and possibly also INSTALL_RPATH, depending on what conda-build's fixup routine expects.
>>>
>>> For example, adding this line near the top of your example CMakeList fixed the resulting binary, at least in the build directory:
>>>
>>> set(CMAKE_BUILD_RPATH "$ENV{CONDA_PREFIX}/lib")
>>>
>>>
>>> On Fri, Aug 10, 2018 at 5:55 PM Sebastián Mancilla <[hidden email]> wrote:
>>>>
>>>> I am trying to use Conda as a package manager for isolated C++ development
>>>> environments. But unfortunately, when using CMake with the Anaconda-provided
>>>> compilers [1] (which are used to compile the binary packages in the Anaconda
>>>> repositories), things do not work as expected.
>>>>
>>>> I have a small test case available here [2], with an executable calling a
>>>> shared library and a third-party dependency installed with Conda.
>>>>
>>>> [1]: https://conda.io/docs/user-guide/tasks/build-packages/compiler-tools.html
>>>> [2]: https://gist.github.com/smancill/b28ca07ac11fdf285b4d559545a1630b
>>>>
>>>> --------------------------------------------------
>>>>
>>>> First, when using the system compiler, all works fine (but I am not sure of the
>>>> binary compatibility with the Conda packages, that's why I want to use the
>>>> Anaconda compilers):
>>>>
>>>>     # create the environment and install XercesC
>>>>     $ conda create -n test-system xerces-c
>>>>     ...
>>>>     environment location: /Users/smancill/.local/share/miniconda3/envs/test-system
>>>>     ...
>>>>     The following NEW packages will be INSTALLED:
>>>>
>>>>     icu:       58.2-h4b95b61_1
>>>>     libcxx:    4.0.1-h579ed51_0
>>>>     libcxxabi: 4.0.1-hebd6815_0
>>>>     xerces-c:  3.2.1-h44e365a_0
>>>>     ...
>>>>
>>>>     # activate the environment
>>>>     $ conda activate test-system
>>>>
>>>>     $ mkdir build-osx-system
>>>>     $ cd build-osx-system
>>>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>>>     -- The CXX compiler identification is AppleClang 9.0.0.9000039
>>>>     -- Check for working CXX compiler: /usr/bin/c++
>>>>     -- Check for working CXX compiler: /usr/bin/c++ -- works
>>>>     ...
>>>>     -- Found XercesC: /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib (found version "3.2.1")
>>>>     -- Configuring done
>>>>     -- Generating done
>>>>     -- Build files have been written to: /Users/smancill/src/conda-test/build-osx-system
>>>>
>>>>     $ make -j1 VERBOSE=1
>>>>     ...
>>>>     [100%] Linking CXX executable bar
>>>>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
>>>>     /usr/bin/c++   -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -mmacosx-version-min=10.12 -Wl,-search_paths_first -Wl,-headerpad_max_install_names  CMakeFiles/bar.dir/bar.cpp.o  -o bar -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-system -Wl,-rpath,/Users/smancill/.local/share/miniconda3/envs/test-system/lib libfoo.dylib /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
>>>>     ...
>>>>
>>>> The build directory (~/src/conda-test/build-osx-system) and the conda
>>>> environment lib directory (~/.local/share/miniconda3/envs/test-system/lib)
>>>> are correctly added to the RPATH in the build tree by the link command:
>>>>
>>>>     $ ./bar
>>>>     Hello, world!
>>>>
>>>>     $ otool -L ./bar
>>>>     ./bar:
>>>>         @rpath/libfoo.dylib (compatibility version 1.0.0, current version 0.0.0)
>>>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
>>>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
>>>>
>>>>     $ otool -l ./bar | grep -A2 LC_RPATH
>>>>             cmd LC_RPATH
>>>>         cmdsize 56
>>>>             path /Users/smancill/src/conda-test/build-osx-system (offset 12)
>>>>     --
>>>>             cmd LC_RPATH
>>>>         cmdsize 80
>>>>             path /Users/smancill/.local/share/miniconda3/envs/test-system/lib (offset 12)
>>>>
>>>> If I install the binary, it fails because I haven't configured CMake to set the install RPATH:
>>>>
>>>>     $ make install
>>>>     ...
>>>>     Install the project...
>>>>     -- Install configuration: ""
>>>>     -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libfoo.dylib
>>>>     -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/include/foo.hpp
>>>>     -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar
>>>>
>>>>     $ bar
>>>>     dyld: Library not loaded: @rpath/libfoo.dylib
>>>>       Referenced from: /Users/smancill/.local/share/miniconda4/envs/test-system/bin/bar
>>>>       Reason: image not found
>>>>     [1]    84611 abort      bar
>>>>
>>>>     $ otool -L $CONDA_PREFIX/bin/bar
>>>>     /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar:
>>>>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
>>>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
>>>>
>>>>     $ otool -l $CONDA_PREFIX/bin/bar | grep -A2 LC_RPATH
>>>>     # empty
>>>>
>>>>     # deactivate the environment to start again
>>>>     $ conda deactivate
>>>>
>>>> The same can be observed on Linux. Everything works as it should.
>>>>
>>>> --------------------------------------------------
>>>>
>>>> If I try to use Anaconda compilers on macOS, the build RPATH is not set
>>>> properly anymore:
>>>>
>>>>     # create the environment and install the Anaconda compiler for macOS, and XercesC
>>>>     $ conda create -n test-conda clangxx_osx-64 xerces-c
>>>>     ...
>>>>     environment location: /Users/smancill/.local/share/miniconda3/envs/test-conda
>>>>     ...
>>>>     The following NEW packages will be INSTALLED:
>>>>
>>>>         cctools:        895-h7512d6f_0
>>>>         clang:          4.0.1-h662ec87_0
>>>>         clang_osx-64:   4.0.1-h1ce6c1d_11
>>>>         clangxx:        4.0.1-hc9b4283_0
>>>>         clangxx_osx-64: 4.0.1-h22b1bf0_11
>>>>         compiler-rt:    4.0.1-h5487866_0
>>>>         icu:            58.2-h4b95b61_1
>>>>         ld64:           274.2-h7c2db76_0
>>>>         libcxx:         4.0.1-h579ed51_0
>>>>         libcxxabi:      4.0.1-hebd6815_0
>>>>         llvm:           4.0.1-hc748206_0
>>>>         llvm-lto-tapi:  4.0.1-h6701bc3_0
>>>>         xerces-c:       3.2.1-h44e365a_0
>>>>     ...
>>>>
>>>>     # activate the environment (which sets the variables to use the Anaconda compiler)
>>>>     $ conda activate test-conda
>>>>
>>>>     $ mkdir build-osx-conda
>>>>     $ cd build-osx-conda
>>>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>>>     -- The CXX compiler identification is Clang 4.0.1
>>>>     -- Check for working CXX compiler: /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
>>>>     -- Check for working CXX compiler: /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++ -- works
>>>>     ...
>>>>     -- Found XercesC: /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib (found version "3.2.1")
>>>>     -- Configuring done
>>>>     -- Generating done
>>>>     -- Build files have been written to: /Users/smancill/src/conda-test/build-osx-conda
>>>>
>>>>     $ make -j1 VERBOSE=1
>>>>     ...
>>>>     [100%] Linking CXX executable bar
>>>>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
>>>>     /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++  -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O2 -pipe -stdlib=libc++ -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -mmacosx-version-min=10.12 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -Wl,-pie -Wl,-headerpad_max_install_names -Wl,-dead_strip_dylibs CMakeFiles/bar.dir/bar.cpp.o  -o bar -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-conda libfoo.dylib /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
>>>>     ...
>>>>
>>>> You can see that the environment lib path is not added to the RPATH by the link command,
>>>> which in turns result in the executable not running from the build tree anymore:
>>>>
>>>>     $ ./bar
>>>>     dyld: Library not loaded: @rpath/libxerces-c-3.2.dylib
>>>>       Referenced from: /Users/smancill/src/conda-test/build-osx-conda/./bar
>>>>       Reason: image not found
>>>>     [1]    89350 abort      ./bar
>>>>
>>>>     $ otool -L ./bar
>>>>     ./bar:
>>>>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>>         @rpath/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
>>>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
>>>>
>>>>     $ otool -l ./bar | grep -A2 LC_RPATH
>>>>           cmd LC_RPATH
>>>>       cmdsize 56
>>>>          path /Users/smancill/src/conda-test/build-osx-conda (offset 12)
>>>>
>>>>     # deactivate the environment
>>>>     $ conda deactivate
>>>>
>>>> --------------------------------------------------
>>>>
>>>> If I try the Anaconda compilers on Linux, there are strange results too:
>>>>
>>>>     # create the environment and install the Anaconda compiler for Linux, and XercesC
>>>>     $ conda create -n test-conda gxx_linux-64 xerces-c
>>>>     ...
>>>>     environment location: /home/vagrant/miniconda3/envs/test-conda
>>>>     ...
>>>>     The following NEW packages will be INSTALLED:
>>>>
>>>>         binutils_impl_linux-64: 2.28.1-had2808c_3
>>>>         binutils_linux-64:      7.2.0-had2808c_27
>>>>         gcc_impl_linux-64:      7.2.0-habb00fd_3
>>>>         gcc_linux-64:           7.2.0-h550dcbe_27
>>>>         gxx_impl_linux-64:      7.2.0-hdf63c60_3
>>>>         gxx_linux-64:           7.2.0-h550dcbe_27
>>>>         icu:                    58.2-h9c2bf20_1
>>>>         libgcc-ng:              7.2.0-hdf63c60_3
>>>>         libstdcxx-ng:           7.2.0-hdf63c60_3
>>>>         xerces-c:               3.2.1-hac72e42_0
>>>>
>>>>     # activate the environment (which sets the variables to use the Anaconda compiler)
>>>>     $ conda activate test-conda
>>>>
>>>>     $ mkdir build-linux-conda
>>>>     $ cd build-linux-conda
>>>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>>>     -- The CXX compiler identification is GNU 7.2.0
>>>>     -- Check for working CXX compiler: /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>>>>     -- Check for working CXX compiler: /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++ -- works
>>>>     ...
>>>>     -- Found XercesC: /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so (found version "3.2.1")
>>>>     -- Configuring done
>>>>     -- Generating done
>>>>     -- Build files have been written to: /vagrant/conda-test/build-linux-conda
>>>>
>>>>     $ make -j1 VERBOSE=1
>>>>     ...
>>>>     [100%] Linking CXX executable bar
>>>>     /usr/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
>>>>     /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++   -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe    -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now CMakeFiles/bar.dir/bar.cpp.o  -o bar libfoo.so /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so -Wl,-rpath,/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:
>>>>     ...
>>>>
>>>> You can see that the environment lib path is added to the RPATH by the link
>>>> command (unlike macOS):
>>>>
>>>>     $ ./bar
>>>>     Hello World!
>>>>
>>>> But when inspecting the dependencies, the environment lib path appears twice:
>>>>
>>>>     $ readelf -d ./bar
>>>>     ...
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libxerces-c-3.2.so]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>>>>      0x000000000000000f (RPATH)              Library rpath: [/home/vagrant/miniconda3/envs/test-conda/lib:/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:]
>>>>     ...
>>>>
>>>> Which is wrong. Now the build tree binary will pick first any old version of
>>>> the foo library installed in the environment instead of the version in the
>>>> build tree.
>>>>
>>>> It seems that the Anaconda toolchain is setting the environment lib path into
>>>> the RPATH by its own. It is also set when installing the binaries, even when
>>>> CMake is not configured to set the install RPATH:
>>>>
>>>>     $ make install
>>>>     ...
>>>>     Install the project...
>>>>     -- Install configuration: ""
>>>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/lib/libfoo.so
>>>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/include/foo.hpp
>>>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/bin/bar
>>>>     -- Set runtime path of "/home/vagrant/miniconda3/envs/test-conda/bin/bar" to ""
>>>>
>>>>     $ bar
>>>>     Hello World!
>>>>
>>>>     $ readelf -d $CONDA_PREFIX/bin/bar
>>>>     ...
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libxerces-c-3.2.so]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>>>>      0x000000000000000f (RPATH)              Library rpath: [/home/vagrant/miniconda3/envs/test-conda/lib]
>>>>     ...
>>>>
>>>>     # deactivate the environment
>>>>     $ conda deactivate
>>>>
>>>> --------------------------------------------------
>>>>
>>>> TL;DR I cannot get CMake and the Anaconda compilers and packages working
>>>> correctly.
>>>>
>>>> - On macOS, the Conda environment library path is not added to the build RPATH.
>>>> - On Linux, the Conda environment library path is always added to the RPATH
>>>>   (in both build and install) independently of CMake.
>>>>
>>>> Any advice or workarounds?
>>>>
>>>> --
>>>> Sebastian Mancilla
>>>> --
>>>>
>>>> Powered by www.kitware.com
>>>>
>>>> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>>>>
>>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>>>>
>>>> CMake Support: http://cmake.org/cmake/help/support.html
>>>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>>>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>>>
>>>> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> https://cmake.org/mailman/listinfo/cmake
>
>
>
> --
> Sebastian Mancilla Matta
> CCTVal, UTFSM
> Valparaíso, Chile
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Issues trying to use the Anaconda compiler tools with CMake

Sebastián Mancilla
I wanted to try Conda for normal day-to-day C++ development, while having all the dependencies isolated from other projects and the base system.

- Change the sources
- Build
- Run the tests
- Repeat

The most common workflow possible. I shouldn't go through conda-build for that. There is nothing special about $CONDA_PREFIX that requires handling by conda-build, I just need to point to the headers and the libraries (which by using Conda are conveniently under a single prefix).

Then when development is more or less ready I can use conda-build to create a package that can be installed and tested in other environments, and it works fine when building/installing a CMake project (I have being doing that without problems these last days and I happy with it, much better than Nix).

My main issue is that, as I explained, I cannot run the tests because $CONDA_PREFIX/lib is not in the build RPATH, and I wanted to understand why, and maybe get a workaround.
Passing -DCMAKE_BUILD_RPATH=$CONDA_PREFIX/lib allows the dependencies to be found, but it doesn't really do the same thing.


Another common thing that may be done is to develop a couple of projects in the same environment:

- Work on A
- Install A into $CONDA_PREFIX, so I can compile B against it and check their integration
- Back to more work on A
- Run the tests of A to check changes

I have being using CMake exclusively in the last 5+ years, and I got used to the way the RPATH are set in the build tree. I know that if I run the tests, they will run agains the modified version of A compiled in the build tree, and not the version installed previously in PREFIX.

(Somebody may say that A and B should be built at the same time [with build tree exports and add_directory, or going through the package registry], but that's not the point. B may not even use CMake).

CMake defaults plus Anaconda compilers break that by not having the RPATH in the expected order. And it is not easy to get them right.

But maybe it is just me too accustomed to the way CMake works by default. I don't really know how people using Autotools or Meson run their tests. Do they set the RPATH?


El mar., 14 de ago. de 2018 a la(s) 03:43, Ray Donnelly ([hidden email]) escribió:
Why are you not using conda-build here? Anaconda Distro and
conda-forge build countless CMake projects. It handles so much extra
stuff on top of building (DSO verification, rpath rewriting, more). If
your end goal is not conda packages then you can untar most sets of
conda-packages to make working software installations (caveat for most
being that some software requires what we call 'prefix replacament'
and those aren't trivially relocatable).

IMHO CMake's handling of RPATHs is broken, as per my "determine
implicit linker directories" PR which there seems to be little to no
interest in instead preferring toolchain cmake files for something
that *clearly* should be queried from the link as it is imperative
when building software that CMake and the toolchain agree on things as
fundamental as this.

RPATH is never set by a toolchain except through being passed to it
(by CMake's logic, fixed by
https://urldefense.proofpoint.com/v2/url?u=https-3A__gitlab.kitware.com_cmake_cmake_merge-5Frequests_207&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=wviv_JywOo9sb5vTUw4ilTQ5JMOrMD9A_hxuf-rCcZA&e= ).

I would again request that this pretty trivial, obvious and important
PR gets some consideration. Without it CMake asks anyone trying to
build a software distro with more than simple system prefix-based
compilation will run into needing this fix or needing to provide a
toolchain just to tell CMake what it should figure out for itself.

On Tue, Aug 14, 2018 at 2:12 AM, Sebastián Mancilla <[hidden email]> wrote:
> Thanks for the links.
>
> The problem of setting CMAKE_BUILD_RPATH to $CONDA_PREFIX/lib is that
> for binaries and libraries in the build tree, the list of RPATH
> locations will be in the wrong order: the dependencies library path
> will be first, and then the build tree. This will break the unit tests
> if the library was installed previously (for example, to check the
> library by running other installed programs), and then modified as
> part of normal development, because the installed version will be
> loaded instead of the version in the build tree. CMake supports this
> use case out of the box and it works great (when not using Anaconda).
>
> Note that in Linux the $CONDA_PREFIX/lib seems to be added to the
> RPATH by the Anaconda toolchain itself, and it will appear first, so
> there is nothing that can be done about that with CMake.
>
> It seems that the workarounds when using Anaconda compilers, and doing
> development, are:
>
> - Always install before unit testing changes to the library being
> developed (and set CMAKE_BUILD_RPATH).
> - Never install the library (so the build tree not being first in the
> RPATH is not an issue, and set CMAKE_BUILD_RPATH), create a different
> environment to test installation.
> - Don't use the build RPATH and set the proper environment variables
> ([DY]LD_LIBRARY_PATH) with the right path order when running from the
> build tree.
> - Manipulate the RPATH manually (with patchelf or similar).
> - Don't use Anaconda compilers (will there be binary issues with
> Anaconda dependencies?)
>
> But they are not ideal.
>
>
> If the Conda environment is not being used for development and someone
> wants to just build and use some binary/library, setting
> CMAKE_INSTALL_RPATH to $CONDA_PREFIX/lib and then installing will work
> fine. And it looks that is not even necessary on Linux, because the
> RPATH is already set by the toolchain.
>
> El lun., 13 de ago. de 2018 a la(s) 13:35, Isaiah Norton
> ([hidden email]) escribió:
>>
>> See also:
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__gitlab.kitware.com_cmake_cmake_merge-5Frequests_207&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=wviv_JywOo9sb5vTUw4ilTQ5JMOrMD9A_hxuf-rCcZA&e=
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__gitlab.kitware.com_cmake_cmake_issues_17483&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=1HXSUEWs7xRLJp5YZX-GkAVK2XOSe8fuzCRIAvAfNcA&e=  (looks semi-related)
>>
>> Ray Donnelly, who filed those issues, maintains the Anaconda compiler toolchain -- so you are in good company hitting this issue. It looks like some conda recipes explicitly define INSTALL_RPATH, likely for this reason:
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_AnacondaRecipes_vtk-2Dfeedstock_blob_791a1db9026fa2c81d171c38835b512adf221794_recipe_build.sh-23L30&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=06Ed9Yo2DX991fx_H21n9HBNLLFLNa94vVxrGHTc75I&e=
>>
>>
>>
>> On Mon, Aug 13, 2018 at 11:54 AM Isaiah Norton <[hidden email]> wrote:
>>>
>>> The RPATH is not included when using Anaconda because CMake considers the Anaconda lib path to be an implicit link directory (as reported by the compiler). Look at `$build_dir/CMakeFiles/CMakeOutput.log` in the section about "implicit link info".
>>>
>>> The simplest work-around is to set BUILD_RPATH manually, and possibly also INSTALL_RPATH, depending on what conda-build's fixup routine expects.
>>>
>>> For example, adding this line near the top of your example CMakeList fixed the resulting binary, at least in the build directory:
>>>
>>> set(CMAKE_BUILD_RPATH "$ENV{CONDA_PREFIX}/lib")
>>>
>>>
>>> On Fri, Aug 10, 2018 at 5:55 PM Sebastián Mancilla <[hidden email]> wrote:
>>>>
>>>> I am trying to use Conda as a package manager for isolated C++ development
>>>> environments. But unfortunately, when using CMake with the Anaconda-provided
>>>> compilers [1] (which are used to compile the binary packages in the Anaconda
>>>> repositories), things do not work as expected.
>>>>
>>>> I have a small test case available here [2], with an executable calling a
>>>> shared library and a third-party dependency installed with Conda.
>>>>
>>>> [1]: https://urldefense.proofpoint.com/v2/url?u=https-3A__conda.io_docs_user-2Dguide_tasks_build-2Dpackages_compiler-2Dtools.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=jvTiH6i8c51MldDSbrw1AxiclEs1TKUMg-iQpLOoJqM&e=
>>>> [2]: https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_smancill_b28ca07ac11fdf285b4d559545a1630b&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=q3em0cZgykXNfXgRt7bdxCnVuz0FkuNVx462yPtpEbA&e=
>>>>
>>>> --------------------------------------------------
>>>>
>>>> First, when using the system compiler, all works fine (but I am not sure of the
>>>> binary compatibility with the Conda packages, that's why I want to use the
>>>> Anaconda compilers):
>>>>
>>>>     # create the environment and install XercesC
>>>>     $ conda create -n test-system xerces-c
>>>>     ...
>>>>     environment location: /Users/smancill/.local/share/miniconda3/envs/test-system
>>>>     ...
>>>>     The following NEW packages will be INSTALLED:
>>>>
>>>>     icu:       58.2-h4b95b61_1
>>>>     libcxx:    4.0.1-h579ed51_0
>>>>     libcxxabi: 4.0.1-hebd6815_0
>>>>     xerces-c:  3.2.1-h44e365a_0
>>>>     ...
>>>>
>>>>     # activate the environment
>>>>     $ conda activate test-system
>>>>
>>>>     $ mkdir build-osx-system
>>>>     $ cd build-osx-system
>>>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>>>     -- The CXX compiler identification is AppleClang 9.0.0.9000039
>>>>     -- Check for working CXX compiler: /usr/bin/c++
>>>>     -- Check for working CXX compiler: /usr/bin/c++ -- works
>>>>     ...
>>>>     -- Found XercesC: /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib (found version "3.2.1")
>>>>     -- Configuring done
>>>>     -- Generating done
>>>>     -- Build files have been written to: /Users/smancill/src/conda-test/build-osx-system
>>>>
>>>>     $ make -j1 VERBOSE=1
>>>>     ...
>>>>     [100%] Linking CXX executable bar
>>>>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
>>>>     /usr/bin/c++   -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -mmacosx-version-min=10.12 -Wl,-search_paths_first -Wl,-headerpad_max_install_names  CMakeFiles/bar.dir/bar.cpp.o  -o bar -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-system -Wl,-rpath,/Users/smancill/.local/share/miniconda3/envs/test-system/lib libfoo.dylib /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
>>>>     ...
>>>>
>>>> The build directory (~/src/conda-test/build-osx-system) and the conda
>>>> environment lib directory (~/.local/share/miniconda3/envs/test-system/lib)
>>>> are correctly added to the RPATH in the build tree by the link command:
>>>>
>>>>     $ ./bar
>>>>     Hello, world!
>>>>
>>>>     $ otool -L ./bar
>>>>     ./bar:
>>>>         @rpath/libfoo.dylib (compatibility version 1.0.0, current version 0.0.0)
>>>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
>>>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
>>>>
>>>>     $ otool -l ./bar | grep -A2 LC_RPATH
>>>>             cmd LC_RPATH
>>>>         cmdsize 56
>>>>             path /Users/smancill/src/conda-test/build-osx-system (offset 12)
>>>>     --
>>>>             cmd LC_RPATH
>>>>         cmdsize 80
>>>>             path /Users/smancill/.local/share/miniconda3/envs/test-system/lib (offset 12)
>>>>
>>>> If I install the binary, it fails because I haven't configured CMake to set the install RPATH:
>>>>
>>>>     $ make install
>>>>     ...
>>>>     Install the project...
>>>>     -- Install configuration: ""
>>>>     -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libfoo.dylib
>>>>     -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/include/foo.hpp
>>>>     -- Installing: /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar
>>>>
>>>>     $ bar
>>>>     dyld: Library not loaded: @rpath/libfoo.dylib
>>>>       Referenced from: /Users/smancill/.local/share/miniconda4/envs/test-system/bin/bar
>>>>       Reason: image not found
>>>>     [1]    84611 abort      bar
>>>>
>>>>     $ otool -L $CONDA_PREFIX/bin/bar
>>>>     /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar:
>>>>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
>>>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
>>>>
>>>>     $ otool -l $CONDA_PREFIX/bin/bar | grep -A2 LC_RPATH
>>>>     # empty
>>>>
>>>>     # deactivate the environment to start again
>>>>     $ conda deactivate
>>>>
>>>> The same can be observed on Linux. Everything works as it should.
>>>>
>>>> --------------------------------------------------
>>>>
>>>> If I try to use Anaconda compilers on macOS, the build RPATH is not set
>>>> properly anymore:
>>>>
>>>>     # create the environment and install the Anaconda compiler for macOS, and XercesC
>>>>     $ conda create -n test-conda clangxx_osx-64 xerces-c
>>>>     ...
>>>>     environment location: /Users/smancill/.local/share/miniconda3/envs/test-conda
>>>>     ...
>>>>     The following NEW packages will be INSTALLED:
>>>>
>>>>         cctools:        895-h7512d6f_0
>>>>         clang:          4.0.1-h662ec87_0
>>>>         clang_osx-64:   4.0.1-h1ce6c1d_11
>>>>         clangxx:        4.0.1-hc9b4283_0
>>>>         clangxx_osx-64: 4.0.1-h22b1bf0_11
>>>>         compiler-rt:    4.0.1-h5487866_0
>>>>         icu:            58.2-h4b95b61_1
>>>>         ld64:           274.2-h7c2db76_0
>>>>         libcxx:         4.0.1-h579ed51_0
>>>>         libcxxabi:      4.0.1-hebd6815_0
>>>>         llvm:           4.0.1-hc748206_0
>>>>         llvm-lto-tapi:  4.0.1-h6701bc3_0
>>>>         xerces-c:       3.2.1-h44e365a_0
>>>>     ...
>>>>
>>>>     # activate the environment (which sets the variables to use the Anaconda compiler)
>>>>     $ conda activate test-conda
>>>>
>>>>     $ mkdir build-osx-conda
>>>>     $ cd build-osx-conda
>>>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>>>     -- The CXX compiler identification is Clang 4.0.1
>>>>     -- Check for working CXX compiler: /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
>>>>     -- Check for working CXX compiler: /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++ -- works
>>>>     ...
>>>>     -- Found XercesC: /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib (found version "3.2.1")
>>>>     -- Configuring done
>>>>     -- Generating done
>>>>     -- Build files have been written to: /Users/smancill/src/conda-test/build-osx-conda
>>>>
>>>>     $ make -j1 VERBOSE=1
>>>>     ...
>>>>     [100%] Linking CXX executable bar
>>>>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
>>>>     /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++  -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE -fstack-protector-strong -O2 -pipe -stdlib=libc++ -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk -mmacosx-version-min=10.12 -Wl,-search_paths_first -Wl,-headerpad_max_install_names -Wl,-pie -Wl,-headerpad_max_install_names -Wl,-dead_strip_dylibs CMakeFiles/bar.dir/bar.cpp.o  -o bar -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-conda libfoo.dylib /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
>>>>     ...
>>>>
>>>> You can see that the environment lib path is not added to the RPATH by the link command,
>>>> which in turns result in the executable not running from the build tree anymore:
>>>>
>>>>     $ ./bar
>>>>     dyld: Library not loaded: @rpath/libxerces-c-3.2.dylib
>>>>       Referenced from: /Users/smancill/src/conda-test/build-osx-conda/./bar
>>>>       Reason: image not found
>>>>     [1]    89350 abort      ./bar
>>>>
>>>>     $ otool -L ./bar
>>>>     ./bar:
>>>>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current version 0.0.0)
>>>>         @rpath/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
>>>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
>>>>
>>>>     $ otool -l ./bar | grep -A2 LC_RPATH
>>>>           cmd LC_RPATH
>>>>       cmdsize 56
>>>>          path /Users/smancill/src/conda-test/build-osx-conda (offset 12)
>>>>
>>>>     # deactivate the environment
>>>>     $ conda deactivate
>>>>
>>>> --------------------------------------------------
>>>>
>>>> If I try the Anaconda compilers on Linux, there are strange results too:
>>>>
>>>>     # create the environment and install the Anaconda compiler for Linux, and XercesC
>>>>     $ conda create -n test-conda gxx_linux-64 xerces-c
>>>>     ...
>>>>     environment location: /home/vagrant/miniconda3/envs/test-conda
>>>>     ...
>>>>     The following NEW packages will be INSTALLED:
>>>>
>>>>         binutils_impl_linux-64: 2.28.1-had2808c_3
>>>>         binutils_linux-64:      7.2.0-had2808c_27
>>>>         gcc_impl_linux-64:      7.2.0-habb00fd_3
>>>>         gcc_linux-64:           7.2.0-h550dcbe_27
>>>>         gxx_impl_linux-64:      7.2.0-hdf63c60_3
>>>>         gxx_linux-64:           7.2.0-h550dcbe_27
>>>>         icu:                    58.2-h9c2bf20_1
>>>>         libgcc-ng:              7.2.0-hdf63c60_3
>>>>         libstdcxx-ng:           7.2.0-hdf63c60_3
>>>>         xerces-c:               3.2.1-hac72e42_0
>>>>
>>>>     # activate the environment (which sets the variables to use the Anaconda compiler)
>>>>     $ conda activate test-conda
>>>>
>>>>     $ mkdir build-linux-conda
>>>>     $ cd build-linux-conda
>>>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>>>     -- The CXX compiler identification is GNU 7.2.0
>>>>     -- Check for working CXX compiler: /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>>>>     -- Check for working CXX compiler: /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++ -- works
>>>>     ...
>>>>     -- Found XercesC: /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so (found version "3.2.1")
>>>>     -- Configuring done
>>>>     -- Generating done
>>>>     -- Build files have been written to: /vagrant/conda-test/build-linux-conda
>>>>
>>>>     $ make -j1 VERBOSE=1
>>>>     ...
>>>>     [100%] Linking CXX executable bar
>>>>     /usr/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt --verbose=1
>>>>     /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++   -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe    -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now CMakeFiles/bar.dir/bar.cpp.o  -o bar libfoo.so /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so -Wl,-rpath,/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:
>>>>     ...
>>>>
>>>> You can see that the environment lib path is added to the RPATH by the link
>>>> command (unlike macOS):
>>>>
>>>>     $ ./bar
>>>>     Hello World!
>>>>
>>>> But when inspecting the dependencies, the environment lib path appears twice:
>>>>
>>>>     $ readelf -d ./bar
>>>>     ...
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libxerces-c-3.2.so]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>>>>      0x000000000000000f (RPATH)              Library rpath: [/home/vagrant/miniconda3/envs/test-conda/lib:/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:]
>>>>     ...
>>>>
>>>> Which is wrong. Now the build tree binary will pick first any old version of
>>>> the foo library installed in the environment instead of the version in the
>>>> build tree.
>>>>
>>>> It seems that the Anaconda toolchain is setting the environment lib path into
>>>> the RPATH by its own. It is also set when installing the binaries, even when
>>>> CMake is not configured to set the install RPATH:
>>>>
>>>>     $ make install
>>>>     ...
>>>>     Install the project...
>>>>     -- Install configuration: ""
>>>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/lib/libfoo.so
>>>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/include/foo.hpp
>>>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/bin/bar
>>>>     -- Set runtime path of "/home/vagrant/miniconda3/envs/test-conda/bin/bar" to ""
>>>>
>>>>     $ bar
>>>>     Hello World!
>>>>
>>>>     $ readelf -d $CONDA_PREFIX/bin/bar
>>>>     ...
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libxerces-c-3.2.so]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
>>>>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>>>>      0x000000000000000f (RPATH)              Library rpath: [/home/vagrant/miniconda3/envs/test-conda/lib]
>>>>     ...
>>>>
>>>>     # deactivate the environment
>>>>     $ conda deactivate
>>>>
>>>> --------------------------------------------------
>>>>
>>>> TL;DR I cannot get CMake and the Anaconda compilers and packages working
>>>> correctly.
>>>>
>>>> - On macOS, the Conda environment library path is not added to the build RPATH.
>>>> - On Linux, the Conda environment library path is always added to the RPATH
>>>>   (in both build and install) independently of CMake.
>>>>
>>>> Any advice or workarounds?
>>>>
>>>> --
>>>> Sebastian Mancilla
>>>> --
>>>>
>>>> Powered by www.kitware.com
>>>>
>>>> Please keep messages on-topic and check the CMake FAQ at: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cmake.org_Wiki_CMake-5FFAQ&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=uBEF8GemaQb9eJ-UK_hEzA_YgX3pQ-boOIEG7uPkAyc&e=
>>>>
>>>> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>>>>
>>>> CMake Support: https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_support.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=svD5IJGKwoXnqAMeR130SGVF4UsybjdD3_6P3kozhAA&e=
>>>> CMake Consulting: https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_consulting.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=07p3Ic2lHKjWP1e65eN4md9oL_EaUWgnDc4fUQCx4oI&e=
>>>> CMake Training Courses: https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_training.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=z4EmjaY7PSqPEwinemJnTXOI9drLVGgOGoIE1HRhk4o&e=
>>>>
>>>> Visit other Kitware open-source projects at https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=QzHKjq3n_bPKgzhchCEiD0_KFJrVhaXBFSACVpxG5nU&e=
>>>>
>>>> Follow this link to subscribe/unsubscribe:
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__cmake.org_mailman_listinfo_cmake&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=fOiqJW-HpoDIaOBxq5-_9vu0GwxF4qjmchJS1C3GHjI&e=
>
>
>
> --
> Sebastian Mancilla Matta
> CCTVal, UTFSM
> Valparaíso, Chile
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cmake.org_Wiki_CMake-5FFAQ&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=uBEF8GemaQb9eJ-UK_hEzA_YgX3pQ-boOIEG7uPkAyc&e=
>
> Kitware offers various services to support the CMake community. For more information on each offering, please visit:
>
> CMake Support: https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_support.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=svD5IJGKwoXnqAMeR130SGVF4UsybjdD3_6P3kozhAA&e=
> CMake Consulting: https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_consulting.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=07p3Ic2lHKjWP1e65eN4md9oL_EaUWgnDc4fUQCx4oI&e=
> CMake Training Courses: https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_training.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=z4EmjaY7PSqPEwinemJnTXOI9drLVGgOGoIE1HRhk4o&e=
>
> Visit other Kitware open-source projects at https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=QzHKjq3n_bPKgzhchCEiD0_KFJrVhaXBFSACVpxG5nU&e=
>
> Follow this link to subscribe/unsubscribe:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__cmake.org_mailman_listinfo_cmake&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=Qi50uFIqz8VX30PtrlfRY6CGw0gYYbc3vo0gmgXQR9g&s=fOiqJW-HpoDIaOBxq5-_9vu0GwxF4qjmchJS1C3GHjI&e=


--
Sebastian Mancilla Matta
CCTVal, UTFSM
Valparaíso, Chile

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Issues trying to use the Anaconda compiler tools with CMake

Eric Noulard


Le mar. 14 août 2018 à 20:38, Sebastián Mancilla <[hidden email]> a écrit :
I wanted to try Conda for normal day-to-day C++ development, while having all the dependencies isolated from other projects and the base system.

- Change the sources
- Build
- Run the tests
- Repeat

Hi Sebastian,

Just curious on why you would prefer conda over "real" container technology like docker or rkt for the kind of usage you describe ?
Do you ultimately want to distribute your software as conda packages?

I'm not proficient in conda but AFAIK docker (or rkt) offers easier/better isolation for the usage you describe.
The side-effect being that inside your container cmake should behave like as expected.
At least this is my own experience.

Some people even try to automatize the container creation out of conda packaged software:
I have no experience with that whatsoever, I usually craft my own dockerfile and work with that.

If your goal includes the distrubution of your software as conda package may be you can get in touch with people
at conda-forge: https://conda-forge.org/#about, I bet they build a lot of cmake-based projects in there and may
have experienced same caveats with the conda compilers usage.


--
Eric

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Issues trying to use the Anaconda compiler tools with CMake

Ray Donnelly
Docker is unnecessary overhead here and irrelevant to the question of which compilers to use when building conda packages (use ours or risk binary incompatibility with the rest of the ecosystems, please do not attempt to use e.g. CentOS6 system compilers to compile modern software either!). Docker doesn't come with modern compilers patched to support things like c++17 on CentOS6, they are also slow and to not mitigate against Spectre.

Our compilation story is very good. We use fully isolated pdeudo cross compilers that both target and run on CentOS6 in Linux and our own builds of clang on macOS. We repackage CentOS6 rpms into the compiler sysroot for the few packages that link to system libs.

I like and use for docker but conda has its own story here and docker and compiler technology are orthogonal in this regard. To t, I still use our computers on docker.

I honestly believe the isolation fans sometimes go far to far though and will accept a lot of unnecessary complication and overhead chasing this goal. Sufficient isolation is possible in other ways.

For testing the packages though (on Linux targets) I love using docker. I can make sure our conda packages work on all the OSes we support.

You can if you want use our compilers in docker but it's pretty pointless (and routing conda package building thorough something like docker is a requirement the community, conda forge in particular does not need).

I dream of a day when docker is seen as one great tool with lots of useful applications instead of the solution to everything but I don't see it coming anytime soon.

On Aug 15, 2018 9:29 AM, "Eric Noulard" <[hidden email]> wrote:


Le mar. 14 août 2018 à 20:38, Sebastián Mancilla <[hidden email]> a écrit :
I wanted to try Conda for normal day-to-day C++ development, while having all the dependencies isolated from other projects and the base system.

- Change the sources
- Build
- Run the tests
- Repeat

Hi Sebastian,

Just curious on why you would prefer conda over "real" container technology like docker or rkt for the kind of usage you describe ?
Do you ultimately want to distribute your software as conda packages?

I'm not proficient in conda but AFAIK docker (or rkt) offers easier/better isolation for the usage you describe.
The side-effect being that inside your container cmake should behave like as expected.
At least this is my own experience.

Some people even try to automatize the container creation out of conda packaged software:
I have no experience with that whatsoever, I usually craft my own dockerfile and work with that.

If your goal includes the distrubution of your software as conda package may be you can get in touch with people
at conda-forge: https://conda-forge.org/#about, I bet they build a lot of cmake-based projects in there and may
have experienced same caveats with the conda compilers usage.


--
Eric


--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Issues trying to use the Anaconda compiler tools with CMake

Eric Noulard


Le mer. 15 août 2018 à 10:57, Ray Donnelly <[hidden email]> a écrit :
Docker is unnecessary overhead here and irrelevant to the question of which compilers to use when building conda packages (use ours or risk binary incompatibility with the rest of the ecosystems, please do not attempt to use e.g. CentOS6 system compilers to compile modern software either!). Docker doesn't come with modern compilers patched to support things like c++17 on CentOS6, they are also slow and to not mitigate against Spectre.

Hi Ray,

Don't get me wrong I certainly don't want to generate flamewar against the benefits conda gives to many users.
I routinely use custom-compiled compilers in native environment (without docker nor conda though) and I did never have any issue while compiling things with CMake and those custom compilers.
 
Our compilation story is very good. 

Again I don't doubt that, and please accept my apologies if my previous words may have been understood otherwise.
 
For testing the packages though (on Linux targets) I love using docker. I can make sure our conda packages work on all the OSes we support.

Agreed too, use the right tool for the right purpose.
 
You can if you want use our compilers in docker but it's pretty pointless (and routing conda package building thorough something like docker is a requirement the community, conda forge in particular does not need).

I don't want that I was asking question about Sebastian needs and certainly not questioning the value of conda and in particular the conda compiler work you did.
I know too well that having a "fully controlled compiler version" is essential when you want to support a wide range of platforms [even various linux distribution], precisely because you want to ensure that you can "at least" have say C++17 on all your supported platform/distros, or common runtime or homogeneous OpenMP support etc... 
 

I dream of a day when docker is seen as one great tool with lots of useful applications instead of the solution to everything but I don't see it coming anytime soon.

I really don't think docker is the solution to everything.
Again I'm sorry if my previous statement may have been understood otherwise.

Having conda/conda compiler/conda build work seamlessly working with CMake is valuable and I'm sure you'll find the proper solution for that along with Kitware
as already referred issue and PR indicates.

--
Eric

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Issues trying to use the Anaconda compiler tools with CMake

Ray Donnelly
In reply to this post by Sebastián Mancilla
Hi Sebastián,

Without having time to properly go through this, I feel I should
correct some technical inaccuracies, but *all* of your issues can be
sidestepped by using conda-build. Installation and RPATHs are always
very tricky for projects to get right so we side step any issues here
by running post-build fixups on these things. We ensure RPATHs have
the opportunity to add our own, uniquify them (I think!), and make
them fully relative on macOS and Linux.

WRT RPATHs being added or not, we set LDFLAGs for RPATHs the linker
activation script *when run under conda-build*. If you want to fake
that so you get the exact same flags that are used to compile our
packages do: CONDA_BUILD=1 conda activate envname. If you don't set
CONDA_BUILD=1 then it'll set all flags *except* -I${PREFIX}/include,
-L${PREFIX}/lib and -Wl,-rpath,${PREFIX}/lib.

If you want to use our compilers in their completely 'raw' form (of
course you could unset LDFLAGS, CFLAGS, CPPFLAGS too), then install
e.g. gcc_impl_linux-64 instead of gcc_linux-64 which really are
helpers for interfacing the raw compilers with conda-build (and
setting good default compilation flags for security and performance
reasons).

You mentioned using [DY]LD_LIBRARY_PATH, I would caution no one to do
this ever outside of development workflows. FWIW, we run into lots of
trouble with LD_LIBRARY_PATH and I am *firmly* in the camp that
LD_LIBRARY_PATH is harmful (i.e. never use it systematically) and I am
utterly convinced that DT_RUNPATH is a huge mistake. We actually
consider detection of DT_RUNPATH in any of our DSOs or exes an error
condition and only allow DT_RPATH. We just had so many bugs due to the
wrong libs being used by end users due to this, for example there is
no way a Qt application linked against our Qt libs is going to be
happy with some random system Qt library that's been interposed.

For macOS, you should also set CONDA_BUILD_SYSROOT=<somewhere that
macOS 10.9, 10.10 or 10.11 SDK> (depending on the macOS version you
want to target). These old SDKs can be gotten from old Xcode builds
and also on github. Unfortunately the compilers are not compatible
with the new .tbd file format used in newer SDKs and by the newest
Apple system linker and the source to enable that has not been
released yet (there have been no new source drops for Apple's ld64 in
a while).

But please, just use conda-build! While we try to keep them working in
as many situations as we can, these tools are primarily focussed
around conda-build and the technical decisions we make with respect to
them will be from that perspective.

Hope this helps some?

 Fri, Aug 10, 2018 at 10:48 PM, Sebastián Mancilla <[hidden email]> wrote:

> I am trying to use Conda as a package manager for isolated C++ development
> environments. But unfortunately, when using CMake with the Anaconda-provided
> compilers [1] (which are used to compile the binary packages in the Anaconda
> repositories), things do not work as expected.
>
> I have a small test case available here [2], with an executable calling a
> shared library and a third-party dependency installed with Conda.
>
> [1]:
> https://conda.io/docs/user-guide/tasks/build-packages/compiler-tools.html
> [2]: https://gist.github.com/smancill/b28ca07ac11fdf285b4d559545a1630b
>
> --------------------------------------------------
>
> First, when using the system compiler, all works fine (but I am not sure of
> the
> binary compatibility with the Conda packages, that's why I want to use the
> Anaconda compilers):
>
>     # create the environment and install XercesC
>     $ conda create -n test-system xerces-c
>     ...
>     environment location:
> /Users/smancill/.local/share/miniconda3/envs/test-system
>     ...
>     The following NEW packages will be INSTALLED:
>
>     icu:       58.2-h4b95b61_1
>     libcxx:    4.0.1-h579ed51_0
>     libcxxabi: 4.0.1-hebd6815_0
>     xerces-c:  3.2.1-h44e365a_0
>     ...
>
>     # activate the environment
>     $ conda activate test-system
>
>     $ mkdir build-osx-system
>     $ cd build-osx-system
>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>     -- The CXX compiler identification is AppleClang 9.0.0.9000039
>     -- Check for working CXX compiler: /usr/bin/c++
>     -- Check for working CXX compiler: /usr/bin/c++ -- works
>     ...
>     -- Found XercesC:
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
> (found version "3.2.1")
>     -- Configuring done
>     -- Generating done
>     -- Build files have been written to:
> /Users/smancill/src/conda-test/build-osx-system
>
>     $ make -j1 VERBOSE=1
>     ...
>     [100%] Linking CXX executable bar
>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
> --verbose=1
>     /usr/bin/c++   -isysroot
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
> -mmacosx-version-min=10.12 -Wl,-search_paths_first
> -Wl,-headerpad_max_install_names  CMakeFiles/bar.dir/bar.cpp.o  -o bar
> -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-system
> -Wl,-rpath,/Users/smancill/.local/share/miniconda3/envs/test-system/lib
> libfoo.dylib
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
>     ...
>
> The build directory (~/src/conda-test/build-osx-system) and the conda
> environment lib directory (~/.local/share/miniconda3/envs/test-system/lib)
> are correctly added to the RPATH in the build tree by the link command:
>
>     $ ./bar
>     Hello, world!
>
>     $ otool -L ./bar
>     ./bar:
>         @rpath/libfoo.dylib (compatibility version 1.0.0, current version
> 0.0.0)
>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
> version 0.0.0)
>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
> version 400.9.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1252.0.0)
>
>     $ otool -l ./bar | grep -A2 LC_RPATH
>             cmd LC_RPATH
>         cmdsize 56
>             path /Users/smancill/src/conda-test/build-osx-system (offset 12)
>     --
>             cmd LC_RPATH
>         cmdsize 80
>             path
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib (offset 12)
>
> If I install the binary, it fails because I haven't configured CMake to set
> the install RPATH:
>
>     $ make install
>     ...
>     Install the project...
>     -- Install configuration: ""
>     -- Installing:
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libfoo.dylib
>     -- Installing:
> /Users/smancill/.local/share/miniconda3/envs/test-system/include/foo.hpp
>     -- Installing:
> /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar
>
>     $ bar
>     dyld: Library not loaded: @rpath/libfoo.dylib
>       Referenced from:
> /Users/smancill/.local/share/miniconda4/envs/test-system/bin/bar
>       Reason: image not found
>     [1]    84611 abort      bar
>
>     $ otool -L $CONDA_PREFIX/bin/bar
>     /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar:
>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version
> 0.0.0)
>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
> version 0.0.0)
>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
> version 400.9.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1252.0.0)
>
>     $ otool -l $CONDA_PREFIX/bin/bar | grep -A2 LC_RPATH
>     # empty
>
>     # deactivate the environment to start again
>     $ conda deactivate
>
> The same can be observed on Linux. Everything works as it should.
>
> --------------------------------------------------
>
> If I try to use Anaconda compilers on macOS, the build RPATH is not set
> properly anymore:
>
>     # create the environment and install the Anaconda compiler for macOS,
> and XercesC
>     $ conda create -n test-conda clangxx_osx-64 xerces-c
>     ...
>     environment location:
> /Users/smancill/.local/share/miniconda3/envs/test-conda
>     ...
>     The following NEW packages will be INSTALLED:
>
>         cctools:        895-h7512d6f_0
>         clang:          4.0.1-h662ec87_0
>         clang_osx-64:   4.0.1-h1ce6c1d_11
>         clangxx:        4.0.1-hc9b4283_0
>         clangxx_osx-64: 4.0.1-h22b1bf0_11
>         compiler-rt:    4.0.1-h5487866_0
>         icu:            58.2-h4b95b61_1
>         ld64:           274.2-h7c2db76_0
>         libcxx:         4.0.1-h579ed51_0
>         libcxxabi:      4.0.1-hebd6815_0
>         llvm:           4.0.1-hc748206_0
>         llvm-lto-tapi:  4.0.1-h6701bc3_0
>         xerces-c:       3.2.1-h44e365a_0
>     ...
>
>     # activate the environment (which sets the variables to use the Anaconda
> compiler)
>     $ conda activate test-conda
>
>     $ mkdir build-osx-conda
>     $ cd build-osx-conda
>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>     -- The CXX compiler identification is Clang 4.0.1
>     -- Check for working CXX compiler:
> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
>     -- Check for working CXX compiler:
> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
> -- works
>     ...
>     -- Found XercesC:
> /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
> (found version "3.2.1")
>     -- Configuring done
>     -- Generating done
>     -- Build files have been written to:
> /Users/smancill/src/conda-test/build-osx-conda
>
>     $ make -j1 VERBOSE=1
>     ...
>     [100%] Linking CXX executable bar
>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
> --verbose=1
>
> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
> -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE
> -fstack-protector-strong -O2 -pipe -stdlib=libc++
> -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isysroot
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
> -mmacosx-version-min=10.12 -Wl,-search_paths_first
> -Wl,-headerpad_max_install_names -Wl,-pie -Wl,-headerpad_max_install_names
> -Wl,-dead_strip_dylibs CMakeFiles/bar.dir/bar.cpp.o  -o bar
> -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-conda libfoo.dylib
> /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
>     ...
>
> You can see that the environment lib path is not added to the RPATH by the
> link command,
> which in turns result in the executable not running from the build tree
> anymore:
>
>     $ ./bar
>     dyld: Library not loaded: @rpath/libxerces-c-3.2.dylib
>       Referenced from: /Users/smancill/src/conda-test/build-osx-conda/./bar
>       Reason: image not found
>     [1]    89350 abort      ./bar
>
>     $ otool -L ./bar
>     ./bar:
>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version
> 0.0.0)
>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
> version 0.0.0)
>         @rpath/libc++.1.dylib (compatibility version 1.0.0, current version
> 1.0.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1252.0.0)
>
>     $ otool -l ./bar | grep -A2 LC_RPATH
>           cmd LC_RPATH
>       cmdsize 56
>          path /Users/smancill/src/conda-test/build-osx-conda (offset 12)
>
>     # deactivate the environment
>     $ conda deactivate
>
> --------------------------------------------------
>
> If I try the Anaconda compilers on Linux, there are strange results too:
>
>     # create the environment and install the Anaconda compiler for Linux,
> and XercesC
>     $ conda create -n test-conda gxx_linux-64 xerces-c
>     ...
>     environment location: /home/vagrant/miniconda3/envs/test-conda
>     ...
>     The following NEW packages will be INSTALLED:
>
>         binutils_impl_linux-64: 2.28.1-had2808c_3
>         binutils_linux-64:      7.2.0-had2808c_27
>         gcc_impl_linux-64:      7.2.0-habb00fd_3
>         gcc_linux-64:           7.2.0-h550dcbe_27
>         gxx_impl_linux-64:      7.2.0-hdf63c60_3
>         gxx_linux-64:           7.2.0-h550dcbe_27
>         icu:                    58.2-h9c2bf20_1
>         libgcc-ng:              7.2.0-hdf63c60_3
>         libstdcxx-ng:           7.2.0-hdf63c60_3
>         xerces-c:               3.2.1-hac72e42_0
>
>     # activate the environment (which sets the variables to use the Anaconda
> compiler)
>     $ conda activate test-conda
>
>     $ mkdir build-linux-conda
>     $ cd build-linux-conda
>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>     -- The CXX compiler identification is GNU 7.2.0
>     -- Check for working CXX compiler:
> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>     -- Check for working CXX compiler:
> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
> -- works
>     ...
>     -- Found XercesC:
> /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so (found version
> "3.2.1")
>     -- Configuring done
>     -- Generating done
>     -- Build files have been written to:
> /vagrant/conda-test/build-linux-conda
>
>     $ make -j1 VERBOSE=1
>     ...
>     [100%] Linking CXX executable bar
>     /usr/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
> --verbose=1
>
> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
> -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona
> -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2
> -pipe    -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now
> CMakeFiles/bar.dir/bar.cpp.o  -o bar libfoo.so
> /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so
> -Wl,-rpath,/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:
>     ...
>
> You can see that the environment lib path is added to the RPATH by the link
> command (unlike macOS):
>
>     $ ./bar
>     Hello World!
>
> But when inspecting the dependencies, the environment lib path appears
> twice:
>
>     $ readelf -d ./bar
>     ...
>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>      0x0000000000000001 (NEEDED)             Shared library:
> [libxerces-c-3.2.so]
>      0x0000000000000001 (NEEDED)             Shared library:
> [libstdc++.so.6]
>      0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>      0x000000000000000f (RPATH)              Library rpath:
> [/home/vagrant/miniconda3/envs/test-conda/lib:/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:]
>     ...
>
> Which is wrong. Now the build tree binary will pick first any old version of
> the foo library installed in the environment instead of the version in the
> build tree.
>
> It seems that the Anaconda toolchain is setting the environment lib path
> into
> the RPATH by its own. It is also set when installing the binaries, even when
> CMake is not configured to set the install RPATH:
>
>     $ make install
>     ...
>     Install the project...
>     -- Install configuration: ""
>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/lib/libfoo.so
>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/include/foo.hpp
>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/bin/bar
>     -- Set runtime path of
> "/home/vagrant/miniconda3/envs/test-conda/bin/bar" to ""
>
>     $ bar
>     Hello World!
>
>     $ readelf -d $CONDA_PREFIX/bin/bar
>     ...
>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>      0x0000000000000001 (NEEDED)             Shared library:
> [libxerces-c-3.2.so]
>      0x0000000000000001 (NEEDED)             Shared library:
> [libstdc++.so.6]
>      0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>      0x000000000000000f (RPATH)              Library rpath:
> [/home/vagrant/miniconda3/envs/test-conda/lib]
>     ...
>
>     # deactivate the environment
>     $ conda deactivate
>
> --------------------------------------------------
>
> TL;DR I cannot get CMake and the Anaconda compilers and packages working
> correctly.
>
> - On macOS, the Conda environment library path is not added to the build
> RPATH.
> - On Linux, the Conda environment library path is always added to the RPATH
>   (in both build and install) independently of CMake.
>
> Any advice or workarounds?
>
> --
> Sebastian Mancilla
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> http://www.cmake.org/Wiki/CMake_FAQ
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> https://cmake.org/mailman/listinfo/cmake
>
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Issues trying to use the Anaconda compiler tools with CMake

Ray Donnelly
Our compiler activation scripts (highlighting the bit of most interest
to you I hope) are here:
https://github.com/AnacondaRecipes/aggregate/blob/master/ctng-compilers-activation-feedstock/recipe/activate-gcc.sh#L84-L101

On Wed, Aug 15, 2018 at 11:44 AM, Ray Donnelly <[hidden email]> wrote:

> Hi Sebastián,
>
> Without having time to properly go through this, I feel I should
> correct some technical inaccuracies, but *all* of your issues can be
> sidestepped by using conda-build. Installation and RPATHs are always
> very tricky for projects to get right so we side step any issues here
> by running post-build fixups on these things. We ensure RPATHs have
> the opportunity to add our own, uniquify them (I think!), and make
> them fully relative on macOS and Linux.
>
> WRT RPATHs being added or not, we set LDFLAGs for RPATHs the linker
> activation script *when run under conda-build*. If you want to fake
> that so you get the exact same flags that are used to compile our
> packages do: CONDA_BUILD=1 conda activate envname. If you don't set
> CONDA_BUILD=1 then it'll set all flags *except* -I${PREFIX}/include,
> -L${PREFIX}/lib and -Wl,-rpath,${PREFIX}/lib.
>
> If you want to use our compilers in their completely 'raw' form (of
> course you could unset LDFLAGS, CFLAGS, CPPFLAGS too), then install
> e.g. gcc_impl_linux-64 instead of gcc_linux-64 which really are
> helpers for interfacing the raw compilers with conda-build (and
> setting good default compilation flags for security and performance
> reasons).
>
> You mentioned using [DY]LD_LIBRARY_PATH, I would caution no one to do
> this ever outside of development workflows. FWIW, we run into lots of
> trouble with LD_LIBRARY_PATH and I am *firmly* in the camp that
> LD_LIBRARY_PATH is harmful (i.e. never use it systematically) and I am
> utterly convinced that DT_RUNPATH is a huge mistake. We actually
> consider detection of DT_RUNPATH in any of our DSOs or exes an error
> condition and only allow DT_RPATH. We just had so many bugs due to the
> wrong libs being used by end users due to this, for example there is
> no way a Qt application linked against our Qt libs is going to be
> happy with some random system Qt library that's been interposed.
>
> For macOS, you should also set CONDA_BUILD_SYSROOT=<somewhere that
> macOS 10.9, 10.10 or 10.11 SDK> (depending on the macOS version you
> want to target). These old SDKs can be gotten from old Xcode builds
> and also on github. Unfortunately the compilers are not compatible
> with the new .tbd file format used in newer SDKs and by the newest
> Apple system linker and the source to enable that has not been
> released yet (there have been no new source drops for Apple's ld64 in
> a while).
>
> But please, just use conda-build! While we try to keep them working in
> as many situations as we can, these tools are primarily focussed
> around conda-build and the technical decisions we make with respect to
> them will be from that perspective.
>
> Hope this helps some?
>
>  Fri, Aug 10, 2018 at 10:48 PM, Sebastián Mancilla <[hidden email]> wrote:
>> I am trying to use Conda as a package manager for isolated C++ development
>> environments. But unfortunately, when using CMake with the Anaconda-provided
>> compilers [1] (which are used to compile the binary packages in the Anaconda
>> repositories), things do not work as expected.
>>
>> I have a small test case available here [2], with an executable calling a
>> shared library and a third-party dependency installed with Conda.
>>
>> [1]:
>> https://conda.io/docs/user-guide/tasks/build-packages/compiler-tools.html
>> [2]: https://gist.github.com/smancill/b28ca07ac11fdf285b4d559545a1630b
>>
>> --------------------------------------------------
>>
>> First, when using the system compiler, all works fine (but I am not sure of
>> the
>> binary compatibility with the Conda packages, that's why I want to use the
>> Anaconda compilers):
>>
>>     # create the environment and install XercesC
>>     $ conda create -n test-system xerces-c
>>     ...
>>     environment location:
>> /Users/smancill/.local/share/miniconda3/envs/test-system
>>     ...
>>     The following NEW packages will be INSTALLED:
>>
>>     icu:       58.2-h4b95b61_1
>>     libcxx:    4.0.1-h579ed51_0
>>     libcxxabi: 4.0.1-hebd6815_0
>>     xerces-c:  3.2.1-h44e365a_0
>>     ...
>>
>>     # activate the environment
>>     $ conda activate test-system
>>
>>     $ mkdir build-osx-system
>>     $ cd build-osx-system
>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
>> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>     -- The CXX compiler identification is AppleClang 9.0.0.9000039
>>     -- Check for working CXX compiler: /usr/bin/c++
>>     -- Check for working CXX compiler: /usr/bin/c++ -- works
>>     ...
>>     -- Found XercesC:
>> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
>> (found version "3.2.1")
>>     -- Configuring done
>>     -- Generating done
>>     -- Build files have been written to:
>> /Users/smancill/src/conda-test/build-osx-system
>>
>>     $ make -j1 VERBOSE=1
>>     ...
>>     [100%] Linking CXX executable bar
>>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
>> --verbose=1
>>     /usr/bin/c++   -isysroot
>> /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
>> -mmacosx-version-min=10.12 -Wl,-search_paths_first
>> -Wl,-headerpad_max_install_names  CMakeFiles/bar.dir/bar.cpp.o  -o bar
>> -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-system
>> -Wl,-rpath,/Users/smancill/.local/share/miniconda3/envs/test-system/lib
>> libfoo.dylib
>> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
>>     ...
>>
>> The build directory (~/src/conda-test/build-osx-system) and the conda
>> environment lib directory (~/.local/share/miniconda3/envs/test-system/lib)
>> are correctly added to the RPATH in the build tree by the link command:
>>
>>     $ ./bar
>>     Hello, world!
>>
>>     $ otool -L ./bar
>>     ./bar:
>>         @rpath/libfoo.dylib (compatibility version 1.0.0, current version
>> 0.0.0)
>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
>> version 0.0.0)
>>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
>> version 400.9.0)
>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> version 1252.0.0)
>>
>>     $ otool -l ./bar | grep -A2 LC_RPATH
>>             cmd LC_RPATH
>>         cmdsize 56
>>             path /Users/smancill/src/conda-test/build-osx-system (offset 12)
>>     --
>>             cmd LC_RPATH
>>         cmdsize 80
>>             path
>> /Users/smancill/.local/share/miniconda3/envs/test-system/lib (offset 12)
>>
>> If I install the binary, it fails because I haven't configured CMake to set
>> the install RPATH:
>>
>>     $ make install
>>     ...
>>     Install the project...
>>     -- Install configuration: ""
>>     -- Installing:
>> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libfoo.dylib
>>     -- Installing:
>> /Users/smancill/.local/share/miniconda3/envs/test-system/include/foo.hpp
>>     -- Installing:
>> /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar
>>
>>     $ bar
>>     dyld: Library not loaded: @rpath/libfoo.dylib
>>       Referenced from:
>> /Users/smancill/.local/share/miniconda4/envs/test-system/bin/bar
>>       Reason: image not found
>>     [1]    84611 abort      bar
>>
>>     $ otool -L $CONDA_PREFIX/bin/bar
>>     /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar:
>>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version
>> 0.0.0)
>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
>> version 0.0.0)
>>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
>> version 400.9.0)
>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> version 1252.0.0)
>>
>>     $ otool -l $CONDA_PREFIX/bin/bar | grep -A2 LC_RPATH
>>     # empty
>>
>>     # deactivate the environment to start again
>>     $ conda deactivate
>>
>> The same can be observed on Linux. Everything works as it should.
>>
>> --------------------------------------------------
>>
>> If I try to use Anaconda compilers on macOS, the build RPATH is not set
>> properly anymore:
>>
>>     # create the environment and install the Anaconda compiler for macOS,
>> and XercesC
>>     $ conda create -n test-conda clangxx_osx-64 xerces-c
>>     ...
>>     environment location:
>> /Users/smancill/.local/share/miniconda3/envs/test-conda
>>     ...
>>     The following NEW packages will be INSTALLED:
>>
>>         cctools:        895-h7512d6f_0
>>         clang:          4.0.1-h662ec87_0
>>         clang_osx-64:   4.0.1-h1ce6c1d_11
>>         clangxx:        4.0.1-hc9b4283_0
>>         clangxx_osx-64: 4.0.1-h22b1bf0_11
>>         compiler-rt:    4.0.1-h5487866_0
>>         icu:            58.2-h4b95b61_1
>>         ld64:           274.2-h7c2db76_0
>>         libcxx:         4.0.1-h579ed51_0
>>         libcxxabi:      4.0.1-hebd6815_0
>>         llvm:           4.0.1-hc748206_0
>>         llvm-lto-tapi:  4.0.1-h6701bc3_0
>>         xerces-c:       3.2.1-h44e365a_0
>>     ...
>>
>>     # activate the environment (which sets the variables to use the Anaconda
>> compiler)
>>     $ conda activate test-conda
>>
>>     $ mkdir build-osx-conda
>>     $ cd build-osx-conda
>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
>> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>     -- The CXX compiler identification is Clang 4.0.1
>>     -- Check for working CXX compiler:
>> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
>>     -- Check for working CXX compiler:
>> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
>> -- works
>>     ...
>>     -- Found XercesC:
>> /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
>> (found version "3.2.1")
>>     -- Configuring done
>>     -- Generating done
>>     -- Build files have been written to:
>> /Users/smancill/src/conda-test/build-osx-conda
>>
>>     $ make -j1 VERBOSE=1
>>     ...
>>     [100%] Linking CXX executable bar
>>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
>> --verbose=1
>>
>> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
>> -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE
>> -fstack-protector-strong -O2 -pipe -stdlib=libc++
>> -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isysroot
>> /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
>> -mmacosx-version-min=10.12 -Wl,-search_paths_first
>> -Wl,-headerpad_max_install_names -Wl,-pie -Wl,-headerpad_max_install_names
>> -Wl,-dead_strip_dylibs CMakeFiles/bar.dir/bar.cpp.o  -o bar
>> -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-conda libfoo.dylib
>> /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
>>     ...
>>
>> You can see that the environment lib path is not added to the RPATH by the
>> link command,
>> which in turns result in the executable not running from the build tree
>> anymore:
>>
>>     $ ./bar
>>     dyld: Library not loaded: @rpath/libxerces-c-3.2.dylib
>>       Referenced from: /Users/smancill/src/conda-test/build-osx-conda/./bar
>>       Reason: image not found
>>     [1]    89350 abort      ./bar
>>
>>     $ otool -L ./bar
>>     ./bar:
>>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version
>> 0.0.0)
>>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
>> version 0.0.0)
>>         @rpath/libc++.1.dylib (compatibility version 1.0.0, current version
>> 1.0.0)
>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
>> version 1252.0.0)
>>
>>     $ otool -l ./bar | grep -A2 LC_RPATH
>>           cmd LC_RPATH
>>       cmdsize 56
>>          path /Users/smancill/src/conda-test/build-osx-conda (offset 12)
>>
>>     # deactivate the environment
>>     $ conda deactivate
>>
>> --------------------------------------------------
>>
>> If I try the Anaconda compilers on Linux, there are strange results too:
>>
>>     # create the environment and install the Anaconda compiler for Linux,
>> and XercesC
>>     $ conda create -n test-conda gxx_linux-64 xerces-c
>>     ...
>>     environment location: /home/vagrant/miniconda3/envs/test-conda
>>     ...
>>     The following NEW packages will be INSTALLED:
>>
>>         binutils_impl_linux-64: 2.28.1-had2808c_3
>>         binutils_linux-64:      7.2.0-had2808c_27
>>         gcc_impl_linux-64:      7.2.0-habb00fd_3
>>         gcc_linux-64:           7.2.0-h550dcbe_27
>>         gxx_impl_linux-64:      7.2.0-hdf63c60_3
>>         gxx_linux-64:           7.2.0-h550dcbe_27
>>         icu:                    58.2-h9c2bf20_1
>>         libgcc-ng:              7.2.0-hdf63c60_3
>>         libstdcxx-ng:           7.2.0-hdf63c60_3
>>         xerces-c:               3.2.1-hac72e42_0
>>
>>     # activate the environment (which sets the variables to use the Anaconda
>> compiler)
>>     $ conda activate test-conda
>>
>>     $ mkdir build-linux-conda
>>     $ cd build-linux-conda
>>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
>> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>>     -- The CXX compiler identification is GNU 7.2.0
>>     -- Check for working CXX compiler:
>> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>>     -- Check for working CXX compiler:
>> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>> -- works
>>     ...
>>     -- Found XercesC:
>> /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so (found version
>> "3.2.1")
>>     -- Configuring done
>>     -- Generating done
>>     -- Build files have been written to:
>> /vagrant/conda-test/build-linux-conda
>>
>>     $ make -j1 VERBOSE=1
>>     ...
>>     [100%] Linking CXX executable bar
>>     /usr/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
>> --verbose=1
>>
>> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>> -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona
>> -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2
>> -pipe    -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now
>> CMakeFiles/bar.dir/bar.cpp.o  -o bar libfoo.so
>> /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so
>> -Wl,-rpath,/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:
>>     ...
>>
>> You can see that the environment lib path is added to the RPATH by the link
>> command (unlike macOS):
>>
>>     $ ./bar
>>     Hello World!
>>
>> But when inspecting the dependencies, the environment lib path appears
>> twice:
>>
>>     $ readelf -d ./bar
>>     ...
>>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>>      0x0000000000000001 (NEEDED)             Shared library:
>> [libxerces-c-3.2.so]
>>      0x0000000000000001 (NEEDED)             Shared library:
>> [libstdc++.so.6]
>>      0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
>>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>>      0x000000000000000f (RPATH)              Library rpath:
>> [/home/vagrant/miniconda3/envs/test-conda/lib:/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:]
>>     ...
>>
>> Which is wrong. Now the build tree binary will pick first any old version of
>> the foo library installed in the environment instead of the version in the
>> build tree.
>>
>> It seems that the Anaconda toolchain is setting the environment lib path
>> into
>> the RPATH by its own. It is also set when installing the binaries, even when
>> CMake is not configured to set the install RPATH:
>>
>>     $ make install
>>     ...
>>     Install the project...
>>     -- Install configuration: ""
>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/lib/libfoo.so
>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/include/foo.hpp
>>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/bin/bar
>>     -- Set runtime path of
>> "/home/vagrant/miniconda3/envs/test-conda/bin/bar" to ""
>>
>>     $ bar
>>     Hello World!
>>
>>     $ readelf -d $CONDA_PREFIX/bin/bar
>>     ...
>>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>>      0x0000000000000001 (NEEDED)             Shared library:
>> [libxerces-c-3.2.so]
>>      0x0000000000000001 (NEEDED)             Shared library:
>> [libstdc++.so.6]
>>      0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
>>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>>      0x000000000000000f (RPATH)              Library rpath:
>> [/home/vagrant/miniconda3/envs/test-conda/lib]
>>     ...
>>
>>     # deactivate the environment
>>     $ conda deactivate
>>
>> --------------------------------------------------
>>
>> TL;DR I cannot get CMake and the Anaconda compilers and packages working
>> correctly.
>>
>> - On macOS, the Conda environment library path is not added to the build
>> RPATH.
>> - On Linux, the Conda environment library path is always added to the RPATH
>>   (in both build and install) independently of CMake.
>>
>> Any advice or workarounds?
>>
>> --
>> Sebastian Mancilla
>>
>> --
>>
>> Powered by www.kitware.com
>>
>> Please keep messages on-topic and check the CMake FAQ at:
>> http://www.cmake.org/Wiki/CMake_FAQ
>>
>> Kitware offers various services to support the CMake community. For more
>> information on each offering, please visit:
>>
>> CMake Support: http://cmake.org/cmake/help/support.html
>> CMake Consulting: http://cmake.org/cmake/help/consulting.html
>> CMake Training Courses: http://cmake.org/cmake/help/training.html
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Follow this link to subscribe/unsubscribe:
>> https://cmake.org/mailman/listinfo/cmake
>>
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Issues trying to use the Anaconda compiler tools with CMake

Sebastián Mancilla
In reply to this post by Eric Noulard
My 5c: Docker is just too annoying to work with if you are targeting users to run your packages.

From the point of view of the final user of your "binary distribution" (some Docker image):

- You have to figure out / copy paste the proper docker command line to run the container (mount volumes, open ports, set environment, etc)
- It runs on a virtual machine if you are not in Linux
- How to run some graphical application?
- In Linux if you need to write some output files in the mounted volumen, they will have the wrong permissions, unless the image provides a fix for it.
- What if you need some extra package? Now you have to create your own image based on the distributed image.
- You are limited to the package versions available in the Linux distribution in which the image is based

Now consider conda:

conda create -n myenv meta-package
conda activate myenv
# run all binaries natively, they are already on PATH, access your file system, install extra packages, have all your command line tools and IDEs at hand.

From the point of view of doing development with Docker, my biggest gripe is how to edit the code while running it in the container. Say I have Vim in the host (or an IDE).
When editing the sources in the host, all dependencies and compilers are in the container, so I lose linting and compilation errors and autocompletion. I would also need to install again all my development tools in the container (say tmux, ag, jq, fzf etc).

Trying to do development while inside a Conda environment is something I think it should work, and I don't think conda-build is necessary until I am ready to create a package.
Unfortunately I hit the issue of this thread.

I have had no issues creating packages with conda-build and CMake so far, and I've packaged a few, including some Qt applications.

El mié., 15 de ago. de 2018 a la(s) 05:29, Eric Noulard ([hidden email]) escribió:


Le mar. 14 août 2018 à 20:38, Sebastián Mancilla <[hidden email]> a écrit :
I wanted to try Conda for normal day-to-day C++ development, while having all the dependencies isolated from other projects and the base system.

- Change the sources
- Build
- Run the tests
- Repeat

Hi Sebastian,

Just curious on why you would prefer conda over "real" container technology like docker or rkt for the kind of usage you describe ?
Do you ultimately want to distribute your software as conda packages?

I'm not proficient in conda but AFAIK docker (or rkt) offers easier/better isolation for the usage you describe.
The side-effect being that inside your container cmake should behave like as expected.
At least this is my own experience.

Some people even try to automatize the container creation out of conda packaged software:
I have no experience with that whatsoever, I usually craft my own dockerfile and work with that.

If your goal includes the distrubution of your software as conda package may be you can get in touch with people
at conda-forge: https://conda-forge.org/#about, I bet they build a lot of cmake-based projects in there and may
have experienced same caveats with the conda compilers usage.


--
Eric


--
Sebastian Mancilla Matta
CCTVal, UTFSM
Valparaíso, Chile

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Issues trying to use the Anaconda compiler tools with CMake

Ray Donnelly


On Wed, Aug 15, 2018, 3:05 PM Sebastián Mancilla <[hidden email]> wrote:
My 5c: Docker is just too annoying to work with if you are targeting users to run your packages.

From the point of view of the final user of your "binary distribution" (some Docker image):

- You have to figure out / copy paste the proper docker command line to run the container (mount volumes, open ports, set environment, etc)
- It runs on a virtual machine if you are not in Linux
- How to run some graphical application?
- In Linux if you need to write some output files in the mounted volumen, they will have the wrong permissions, unless the image provides a fix for it.
- What if you need some extra package? Now you have to create your own image based on the distributed image.
- You are limited to the package versions available in the Linux distribution in which the image is based

Now consider conda:

conda create -n myenv meta-package
conda activate myenv
# run all binaries natively, they are already on PATH, access your file system, install extra packages, have all your command line tools and IDEs at hand.

From the point of view of doing development with Docker, my biggest gripe is how to edit the code while running it in the container. Say I have Vim in the host (or an IDE).
When editing the sources in the host, all dependencies and compilers are in the container, so I lose linting and compilation errors and autocompletion. I would also need to install again all my development tools in the container (say tmux, ag, jq, fzf etc).

Trying to do development while inside a Conda environment is something I think it should work, and I don't think conda-build is necessary until I am ready to create a package.
Unfortunately I hit the issue of this thread.

I already explained how to workaround the issues you saw. The compilers do work in most normal situations, i use them extensively, even for linking to rust software (macOS and Linux), the only caveat being that you should instead so conda cdt packages on Linux for system library dependencies and on macOS you need to get an old SDK.

I have had no issues creating packages with conda-build and CMake so far, and I've packaged a few, including some Qt applications.

El mié., 15 de ago. de 2018 a la(s) 05:29, Eric Noulard ([hidden email]) escribió:


Le mar. 14 août 2018 à 20:38, Sebastián Mancilla <[hidden email]> a écrit :
I wanted to try Conda for normal day-to-day C++ development, while having all the dependencies isolated from other projects and the base system.

- Change the sources
- Build
- Run the tests
- Repeat

Hi Sebastian,

Just curious on why you would prefer conda over "real" container technology like docker or rkt for the kind of usage you describe ?
Do you ultimately want to distribute your software as conda packages?

I'm not proficient in conda but AFAIK docker (or rkt) offers easier/better isolation for the usage you describe.
The side-effect being that inside your container cmake should behave like as expected.
At least this is my own experience.

Some people even try to automatize the container creation out of conda packaged software:
I have no experience with that whatsoever, I usually craft my own dockerfile and work with that.

If your goal includes the distrubution of your software as conda package may be you can get in touch with people
at conda-forge: https://conda-forge.org/#about, I bet they build a lot of cmake-based projects in there and may
have experienced same caveats with the conda compilers usage.


--
Eric


--
Sebastian Mancilla Matta
CCTVal, UTFSM
Valparaíso, Chile

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Issues trying to use the Anaconda compiler tools with CMake

Sebastián Mancilla
In reply to this post by Ray Donnelly
I cannot use conda-build if I am developing. Consider that I will be editing the sources, compiling and running tests constantly. Going through the conda-build process every time I need to check some changes would be too much overhead. conda-build does a lot of things, it creates multiple new environments, and the build.sh script may run some commands that I only need when packaging.

Am I getting conda-build wrong? Is there some kind of development mode?

Also, the "tests" listed in the meta.yaml run with the installed version of the package. I need to run the unit tests. But unit tests are discouraged from being run in the build.sh script, to avoid extra CPU time in the CI servers when building the package (per conda-forge docs).

It would be great if CMake would not filter $CONDA_PREFIX from the build RPATH.

Well, I just doing this as experiment. I really think that using Conda for C++ development has a lot of potential, although it doesn't seem to have a lot of traction. Almost no clear results in Google, (but plenty of "Conda for Python" ofc). It seems to me that the main purpose of C++ packages is to be called from some Python/R code.

Just to clarify, I am pointing to distribute packages to people that would not only run the binaries. They will write some hundred lines of the ugliest C++ code that they will want to compile against the packages, and run from their tree ./my-code and get results. They don't need to create a package for that, they just want to compile and run the code. Also some of them would want to develop new packages to be part of the meta distribution, so that's why I am trying to figure out how to do C++ development within a Conda environment.

P.S. I checked gcc_impl_linux-64. I see I would need to set CC, CXX, LD by hand. Also, no clang_impl_osx-64 package.

El mié., 15 de ago. de 2018 a la(s) 07:44, Ray Donnelly ([hidden email]) escribió:
Hi Sebastián,

Without having time to properly go through this, I feel I should
correct some technical inaccuracies, but *all* of your issues can be
sidestepped by using conda-build. Installation and RPATHs are always
very tricky for projects to get right so we side step any issues here
by running post-build fixups on these things. We ensure RPATHs have
the opportunity to add our own, uniquify them (I think!), and make
them fully relative on macOS and Linux.

WRT RPATHs being added or not, we set LDFLAGs for RPATHs the linker
activation script *when run under conda-build*. If you want to fake
that so you get the exact same flags that are used to compile our
packages do: CONDA_BUILD=1 conda activate envname. If you don't set
CONDA_BUILD=1 then it'll set all flags *except* -I${PREFIX}/include,
-L${PREFIX}/lib and -Wl,-rpath,${PREFIX}/lib.

If you want to use our compilers in their completely 'raw' form (of
course you could unset LDFLAGS, CFLAGS, CPPFLAGS too), then install
e.g. gcc_impl_linux-64 instead of gcc_linux-64 which really are
helpers for interfacing the raw compilers with conda-build (and
setting good default compilation flags for security and performance
reasons).

You mentioned using [DY]LD_LIBRARY_PATH, I would caution no one to do
this ever outside of development workflows. FWIW, we run into lots of
trouble with LD_LIBRARY_PATH and I am *firmly* in the camp that
LD_LIBRARY_PATH is harmful (i.e. never use it systematically) and I am
utterly convinced that DT_RUNPATH is a huge mistake. We actually
consider detection of DT_RUNPATH in any of our DSOs or exes an error
condition and only allow DT_RPATH. We just had so many bugs due to the
wrong libs being used by end users due to this, for example there is
no way a Qt application linked against our Qt libs is going to be
happy with some random system Qt library that's been interposed.

For macOS, you should also set CONDA_BUILD_SYSROOT=<somewhere that
macOS 10.9, 10.10 or 10.11 SDK> (depending on the macOS version you
want to target). These old SDKs can be gotten from old Xcode builds
and also on github. Unfortunately the compilers are not compatible
with the new .tbd file format used in newer SDKs and by the newest
Apple system linker and the source to enable that has not been
released yet (there have been no new source drops for Apple's ld64 in
a while).

But please, just use conda-build! While we try to keep them working in
as many situations as we can, these tools are primarily focussed
around conda-build and the technical decisions we make with respect to
them will be from that perspective.

Hope this helps some?

 Fri, Aug 10, 2018 at 10:48 PM, Sebastián Mancilla <[hidden email]> wrote:
> I am trying to use Conda as a package manager for isolated C++ development
> environments. But unfortunately, when using CMake with the Anaconda-provided
> compilers [1] (which are used to compile the binary packages in the Anaconda
> repositories), things do not work as expected.
>
> I have a small test case available here [2], with an executable calling a
> shared library and a third-party dependency installed with Conda.
>
> [1]:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__conda.io_docs_user-2Dguide_tasks_build-2Dpackages_compiler-2Dtools.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=9ibJ6jRrwBMZIKheWzEMloZyY7BC5CuzHHPAKWlL37Q&e=
> [2]: https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_smancill_b28ca07ac11fdf285b4d559545a1630b&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=kyMaMU1dzC_OC1KzWIrkZoymXxkiWxELh37yJ4vd028&e=
>
> --------------------------------------------------
>
> First, when using the system compiler, all works fine (but I am not sure of
> the
> binary compatibility with the Conda packages, that's why I want to use the
> Anaconda compilers):
>
>     # create the environment and install XercesC
>     $ conda create -n test-system xerces-c
>     ...
>     environment location:
> /Users/smancill/.local/share/miniconda3/envs/test-system
>     ...
>     The following NEW packages will be INSTALLED:
>
>     icu:       58.2-h4b95b61_1
>     libcxx:    4.0.1-h579ed51_0
>     libcxxabi: 4.0.1-hebd6815_0
>     xerces-c:  3.2.1-h44e365a_0
>     ...
>
>     # activate the environment
>     $ conda activate test-system
>
>     $ mkdir build-osx-system
>     $ cd build-osx-system
>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>     -- The CXX compiler identification is AppleClang 9.0.0.9000039
>     -- Check for working CXX compiler: /usr/bin/c++
>     -- Check for working CXX compiler: /usr/bin/c++ -- works
>     ...
>     -- Found XercesC:
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
> (found version "3.2.1")
>     -- Configuring done
>     -- Generating done
>     -- Build files have been written to:
> /Users/smancill/src/conda-test/build-osx-system
>
>     $ make -j1 VERBOSE=1
>     ...
>     [100%] Linking CXX executable bar
>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
> --verbose=1
>     /usr/bin/c++   -isysroot
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
> -mmacosx-version-min=10.12 -Wl,-search_paths_first
> -Wl,-headerpad_max_install_names  CMakeFiles/bar.dir/bar.cpp.o  -o bar
> -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-system
> -Wl,-rpath,/Users/smancill/.local/share/miniconda3/envs/test-system/lib
> libfoo.dylib
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
>     ...
>
> The build directory (~/src/conda-test/build-osx-system) and the conda
> environment lib directory (~/.local/share/miniconda3/envs/test-system/lib)
> are correctly added to the RPATH in the build tree by the link command:
>
>     $ ./bar
>     Hello, world!
>
>     $ otool -L ./bar
>     ./bar:
>         @rpath/libfoo.dylib (compatibility version 1.0.0, current version
> 0.0.0)
>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
> version 0.0.0)
>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
> version 400.9.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1252.0.0)
>
>     $ otool -l ./bar | grep -A2 LC_RPATH
>             cmd LC_RPATH
>         cmdsize 56
>             path /Users/smancill/src/conda-test/build-osx-system (offset 12)
>     --
>             cmd LC_RPATH
>         cmdsize 80
>             path
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib (offset 12)
>
> If I install the binary, it fails because I haven't configured CMake to set
> the install RPATH:
>
>     $ make install
>     ...
>     Install the project...
>     -- Install configuration: ""
>     -- Installing:
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libfoo.dylib
>     -- Installing:
> /Users/smancill/.local/share/miniconda3/envs/test-system/include/foo.hpp
>     -- Installing:
> /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar
>
>     $ bar
>     dyld: Library not loaded: @rpath/libfoo.dylib
>       Referenced from:
> /Users/smancill/.local/share/miniconda4/envs/test-system/bin/bar
>       Reason: image not found
>     [1]    84611 abort      bar
>
>     $ otool -L $CONDA_PREFIX/bin/bar
>     /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar:
>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version
> 0.0.0)
>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
> version 0.0.0)
>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
> version 400.9.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1252.0.0)
>
>     $ otool -l $CONDA_PREFIX/bin/bar | grep -A2 LC_RPATH
>     # empty
>
>     # deactivate the environment to start again
>     $ conda deactivate
>
> The same can be observed on Linux. Everything works as it should.
>
> --------------------------------------------------
>
> If I try to use Anaconda compilers on macOS, the build RPATH is not set
> properly anymore:
>
>     # create the environment and install the Anaconda compiler for macOS,
> and XercesC
>     $ conda create -n test-conda clangxx_osx-64 xerces-c
>     ...
>     environment location:
> /Users/smancill/.local/share/miniconda3/envs/test-conda
>     ...
>     The following NEW packages will be INSTALLED:
>
>         cctools:        895-h7512d6f_0
>         clang:          4.0.1-h662ec87_0
>         clang_osx-64:   4.0.1-h1ce6c1d_11
>         clangxx:        4.0.1-hc9b4283_0
>         clangxx_osx-64: 4.0.1-h22b1bf0_11
>         compiler-rt:    4.0.1-h5487866_0
>         icu:            58.2-h4b95b61_1
>         ld64:           274.2-h7c2db76_0
>         libcxx:         4.0.1-h579ed51_0
>         libcxxabi:      4.0.1-hebd6815_0
>         llvm:           4.0.1-hc748206_0
>         llvm-lto-tapi:  4.0.1-h6701bc3_0
>         xerces-c:       3.2.1-h44e365a_0
>     ...
>
>     # activate the environment (which sets the variables to use the Anaconda
> compiler)
>     $ conda activate test-conda
>
>     $ mkdir build-osx-conda
>     $ cd build-osx-conda
>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>     -- The CXX compiler identification is Clang 4.0.1
>     -- Check for working CXX compiler:
> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
>     -- Check for working CXX compiler:
> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
> -- works
>     ...
>     -- Found XercesC:
> /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
> (found version "3.2.1")
>     -- Configuring done
>     -- Generating done
>     -- Build files have been written to:
> /Users/smancill/src/conda-test/build-osx-conda
>
>     $ make -j1 VERBOSE=1
>     ...
>     [100%] Linking CXX executable bar
>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
> --verbose=1
>
> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
> -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE
> -fstack-protector-strong -O2 -pipe -stdlib=libc++
> -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isysroot
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
> -mmacosx-version-min=10.12 -Wl,-search_paths_first
> -Wl,-headerpad_max_install_names -Wl,-pie -Wl,-headerpad_max_install_names
> -Wl,-dead_strip_dylibs CMakeFiles/bar.dir/bar.cpp.o  -o bar
> -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-conda libfoo.dylib
> /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
>     ...
>
> You can see that the environment lib path is not added to the RPATH by the
> link command,
> which in turns result in the executable not running from the build tree
> anymore:
>
>     $ ./bar
>     dyld: Library not loaded: @rpath/libxerces-c-3.2.dylib
>       Referenced from: /Users/smancill/src/conda-test/build-osx-conda/./bar
>       Reason: image not found
>     [1]    89350 abort      ./bar
>
>     $ otool -L ./bar
>     ./bar:
>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version
> 0.0.0)
>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
> version 0.0.0)
>         @rpath/libc++.1.dylib (compatibility version 1.0.0, current version
> 1.0.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1252.0.0)
>
>     $ otool -l ./bar | grep -A2 LC_RPATH
>           cmd LC_RPATH
>       cmdsize 56
>          path /Users/smancill/src/conda-test/build-osx-conda (offset 12)
>
>     # deactivate the environment
>     $ conda deactivate
>
> --------------------------------------------------
>
> If I try the Anaconda compilers on Linux, there are strange results too:
>
>     # create the environment and install the Anaconda compiler for Linux,
> and XercesC
>     $ conda create -n test-conda gxx_linux-64 xerces-c
>     ...
>     environment location: /home/vagrant/miniconda3/envs/test-conda
>     ...
>     The following NEW packages will be INSTALLED:
>
>         binutils_impl_linux-64: 2.28.1-had2808c_3
>         binutils_linux-64:      7.2.0-had2808c_27
>         gcc_impl_linux-64:      7.2.0-habb00fd_3
>         gcc_linux-64:           7.2.0-h550dcbe_27
>         gxx_impl_linux-64:      7.2.0-hdf63c60_3
>         gxx_linux-64:           7.2.0-h550dcbe_27
>         icu:                    58.2-h9c2bf20_1
>         libgcc-ng:              7.2.0-hdf63c60_3
>         libstdcxx-ng:           7.2.0-hdf63c60_3
>         xerces-c:               3.2.1-hac72e42_0
>
>     # activate the environment (which sets the variables to use the Anaconda
> compiler)
>     $ conda activate test-conda
>
>     $ mkdir build-linux-conda
>     $ cd build-linux-conda
>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>     -- The CXX compiler identification is GNU 7.2.0
>     -- Check for working CXX compiler:
> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>     -- Check for working CXX compiler:
> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
> -- works
>     ...
>     -- Found XercesC:
> /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so (found version
> "3.2.1")
>     -- Configuring done
>     -- Generating done
>     -- Build files have been written to:
> /vagrant/conda-test/build-linux-conda
>
>     $ make -j1 VERBOSE=1
>     ...
>     [100%] Linking CXX executable bar
>     /usr/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
> --verbose=1
>
> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
> -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona
> -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2
> -pipe    -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now
> CMakeFiles/bar.dir/bar.cpp.o  -o bar libfoo.so
> /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so
> -Wl,-rpath,/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:
>     ...
>
> You can see that the environment lib path is added to the RPATH by the link
> command (unlike macOS):
>
>     $ ./bar
>     Hello World!
>
> But when inspecting the dependencies, the environment lib path appears
> twice:
>
>     $ readelf -d ./bar
>     ...
>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>      0x0000000000000001 (NEEDED)             Shared library:
> [libxerces-c-3.2.so]
>      0x0000000000000001 (NEEDED)             Shared library:
> [libstdc++.so.6]
>      0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>      0x000000000000000f (RPATH)              Library rpath:
> [/home/vagrant/miniconda3/envs/test-conda/lib:/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:]
>     ...
>
> Which is wrong. Now the build tree binary will pick first any old version of
> the foo library installed in the environment instead of the version in the
> build tree.
>
> It seems that the Anaconda toolchain is setting the environment lib path
> into
> the RPATH by its own. It is also set when installing the binaries, even when
> CMake is not configured to set the install RPATH:
>
>     $ make install
>     ...
>     Install the project...
>     -- Install configuration: ""
>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/lib/libfoo.so
>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/include/foo.hpp
>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/bin/bar
>     -- Set runtime path of
> "/home/vagrant/miniconda3/envs/test-conda/bin/bar" to ""
>
>     $ bar
>     Hello World!
>
>     $ readelf -d $CONDA_PREFIX/bin/bar
>     ...
>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>      0x0000000000000001 (NEEDED)             Shared library:
> [libxerces-c-3.2.so]
>      0x0000000000000001 (NEEDED)             Shared library:
> [libstdc++.so.6]
>      0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>      0x000000000000000f (RPATH)              Library rpath:
> [/home/vagrant/miniconda3/envs/test-conda/lib]
>     ...
>
>     # deactivate the environment
>     $ conda deactivate
>
> --------------------------------------------------
>
> TL;DR I cannot get CMake and the Anaconda compilers and packages working
> correctly.
>
> - On macOS, the Conda environment library path is not added to the build
> RPATH.
> - On Linux, the Conda environment library path is always added to the RPATH
>   (in both build and install) independently of CMake.
>
> Any advice or workarounds?
>
> --
> Sebastian Mancilla
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cmake.org_Wiki_CMake-5FFAQ&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=GdelxyoZgjgUDZpZLYDRX5TB7K8bnH7ivyB0EBiNAoQ&e=
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_support.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=QbSbBtc-GMz--7tKjKNG-nRFY53D4mceuDjrWNci7Sc&e=
> CMake Consulting: https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_consulting.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=LhGhXtC3-JaFI20UkcWMEw8QZpYNTDT5e2vJhuKjan4&e=
> CMake Training Courses: https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_training.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=oou7JfZWiRu6hUMB0_vo_Bjb_DLWjsmePAz_1CrVzQA&e=
>
> Visit other Kitware open-source projects at
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=3MJhnhS7Ki2a8XfbvcYt0oMlt0ctGc1FnXvv4ZBD_mE&e=
>
> Follow this link to subscribe/unsubscribe:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__cmake.org_mailman_listinfo_cmake&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=W0QwY-pUUOH_XmHdxssgWgGDWsF6xuqD7UvjH8ApONc&e=
>


--
Sebastian Mancilla Matta
CCTVal, UTFSM
Valparaíso, Chile

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake
Reply | Threaded
Open this post in threaded view
|

Re: Issues trying to use the Anaconda compiler tools with CMake

Michael Sarahan
conda-build maintainer here.  I agree that having conda/conda-build as a provisioner for general-purpose build environments would be helpful.  I'm afraid I don't understand what's missing or otherwise needs to change here, though.  If you have concrete suggestions (and better, PRs) for how to make conda, conda-build, our compilers, or cmake work better in this capacity, we'd be happy to talk more with you on our issue tracker.


On Wed, Aug 15, 2018 at 9:33 AM Sebastián Mancilla <[hidden email]> wrote:
I cannot use conda-build if I am developing. Consider that I will be editing the sources, compiling and running tests constantly. Going through the conda-build process every time I need to check some changes would be too much overhead. conda-build does a lot of things, it creates multiple new environments, and the build.sh script may run some commands that I only need when packaging.

Am I getting conda-build wrong? Is there some kind of development mode?

Also, the "tests" listed in the meta.yaml run with the installed version of the package. I need to run the unit tests. But unit tests are discouraged from being run in the build.sh script, to avoid extra CPU time in the CI servers when building the package (per conda-forge docs).

It would be great if CMake would not filter $CONDA_PREFIX from the build RPATH.

Well, I just doing this as experiment. I really think that using Conda for C++ development has a lot of potential, although it doesn't seem to have a lot of traction. Almost no clear results in Google, (but plenty of "Conda for Python" ofc). It seems to me that the main purpose of C++ packages is to be called from some Python/R code.

Just to clarify, I am pointing to distribute packages to people that would not only run the binaries. They will write some hundred lines of the ugliest C++ code that they will want to compile against the packages, and run from their tree ./my-code and get results. They don't need to create a package for that, they just want to compile and run the code. Also some of them would want to develop new packages to be part of the meta distribution, so that's why I am trying to figure out how to do C++ development within a Conda environment.

P.S. I checked gcc_impl_linux-64. I see I would need to set CC, CXX, LD by hand. Also, no clang_impl_osx-64 package.

El mié., 15 de ago. de 2018 a la(s) 07:44, Ray Donnelly ([hidden email]) escribió:
Hi Sebastián,

Without having time to properly go through this, I feel I should
correct some technical inaccuracies, but *all* of your issues can be
sidestepped by using conda-build. Installation and RPATHs are always
very tricky for projects to get right so we side step any issues here
by running post-build fixups on these things. We ensure RPATHs have
the opportunity to add our own, uniquify them (I think!), and make
them fully relative on macOS and Linux.

WRT RPATHs being added or not, we set LDFLAGs for RPATHs the linker
activation script *when run under conda-build*. If you want to fake
that so you get the exact same flags that are used to compile our
packages do: CONDA_BUILD=1 conda activate envname. If you don't set
CONDA_BUILD=1 then it'll set all flags *except* -I${PREFIX}/include,
-L${PREFIX}/lib and -Wl,-rpath,${PREFIX}/lib.

If you want to use our compilers in their completely 'raw' form (of
course you could unset LDFLAGS, CFLAGS, CPPFLAGS too), then install
e.g. gcc_impl_linux-64 instead of gcc_linux-64 which really are
helpers for interfacing the raw compilers with conda-build (and
setting good default compilation flags for security and performance
reasons).

You mentioned using [DY]LD_LIBRARY_PATH, I would caution no one to do
this ever outside of development workflows. FWIW, we run into lots of
trouble with LD_LIBRARY_PATH and I am *firmly* in the camp that
LD_LIBRARY_PATH is harmful (i.e. never use it systematically) and I am
utterly convinced that DT_RUNPATH is a huge mistake. We actually
consider detection of DT_RUNPATH in any of our DSOs or exes an error
condition and only allow DT_RPATH. We just had so many bugs due to the
wrong libs being used by end users due to this, for example there is
no way a Qt application linked against our Qt libs is going to be
happy with some random system Qt library that's been interposed.

For macOS, you should also set CONDA_BUILD_SYSROOT=<somewhere that
macOS 10.9, 10.10 or 10.11 SDK> (depending on the macOS version you
want to target). These old SDKs can be gotten from old Xcode builds
and also on github. Unfortunately the compilers are not compatible
with the new .tbd file format used in newer SDKs and by the newest
Apple system linker and the source to enable that has not been
released yet (there have been no new source drops for Apple's ld64 in
a while).

But please, just use conda-build! While we try to keep them working in
as many situations as we can, these tools are primarily focussed
around conda-build and the technical decisions we make with respect to
them will be from that perspective.

Hope this helps some?

 Fri, Aug 10, 2018 at 10:48 PM, Sebastián Mancilla <[hidden email]> wrote:
> I am trying to use Conda as a package manager for isolated C++ development
> environments. But unfortunately, when using CMake with the Anaconda-provided
> compilers [1] (which are used to compile the binary packages in the Anaconda
> repositories), things do not work as expected.
>
> I have a small test case available here [2], with an executable calling a
> shared library and a third-party dependency installed with Conda.
>
> [1]:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__conda.io_docs_user-2Dguide_tasks_build-2Dpackages_compiler-2Dtools.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=9ibJ6jRrwBMZIKheWzEMloZyY7BC5CuzHHPAKWlL37Q&e=
> [2]: https://urldefense.proofpoint.com/v2/url?u=https-3A__gist.github.com_smancill_b28ca07ac11fdf285b4d559545a1630b&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=kyMaMU1dzC_OC1KzWIrkZoymXxkiWxELh37yJ4vd028&e=
>
> --------------------------------------------------
>
> First, when using the system compiler, all works fine (but I am not sure of
> the
> binary compatibility with the Conda packages, that's why I want to use the
> Anaconda compilers):
>
>     # create the environment and install XercesC
>     $ conda create -n test-system xerces-c
>     ...
>     environment location:
> /Users/smancill/.local/share/miniconda3/envs/test-system
>     ...
>     The following NEW packages will be INSTALLED:
>
>     icu:       58.2-h4b95b61_1
>     libcxx:    4.0.1-h579ed51_0
>     libcxxabi: 4.0.1-hebd6815_0
>     xerces-c:  3.2.1-h44e365a_0
>     ...
>
>     # activate the environment
>     $ conda activate test-system
>
>     $ mkdir build-osx-system
>     $ cd build-osx-system
>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>     -- The CXX compiler identification is AppleClang 9.0.0.9000039
>     -- Check for working CXX compiler: /usr/bin/c++
>     -- Check for working CXX compiler: /usr/bin/c++ -- works
>     ...
>     -- Found XercesC:
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
> (found version "3.2.1")
>     -- Configuring done
>     -- Generating done
>     -- Build files have been written to:
> /Users/smancill/src/conda-test/build-osx-system
>
>     $ make -j1 VERBOSE=1
>     ...
>     [100%] Linking CXX executable bar
>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
> --verbose=1
>     /usr/bin/c++   -isysroot
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
> -mmacosx-version-min=10.12 -Wl,-search_paths_first
> -Wl,-headerpad_max_install_names  CMakeFiles/bar.dir/bar.cpp.o  -o bar
> -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-system
> -Wl,-rpath,/Users/smancill/.local/share/miniconda3/envs/test-system/lib
> libfoo.dylib
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libxerces-c.dylib
>     ...
>
> The build directory (~/src/conda-test/build-osx-system) and the conda
> environment lib directory (~/.local/share/miniconda3/envs/test-system/lib)
> are correctly added to the RPATH in the build tree by the link command:
>
>     $ ./bar
>     Hello, world!
>
>     $ otool -L ./bar
>     ./bar:
>         @rpath/libfoo.dylib (compatibility version 1.0.0, current version
> 0.0.0)
>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
> version 0.0.0)
>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
> version 400.9.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1252.0.0)
>
>     $ otool -l ./bar | grep -A2 LC_RPATH
>             cmd LC_RPATH
>         cmdsize 56
>             path /Users/smancill/src/conda-test/build-osx-system (offset 12)
>     --
>             cmd LC_RPATH
>         cmdsize 80
>             path
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib (offset 12)
>
> If I install the binary, it fails because I haven't configured CMake to set
> the install RPATH:
>
>     $ make install
>     ...
>     Install the project...
>     -- Install configuration: ""
>     -- Installing:
> /Users/smancill/.local/share/miniconda3/envs/test-system/lib/libfoo.dylib
>     -- Installing:
> /Users/smancill/.local/share/miniconda3/envs/test-system/include/foo.hpp
>     -- Installing:
> /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar
>
>     $ bar
>     dyld: Library not loaded: @rpath/libfoo.dylib
>       Referenced from:
> /Users/smancill/.local/share/miniconda4/envs/test-system/bin/bar
>       Reason: image not found
>     [1]    84611 abort      bar
>
>     $ otool -L $CONDA_PREFIX/bin/bar
>     /Users/smancill/.local/share/miniconda3/envs/test-system/bin/bar:
>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version
> 0.0.0)
>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
> version 0.0.0)
>         /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
> version 400.9.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1252.0.0)
>
>     $ otool -l $CONDA_PREFIX/bin/bar | grep -A2 LC_RPATH
>     # empty
>
>     # deactivate the environment to start again
>     $ conda deactivate
>
> The same can be observed on Linux. Everything works as it should.
>
> --------------------------------------------------
>
> If I try to use Anaconda compilers on macOS, the build RPATH is not set
> properly anymore:
>
>     # create the environment and install the Anaconda compiler for macOS,
> and XercesC
>     $ conda create -n test-conda clangxx_osx-64 xerces-c
>     ...
>     environment location:
> /Users/smancill/.local/share/miniconda3/envs/test-conda
>     ...
>     The following NEW packages will be INSTALLED:
>
>         cctools:        895-h7512d6f_0
>         clang:          4.0.1-h662ec87_0
>         clang_osx-64:   4.0.1-h1ce6c1d_11
>         clangxx:        4.0.1-hc9b4283_0
>         clangxx_osx-64: 4.0.1-h22b1bf0_11
>         compiler-rt:    4.0.1-h5487866_0
>         icu:            58.2-h4b95b61_1
>         ld64:           274.2-h7c2db76_0
>         libcxx:         4.0.1-h579ed51_0
>         libcxxabi:      4.0.1-hebd6815_0
>         llvm:           4.0.1-hc748206_0
>         llvm-lto-tapi:  4.0.1-h6701bc3_0
>         xerces-c:       3.2.1-h44e365a_0
>     ...
>
>     # activate the environment (which sets the variables to use the Anaconda
> compiler)
>     $ conda activate test-conda
>
>     $ mkdir build-osx-conda
>     $ cd build-osx-conda
>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>     -- The CXX compiler identification is Clang 4.0.1
>     -- Check for working CXX compiler:
> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
>     -- Check for working CXX compiler:
> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
> -- works
>     ...
>     -- Found XercesC:
> /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
> (found version "3.2.1")
>     -- Configuring done
>     -- Generating done
>     -- Build files have been written to:
> /Users/smancill/src/conda-test/build-osx-conda
>
>     $ make -j1 VERBOSE=1
>     ...
>     [100%] Linking CXX executable bar
>     /usr/local/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
> --verbose=1
>
> /Users/smancill/.local/share/miniconda3/envs/test-conda/bin/x86_64-apple-darwin13.4.0-clang++
> -march=core2 -mtune=haswell -mssse3 -ftree-vectorize -fPIC -fPIE
> -fstack-protector-strong -O2 -pipe -stdlib=libc++
> -fvisibility-inlines-hidden -std=c++14 -fmessage-length=0 -isysroot
> /Library/Developer/CommandLineTools/SDKs/MacOSX10.13.sdk
> -mmacosx-version-min=10.12 -Wl,-search_paths_first
> -Wl,-headerpad_max_install_names -Wl,-pie -Wl,-headerpad_max_install_names
> -Wl,-dead_strip_dylibs CMakeFiles/bar.dir/bar.cpp.o  -o bar
> -Wl,-rpath,/Users/smancill/src/conda-test/build-osx-conda libfoo.dylib
> /Users/smancill/.local/share/miniconda3/envs/test-conda/lib/libxerces-c.dylib
>     ...
>
> You can see that the environment lib path is not added to the RPATH by the
> link command,
> which in turns result in the executable not running from the build tree
> anymore:
>
>     $ ./bar
>     dyld: Library not loaded: @rpath/libxerces-c-3.2.dylib
>       Referenced from: /Users/smancill/src/conda-test/build-osx-conda/./bar
>       Reason: image not found
>     [1]    89350 abort      ./bar
>
>     $ otool -L ./bar
>     ./bar:
>         @rpath/libfoo.dylib (compatibility version 0.0.0, current version
> 0.0.0)
>         @rpath/libxerces-c-3.2.dylib (compatibility version 0.0.0, current
> version 0.0.0)
>         @rpath/libc++.1.dylib (compatibility version 1.0.0, current version
> 1.0.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1252.0.0)
>
>     $ otool -l ./bar | grep -A2 LC_RPATH
>           cmd LC_RPATH
>       cmdsize 56
>          path /Users/smancill/src/conda-test/build-osx-conda (offset 12)
>
>     # deactivate the environment
>     $ conda deactivate
>
> --------------------------------------------------
>
> If I try the Anaconda compilers on Linux, there are strange results too:
>
>     # create the environment and install the Anaconda compiler for Linux,
> and XercesC
>     $ conda create -n test-conda gxx_linux-64 xerces-c
>     ...
>     environment location: /home/vagrant/miniconda3/envs/test-conda
>     ...
>     The following NEW packages will be INSTALLED:
>
>         binutils_impl_linux-64: 2.28.1-had2808c_3
>         binutils_linux-64:      7.2.0-had2808c_27
>         gcc_impl_linux-64:      7.2.0-habb00fd_3
>         gcc_linux-64:           7.2.0-h550dcbe_27
>         gxx_impl_linux-64:      7.2.0-hdf63c60_3
>         gxx_linux-64:           7.2.0-h550dcbe_27
>         icu:                    58.2-h9c2bf20_1
>         libgcc-ng:              7.2.0-hdf63c60_3
>         libstdcxx-ng:           7.2.0-hdf63c60_3
>         xerces-c:               3.2.1-hac72e42_0
>
>     # activate the environment (which sets the variables to use the Anaconda
> compiler)
>     $ conda activate test-conda
>
>     $ mkdir build-linux-conda
>     $ cd build-linux-conda
>     $ cmake -DCMAKE_INSTALL_PREFIX=$CONDA_PREFIX
> -DCMAKE_PREFIX_PATH=$CONDA_PREFIX ..
>     -- The CXX compiler identification is GNU 7.2.0
>     -- Check for working CXX compiler:
> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
>     -- Check for working CXX compiler:
> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
> -- works
>     ...
>     -- Found XercesC:
> /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so (found version
> "3.2.1")
>     -- Configuring done
>     -- Generating done
>     -- Build files have been written to:
> /vagrant/conda-test/build-linux-conda
>
>     $ make -j1 VERBOSE=1
>     ...
>     [100%] Linking CXX executable bar
>     /usr/bin/cmake -E cmake_link_script CMakeFiles/bar.dir/link.txt
> --verbose=1
>
> /home/vagrant/miniconda3/envs/test-conda/bin/x86_64-conda_cos6-linux-gnu-c++
> -fvisibility-inlines-hidden -std=c++17 -fmessage-length=0 -march=nocona
> -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2
> -pipe    -Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now
> CMakeFiles/bar.dir/bar.cpp.o  -o bar libfoo.so
> /home/vagrant/miniconda3/envs/test-conda/lib/libxerces-c.so
> -Wl,-rpath,/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:
>     ...
>
> You can see that the environment lib path is added to the RPATH by the link
> command (unlike macOS):
>
>     $ ./bar
>     Hello World!
>
> But when inspecting the dependencies, the environment lib path appears
> twice:
>
>     $ readelf -d ./bar
>     ...
>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>      0x0000000000000001 (NEEDED)             Shared library:
> [libxerces-c-3.2.so]
>      0x0000000000000001 (NEEDED)             Shared library:
> [libstdc++.so.6]
>      0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>      0x000000000000000f (RPATH)              Library rpath:
> [/home/vagrant/miniconda3/envs/test-conda/lib:/vagrant/conda-test/build-linux-conda:/home/vagrant/miniconda3/envs/test-conda/lib:]
>     ...
>
> Which is wrong. Now the build tree binary will pick first any old version of
> the foo library installed in the environment instead of the version in the
> build tree.
>
> It seems that the Anaconda toolchain is setting the environment lib path
> into
> the RPATH by its own. It is also set when installing the binaries, even when
> CMake is not configured to set the install RPATH:
>
>     $ make install
>     ...
>     Install the project...
>     -- Install configuration: ""
>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/lib/libfoo.so
>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/include/foo.hpp
>     -- Installing: /home/vagrant/miniconda3/envs/test-conda/bin/bar
>     -- Set runtime path of
> "/home/vagrant/miniconda3/envs/test-conda/bin/bar" to ""
>
>     $ bar
>     Hello World!
>
>     $ readelf -d $CONDA_PREFIX/bin/bar
>     ...
>      0x0000000000000001 (NEEDED)             Shared library: [libfoo.so]
>      0x0000000000000001 (NEEDED)             Shared library:
> [libxerces-c-3.2.so]
>      0x0000000000000001 (NEEDED)             Shared library:
> [libstdc++.so.6]
>      0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
>      0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>      0x000000000000000f (RPATH)              Library rpath:
> [/home/vagrant/miniconda3/envs/test-conda/lib]
>     ...
>
>     # deactivate the environment
>     $ conda deactivate
>
> --------------------------------------------------
>
> TL;DR I cannot get CMake and the Anaconda compilers and packages working
> correctly.
>
> - On macOS, the Conda environment library path is not added to the build
> RPATH.
> - On Linux, the Conda environment library path is always added to the RPATH
>   (in both build and install) independently of CMake.
>
> Any advice or workarounds?
>
> --
> Sebastian Mancilla
>
> --
>
> Powered by www.kitware.com
>
> Please keep messages on-topic and check the CMake FAQ at:
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.cmake.org_Wiki_CMake-5FFAQ&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=GdelxyoZgjgUDZpZLYDRX5TB7K8bnH7ivyB0EBiNAoQ&e=
>
> Kitware offers various services to support the CMake community. For more
> information on each offering, please visit:
>
> CMake Support: https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_support.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=QbSbBtc-GMz--7tKjKNG-nRFY53D4mceuDjrWNci7Sc&e=
> CMake Consulting: https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_consulting.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=LhGhXtC3-JaFI20UkcWMEw8QZpYNTDT5e2vJhuKjan4&e=
> CMake Training Courses: https://urldefense.proofpoint.com/v2/url?u=http-3A__cmake.org_cmake_help_training.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=oou7JfZWiRu6hUMB0_vo_Bjb_DLWjsmePAz_1CrVzQA&e=
>
> Visit other Kitware open-source projects at
> https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kitware.com_opensource_opensource.html&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=3MJhnhS7Ki2a8XfbvcYt0oMlt0ctGc1FnXvv4ZBD_mE&e=
>
> Follow this link to subscribe/unsubscribe:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__cmake.org_mailman_listinfo_cmake&d=DwIFaQ&c=lz9TcOasaINaaC3U7FbMev2lsutwpI4--09aP8Lu18s&r=8hmSv9ww5s9qu3iT8h5WMi8-YcKXaJvelxT3fMih7S4&m=yJC8JYc6vz5iLZ9uvPSIL0hSyOCRBucgCWXee5u73nk&s=W0QwY-pUUOH_XmHdxssgWgGDWsF6xuqD7UvjH8ApONc&e=
>


--
Sebastian Mancilla Matta
CCTVal, UTFSM
Valparaíso, Chile
--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake

--

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
https://cmake.org/mailman/listinfo/cmake