conda-forge / stir-feedstock Goto Github PK

CUDA 10.2 has already been dropped in conda-forge. So it should be safe to drop this

Also cudatoolkit only applies on CUDA 11. So this could have a selector to limit to CUDA 11

Lastly it may be worthwhile to add a cuda-version dependency in host & run to align packages with a specific CUDA version for installing

host:
    ...
    - cuda-version {{ cuda_compiler_version }}  # [(cuda_compiler_version or "None") != "None"]
  run:
    ...
    - cuda-version {{ cuda_compiler_version }}  # [(cuda_compiler_version or "None") != "None"]

Presumably some people only want the python and don't need the executables and vice versa. I don't know how to do such a thing, but https://github.com/conda-forge/root-feedstock/blob/main/recipe/meta.yaml might give some inspiration.

Comment:

@hmaarrfk we've release a new version https://github.com/UCL/STIR/releases/tag/rel_5.1.0. I think you hoped that a bot would pick this up and create the sha256 for us, but nothing's happening for a week now. Do it manually or is there a trick?

We have run-time errors with libitk 5.2, so it's currently disabled. See #35 for more information.

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

First needed to install libitk-devel with conda, should have been done by STIR. Then I got this error.

$ ninja
ninja: error: '/home/conda/feedstock_root/build_artifacts/stir_1698674427419/_build_env/x86_64-conda-linux-gnu/sysroot/usr/lib/libpthread.so', needed by 'my_prog', missing and no known rule to make it

Installed packages

name: prd
channels:
  - conda-forge
  - defaults
dependencies:
  - bash-completion>=2.11
  - cmake>=3.21.3
  - fmt>=8.1.1
  - compilers
  - h5py>=3.7.0
  - hdf5>=1.12.1
  - howardhinnant_date>=3.0.1
  - ipykernel>=6.19.2
  - ninja>=1.11.0
  - nlohmann_json>=3.11.2
  - numpy>=1.24.3
  - python>=3.11.3
  - shellcheck>=0.8.0
  - xtensor-fftw>=0.2.5
  - xtensor>=0.24.2
  - libitk-devel>=5.2.0
  - stir

Environment info

$ conda info

     active environment : prd
    active env location : /opt/conda/envs/prd
            shell level : 1
       user config file : /home/vscode/.condarc
 populated config files : /opt/conda/.condarc
          conda version : 22.9.0
    conda-build version : not installed
         python version : 3.10.6.final.0
       virtual packages : __linux=6.2.0=0
                          __glibc=2.35=0
                          __unix=0=0
                          __archspec=1=x86_64
       base environment : /opt/conda  (writable)
      conda av data dir : /opt/conda/etc/conda
  conda av metadata url : None
           channel URLs : https://conda.anaconda.org/conda-forge/linux-64
                          https://conda.anaconda.org/conda-forge/noarch
          package cache : /opt/conda/pkgs
                          /home/vscode/.conda/pkgs
       envs directories : /opt/conda/envs
                          /home/vscode/.conda/envs
               platform : linux-64
             user-agent : conda/22.9.0 requests/2.28.1 CPython/3.10.6 Linux/6.2.0-1015-azure ubuntu/22.04.2 glibc/2.35
                UID:GID : 1000:1000
             netrc file : None
           offline mode : False

#18 had to disable to KOSMAPOSL test to pass the Linux azure tests. See 78a6630.

I have not been able to reproduce the failure elsewhere.
See also UCL/STIR#512

Comment:

#94 fixes #73, but it has to set STIR_DOC_DIR to ...share/doc/stir-5.1, which is version dependent. Ideally we get this version from somewhere else (possibly by running stir_config first), or by forcing the installation to ...share/doc/stir, which might be ok in conda (not sure). @casperdcl do you know how to do that?

Also, ideally we would test if STIR_DOC_DIR is set to the correct location, and if stir_config picks it up (i.e. by running stir_config --doc-dir and stir_config --examples-dir).

On Windows, the JSON files are in
%CONDA_PREFIX%\Library\share\stir\config. Not sure yet where they are on Linux/OSX. If the same, the activate scripts will need changing. Of course, then it's a mystery why the tests work with the current scripts on Linux/OSX (but would explain why they don't work for Windows...).

I installed STIR with Miniconda on Windows 10 but could not use any of the utilities nor python, with problems on DLLs.

Checking with dumpbin (or https://github.com/lucasg/Dependencies ), I find that the DLL _stir.pyd needs ITK 5.1 libraries, while the environment installed ITK 5.2 libraries.

I had to do the following to fix this (using Powershell for the 3rd line)

conda create -n stir-python3.8 python=3.8  stir  matplotlib libitk=5.1
conda activate stir-python3.8

where I got the directory name from "conda env list" and I had to fix Python to 3.8 as libitk isn't distributed for 3.9

Is there a mistake in our conda recipe? Should it specify versions of dependencies? That'd be dreadful.

will need itk dependency

without it, it is using the build location
https://github.com/UCL/STIR/blob/35acc8613c67c5aaf781cfa6cb9683f538ace6aa/src/buildblock/find_STIR_config.cxx#L53

Currently, STIR still doesn't default to using OPENMP. We could simply switch STIR_OPENMP=ON. Does this need anything special? e.g. dependency on https://anaconda.org/conda-forge/openmp? (which confusingly seems to be for llvm compilers only)

This package does not depend on ITK, limiting our IO options. However, we depend on
conda-forge/libitk-feedstock#42 being resolved first.

Comment:

#50 added ROOT. However, installing stir fresh on Linux gave me

ImportError: libTree.so.6.22: cannot open shared object file: No such file or directory

Checking contents of my environment, I see

/home/sirfuser/mambaforge/envs/stir_env/lib/libTree.so.6.26

So this is a version mismatch.

Comment:

after installing a fresh environment as in

mamba create -n stirdev  -c conda-forge/label/stir_dev stir
mamba activate stirdev

I get

$ OSMAPOSL
OSMAPOSL: error while loading shared libraries: libparallelproj_c.so.1.7.1: cannot open shared object file: No such file or directory

checking the content of the environment I see

$ ls -l /home/sirfuser/mambaforge/envs/stirdev/lib/libparallelproj_c.so*
lrwxrwxrwx 1 sirfuser sirfuser    26 Jan 30 14:53 /home/sirfuser/mambaforge/envs/stirdev/lib/libparallelproj_c.so -> libparallelproj_c.so.1.7.3
-rwxrwxr-x 3 sirfuser sirfuser 69848 Jan 26 14:21 /home/sirfuser/mambaforge/envs/stirdev/lib/libparallelproj_c.so.1.7.3

Note the version mismatch.

@gschramm does this mean we need to pin the run-time version to the build-version somehow?

#39 disabled windows tests due to failures, probably related to STIR_CONFIG_DIR. It is likely that the activate scripts don't work. Testing currently has to be done manually therefore.

The arm64 builds gives loads of these

ld: warning: direct access in function 'stir::ProjMatrixByBinUsingInterpolation::set_up(std::__1::shared_ptr<stir::ProjDataInfo const> const&, std::__1::shared_ptr<stir::DiscretisedDensity<3, float> const> const&)' from file 'src/recon_buildblock/librecon_buildblock.a(ProjMatrixByBinUsingInterpolation.cxx.o)' to global weak symbol 'typeinfo for stir::VoxelsOnCartesianGrid<float>' from file 'src/buildblock/libbuildblock.a(VoxelsOnCartesianGrid.cxx.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.

The "normal" OSX ones don't.

This warning is related to "visibility". An example PR that claims it resolves it is protocolbuffers/protobuf#9768, but I have no idea if this is relevant here or not. I also don't know if this is a conda specific warning, or actually a STIR problem that we haven't seen as STIR has no CI for arm64.

#50 attempted to add ROOT for OSX as well, but it didn't work.. See conda-forge/root-feedstock#191

Comment:

the bot-generated #51 to use PyPy still fails https://dev.azure.com/conda-forge/feedstock-builds/_build/results?buildId=599277&view=logs&j=d0d954b5-f111-5dc4-4d76-03b6c9d0cf7e&t=841356e0-85bb-57d8-dbbc-852e683d1642&l=2376

$SRC_DIR/build/src/swig/CMakeFiles/_stir.dir/stirPYTHON_wrap.cxx:159660:1: error: too many initializers for 'PyHeapTypeObject' {aka '_heaptypeobject'}

despite it using SWIG 4.1.0 which should contain swig/swig#2264

see #17

See discussion in conda-forge/parallelproj-feedstock#11

@gschramm, feel like creating a PR?

currently only building linux

still struggling with HDF5, so I've explicitly disabled it in #39. See some other comments for problems in #33