liblzma.lib renamed to lzma.lib in 5.6 seems to be causing issues

[minrk]

Solution to issue cannot be found in the documentation.

• I checked the documentation.

Issue

I'm not sure what exactly is going on, but dolfinx builds have started failing on Windows during cmake build with:

ninja: error: 'D:/bld/fenics-dolfinx-split_1736324192638/_h_env/Library/lib/liblzma.lib', needed by 'dolfinx/dolfinx.dll', missing and no known rule to make it

I don't entirely know where this is coming from, because dolfinx doesn't use liblzma. I think it's coming through scotch. The relevant bit of info I can find is that xz 5.2.6 has liblzma.lib, whereas liblzma-devel 5.6.3 has lzma.lib. I think that might mean that packages built against xz 5.2 are not actually compatible with 5.6, despite being allowed by run_exports. It's unclear to me if this is a general runtime problem (dlls have the same name change) or just a downstream build-time problem.

If it's a runtime problem, then I think the solution is a repodata patch to tighten the upper bound on packages depending onxz >=5.2.6,<6.0a0 to <5.6 instead. If it's build-only, then it's probably not a big deal and I can work around it. I think I may only be hitting this because dolfinx needs to pin back impi, which in turn means excluding the latest builds of scotch that use the latest liblzma-devel.

Installed packages

- fenics-ufcx 0.9.0 h1076a80_0
    - ca-certificates 2024.12.14 h56e8100_0
    - intel-openmp 2024.2.1 h57928b3_1083
    - libboost-headers 1.86.0 h57928b3_3
    - llvm-meta 5.0.0 0
    - mpi 1.0 impi
    - ucrt 10.0.22621.0 h57928b3_1
    - impi_rt 2021.12.0 h57928b3_537
    - vc14_runtime 14.42.34433 he29a5d6_23
    - impi-devel 2021.12.0 h57928b3_537
    - vc 14.3 ha32ba9b_23
    - bzip2 1.0.8 h2466b09_7
    - fmt 11.0.2 h7f575de_0
    - libaec 1.1.3 h63175ca_0
    - libiconv 1.17 hcfcfb64_2
    - liblzma 5.6.3 h2466b09_1
    - libzlib 1.3.1 h2466b09_2
    - openmp 5.0.0 vc14_1
    - openssl 3.4.0 ha4e3fda_1
    - pthreads-win32 2.9.1 h2466b09_4
    - pugixml 1.14 h63175ca_0
    - krb5 1.21.3 hdf4eb48_0
    - libflang 5.0.0 h6538335_20180525
    - liblzma-devel 5.6.3 h2466b09_1
    - libssh2 1.11.1 he619c9f_0
    - libxml2 2.13.5 he286e8c_1
    - spdlog 1.15.0 h81cc0e1_0
    - xz-tools 5.6.3 h2466b09_1
    - zlib 1.3.1 h2466b09_2
    - zstd 1.5.6 h0ea2cb4_0
    - libboost 1.86.0 hb0986bb_3
    - libcurl 8.11.1 h88aaa65_0
    - libhwloc 2.11.2 default_hc8275d1_1000
    - xz 5.6.3 h208afaa_1
    - hdf5 1.14.3 mpi_impi_h2ee790a_5
    - libboost-devel 1.86.0 h91493d7_3
    - libscotch 7.0.5 h15f9def_1
    - tbb 2021.13.0 h62715c5_1
    - libptscotch 7.0.5 h908f345_1
    - mkl 2024.2.2 h66d3029_15
    - libblas 3.9.0 26_win64_mkl
    - libcblas 3.9.0 26_win64_mkl
    - liblapack 3.9.0 26_win64_mkl
    - fenics-libbasix 0.9.0 h8983ae2_2

Environment info

active environment : base
    active env location : D:\Miniforge
            shell level : 1
       user config file : C:\Users\VssAdministrator\.condarc
 populated config files : D:\Miniforge\.condarc
                          C:\Users\VssAdministrator\.condarc
          conda version : 24.11.2
    conda-build version : 24.11.2
         python version : 3.12.8.final.0
                 solver : libmamba (default)
       virtual packages : __archspec=1=x86_64_v4
                          __conda=24.11.2=0
                          __win=0=0
       base environment : D:\Miniforge  (writable)
      conda av data dir : D:\Miniforge\etc\conda
  conda av metadata url : None
           channel URLs : https://conda.anaconda.org/conda-forge/win-64
                          https://conda.anaconda.org/conda-forge/noarch
          package cache : D:\Miniforge\pkgs
                          C:\Users\VssAdministrator\.conda\pkgs
                          C:\Users\VssAdministrator\AppData\Local\conda\conda\pkgs
       envs directories : D:\Miniforge\envs
                          C:\Users\VssAdministrator\.conda\envs
                          C:\Users\VssAdministrator\AppData\Local\conda\conda\envs
               platform : win-64
             user-agent : conda/24.11.2 requests/2.32.3 CPython/3.12.8 Windows/2022Server Windows/10.0.20348 solver/libmamba conda-libmamba-solver/24.11.1 libmambapy/2.0.5
          administrator : True
             netrc file : None
           offline mode : False

[minrk]

and it looks like liblzma 5.6 and xz 5.2 don't conflict, so you can instlal both in the same env. The liblzma splits might need a run_constrained on xz:

conda create -n test xz=5.2 liblzma=5.6

should probably fail with a conflict.

[minrk]

The quickest test I could find (https://github.com/minrk/junk/actions/runs/12671152678/job/35312289186) suggests that the dll name change doesn't break things at runtime. I don't really understand that, but linking on Windows is a mystery to me. So it's only the conflict that's really needed, and then I think I can deal with pinning down xz properly excluding newer liblzma.

[minrk]

conda-forge/conda-forge-repodata-patches-feedstock#936 adds the conflict