Build bump to pick up htslib 1.20

[ihnorton]

Build bump to pick up htslib 1.20 [sc-50311].

[dudoslav]

CICD Build log:

htslib: 1.20-hc7ee5c1_2 tiledb

So LGTM

[dudoslav]

CICD Build log:

htslib: 1.20-hc7ee5c1_2 tiledb

So LGTM

[ihnorton]

macOS osx_64 build hit:

2024-07-12T21:51:57.5050830Z + bash test-cli.sh
2024-07-12T21:52:05.8319530Z test-cli.sh: line 11: 17464 Illegal instruction: 4  tiledbvcf export --uri s3://tiledb-inc-demo-data/tiledbvcf-arrays/v4/vcf-samples-20 --regions chr1:1-100000 --sample-names v2-usVwJUmo,v2-WpXCYApL --output-format z --output-dir "$OUTDIR"

rerun

[jdblischak]

macOS osx_64 build hit:

I am confused why we are getting this Illegal instruction error now. We successfully built this feedstock only last week (535c089), and the osx-64 build passed. Given that this PR hasn't changed the TileDB-VCF source code, I don't see why we would need to suddenly change the OSX_DEPLOYMENT_TARGET.

[dudoslav]

@jdblischak We bumped up (released) htslib version to 1.20, and since the pin here is >1.15 it got picked up and used here. So perhaps the illegal instruction comes from htslib

[jdblischak]

I ran the builds on my fork using the latest commit (which used htslib 1.20), and I also tried pinning htslib to 1.19. Both failed with the Illegal instruction error.

This means that something has changed (either a conda dependency or something in the Azure image) since last Tuesday (July 9th) that is causing the error, and it isn't the update of htslib from 1.19 to 1.20.

[jdblischak]

We bumped up (released) htslib version to 1.20, and since the pin here is >1.15 it got picked up and used here. So perhaps the illegal instruction comes from htslib

@dudoslav I had finished typing my response above when you commented. I had the same thought, but I believe my experiment has ruled out htslib as the culprit

[dudoslav]

I am not sure if this is correct but on azure pipelines I can see that the newest jobs run under MacOS 12.7.5 but the last pipeline that passed is also 12.7.5:

https://dev.azure.com/TileDB-Inc/CI/_build/results?buildId=40261&view=logs&j=58ac6aab-c4bc-5de2-2894-98e408cc8ec9&t=3001bc22-659c-4b49-91e9-8cb6ed43d4eb

[jdblischak]

the newest jobs run under MacOS 12.7.5 but the last pipeline that passed is also 12.7.5

Agreed. The versions are the same, but the image has changed:

• last passing: Current image version: '20240630.1'
• currently failing: Current image version: '20240707.1'

[ihnorton]

Agreed. The versions are the same, but the image has changed:

This is a good clue. But toolchain versions seem the same, at least:

2024-07-09T13:21:12.4685960Z INFO: activate_clang_osx-64.sh made the following environmental changes:
2024-07-09T13:21:12.5271560Z +AR=x86_64-apple-darwin13.4.0-ar
2024-07-09T13:21:12.5331170Z +AS=x86_64-apple-darwin13.4.0-as
2024-07-09T13:21:12.5379450Z +CC=x86_64-apple-darwin13.4.0-clang

2024-07-13T07:40:56.3260770Z INFO: activate_clang_osx-64.sh made the following environmental changes:
2024-07-13T07:40:56.3790890Z +AR=x86_64-apple-darwin13.4.0-ar
2024-07-13T07:40:56.3791620Z +AS=x86_64-apple-darwin13.4.0-as
2024-07-13T07:40:56.3791960Z +CC=x86_64-apple-darwin13.4.0-clang
2024-07-13T07:40:56.3792440Z +CC_FOR_BUILD=/Users/runner/miniforge3/conda-bld/tiledb-vcf_1720856107208/_build_env/bin/x86_64-apple-darwin13.4.0-clang

last passing: Current image version: '20240630.1'

This one picked up htslib 1.20, so we know definitively that it was fine before even on 1.20.

[dudoslav]

VCF versions are the same between those two runs and also feedstocks diff is just build number.

[jdblischak]

The osx-64 build runs on "macOS-12"

tiledb-vcf-feedstock/.azure-pipelines/azure-pipelines-osx.yml

Line 8 in 535c089

vmImage: macOS-12

Thus here is the PR that updated the image to version 20240707.1: actions/runner-images#10196

Very few updates were made. Trying to think of potential problems for this error:

• CMake and vcpkg were updated
• AWS CLI and AWS Session Manager CLI were updated. I only mention these because the line that fails is accessing an array from S3

[jdblischak]

Very few updates were made. Trying to think of potential problems for this error:

Ack. Reminding myself that this is a feedstock build. None of these updates should matter. All of the dependencies should be provided by conda.

[jdblischak]

I compared the conda packages installed in the test environment between the last passing build and a currently failing build.

The conda packages that actually changed versions (as opposed to simply a new build) are: libcxx, c-ares, aws-crt-cpp, aws-c-io

Given that this appears to be a problem with the compilation, I investigated libcxx first. Turns out there was already an Issue open about this Illegal instruction error on osx-64 caused by libcxx 18 conda-forge/libcxx-feedstock#162

Also potentially of interest is this PR that recently updated MACOSX_DEPLOYMENT_TARGET for libcxx conda-forge/libcxx-feedstock#159

Full diff below:

$ grep htslib vcf-*
vcf-failing.txt:htslib:                   1.20-hcfc518d_2             tiledb
vcf-passing.txt:htslib:                   1.20-hcfc518d_2             tiledb

$ diff vcf-passing.txt vcf-failing.txt
1c1
< aws-c-auth:               0.7.22-he52cbe7_7           conda-forge
---
> aws-c-auth:               0.7.22-hdb02296_8           conda-forge
5,9c5,9
< aws-c-event-stream:       0.4.2-ha5205da_14           conda-forge
< aws-c-http:               0.8.2-hf609411_4            conda-forge
< aws-c-io:                 0.14.9-h9f49e27_5           conda-forge
< aws-c-mqtt:               0.10.4-hcc4e2a5_7           conda-forge
< aws-c-s3:                 0.6.0-h8fdb93b_0            conda-forge
---
> aws-c-event-stream:       0.4.2-h2713d70_15           conda-forge
> aws-c-http:               0.8.2-ha849b92_5            conda-forge
> aws-c-io:                 0.14.10-h9f49e27_0          conda-forge
> aws-c-mqtt:               0.10.4-hf6997d9_8           conda-forge
> aws-c-s3:                 0.6.0-hfc8374f_1            conda-forge
12,13c12,13
< aws-crt-cpp:              0.27.2-h7746516_0           conda-forge
< aws-sdk-cpp:              1.11.329-hce9e41e_8         conda-forge
---
> aws-crt-cpp:              0.27.3-hed18db7_1           conda-forge
> aws-sdk-cpp:              1.11.329-h554caeb_9         conda-forge
19c19
< c-ares:                   1.28.1-h10d778d_0           conda-forge
---
> c-ares:                   1.32.1-h51dda26_0           conda-forge
28c28
< libcxx:                   17.0.6-heb59cac_3           conda-forge
---
> libcxx:                   18.1.8-hef8daea_0           conda-forge
40c40
< libtiledbvcf:             0.33.2-hfffce77_0           local
---
> libtiledbvcf:             0.33.2-h4f7dbc7_1           local
42c42
< libxml2:                  2.12.7-h3e169fe_1           conda-forge
---
> libxml2:                  2.12.7-hc603aa4_3           conda-forge
49c49
< tiledb:                   2.24.2-h493d6f2_1           conda-forge
---
> tiledb:                   2.24.2-h86b3714_2           conda-forge

[dudoslav]

It seems that we only need to pin libcxx<18: #128

So I will add one last commit removing all other aws and similar pins