Add recipe output for r-tiledbsoma

jdblischak commented 1 year ago

This PR adds an output section to build the conda package r-tiledbsoma

Good news: I was able to build the recipe locally on Ubuntu for R 4.1 and 4.2. I've copied some relevant output from the successful build below
Bad news: The Azure builds fail. For some strange reason, the conda solver tries to install R 3.5. Still have to investigate
Temporary changes: note that I made a few temporary changes to facilitate testing. First I removed all but one of the Python variants to reduce the build time. Second I switched to use the Git repo as the source since enabling the conda builds is an ongoing process
Immediate question: The Python client version exactly matches the libtiledbsoma version. Is the plan to keep a separate version string for the R client?

cc: @eddelbuettel, @nguyenv, @aaronwolen, @ihnorton xref: https://github.com/single-cell-data/TileDB-SOMA/issues/1277#issuecomment-1520930305, https://github.com/single-cell-data/TileDB-SOMA/pull/1302

Excerpts from my successful local build:

> tiledbsoma::show_package_versions()
tiledbsoma:    0.0.0.9022
tiledb-r:      0.19.1
tiledb core:   2.15.2
libtiledbsoma: libtiledb=2.15.2
R:             R version 4.1.3 (2022-03-10)
OS:            Ubuntu 22.04.2 LTS

> tiledbsoma::show_package_versions()
tiledbsoma:    0.0.0.9022
tiledb-r:      0.19.1
tiledb core:   2.15.2
libtiledbsoma: libtiledb=2.15.2
R:             R version 4.2.3 (2023-03-15)
OS:            Ubuntu 22.04.2 LTS

{
  "libtiledbsoma-1.2.2-h238ffd6_0": {
    "recipe": {
      "c_compiler": "gcc",
      "c_compiler_version": "12",
      "channel_targets": "conda-forge main",
      "cxx_compiler": "gxx",
      "cxx_compiler_version": "12",
      "fmt": "9",
      "spdlog": "1.11",
      "target_platform": "linux-64"
    }
  },
  "r-tiledbsoma-0.0.0.9022-r41h00ab1b0_0": {
    "recipe": {
      "channel_targets": "conda-forge main",
      "cxx_compiler": "gxx",
      "cxx_compiler_version": "12",
      "target_platform": "linux-64"
    }
  },
  "r-tiledbsoma-0.0.0.9022-r42h00ab1b0_0": {
    "recipe": {
      "channel_targets": "conda-forge main",
      "cxx_compiler": "gxx",
      "cxx_compiler_version": "12",
      "target_platform": "linux-64"
    }
  },
  "tiledbsoma-py-1.2.2-py310hfb6f7a9_0": {
    "recipe": {
      "channel_targets": "conda-forge main",
      "cxx_compiler": "gxx",
      "cxx_compiler_version": "12",
      "numpy": "1.21",
      "python": "3.10.* *_cpython",
      "target_platform": "linux-64"
    }
  }
}

jdblischak commented 1 year ago

Duh, I forgot to rerender. Thus it didn't use the conda-forge-pinning of r-base 4.1 and 4.2. Locally I was manually pointing to a copy of conda-forge-pinning, so that's why it had worked for me

jdblischak commented 1 year ago

Current status:

linux-64 build passed

osx-64 build failed during compilation

In file included from ../inst/tiledb/include/tiledb/attribute.h:42:
../inst/tiledb/include/tiledb/object.h:131:30: error: 'value' is unavailable: introduced in macOS 10.13 - see https://conda-forge.org/docs/maintainer/knowledge_base.html#newer-c-features-with-old-sdk
  ret += " - \"" + name_.value() + "\">";

osx-arm64 build failed during byte-compliation

** byte-compile and prepare package for lazy loading
Error in dyn.load(file, DLLpath = DLLpath, ...) : 
unable to load shared object '/Users/runner/miniforge3/conda-bld/tiledbsoma_1683311692471/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehol/lib/R/library/lattice/libs/lattice.dylib':
dlopen(/Users/runner/miniforge3/conda-bld/tiledbsoma_1683311692471/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehol/lib/R/library/lattice/libs/lattice.dylib, 6): no suitable image found.  Did find:
/Users/runner/miniforge3/conda-bld/tiledbsoma_1683311692471/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehol/lib/R/library/lattice/libs/lattice.dylib: mach-o, but wron
Calls: <Anonymous> ... asNamespace -> loadNamespace -> library.dynam -> dyn.load
Execution halted
ERROR: lazy loading failed for package ‘tiledbsoma’

johnkerl commented 1 year ago

@jdblischak the unable to load shared object might be addressed by https://github.com/single-cell-data/TileDB-SOMA/pull/1343 which is a WIP

Shelnutt2 commented 1 year ago

@jdblischak the unable to load shared object might be addressed by single-cell-data/TileDB-SOMA#1343 which is a WIP

I don't think that PR will help, the error is not for libtiledbsoma but for lattice.dylib. Also conda doesn't use /usr/local as a path, libraries are in the conda prefix location, which pkg-config should have set from the c++ library.

@jdblischak nice work, thanks for putting this up! I'm wondering if the r-lattice is broken upstream?

For the amd64 issue I think we'll need to wrap the compiler commands like we did in r-tiledb: https://github.com/conda-forge/r-tiledb-feedstock/blob/658080fdbc2ed3c3a0a5039ca4e30460f005c26b/recipe/build.sh#L4

eddelbuettel commented 1 year ago

I'm wondering if the r-lattice is broken upstream?

Unlikely, it is a 'recommended' package that 'effectively' comes with R itself (though it is technically a CRAN package like 19.5k others). But maybe the Conda package needs a rebuild around the R 4.2.3 to R 4.3.0 transition?

jdblischak commented 1 year ago

Thanks all for the feedback. The osx-64 build is passing now!

I'm wondering if the r-lattice is broken upstream?

@Shelnutt2 This was a promising lead. There were previous osx-arm64 conda binaries that were actually osx-64 (https://github.com/conda-forge/r-lattice-feedstock/issues/14). However, these have been marked as broken (https://github.com/conda-forge/admin-requests/pull/218), and the recipe subsequently fixed (https://github.com/conda-forge/r-lattice-feedstock/pull/15). I installed the same osx-arm64 r-lattice versions from the Azure build on a local macOS M1 machine, and I was able to run example lattice code without issue

jdblischak commented 1 year ago

Latest update. I've made progress on the osx-arm64 build. By including all the R package dependencies that require compilation in the cross-compilation build requirements, I was able to remove the loading errors from unrelated packages (eg lattice.dylib).

However, now it is failing to load tiledbsoma.dylib itself, which was surprising given that it should have just been built.

** byte-compile and prepare package for lazy loading
** help
Error :  unable to load shared object '/Users/runner/miniforge3/conda-bld/tiledbsoma_1683650279834/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehol/lib/R/library/00LOCK-r/00new/tiledbsoma/libs/tiledbsoma.dylib':
  dlopen(/Users/runner/miniforge3/conda-bld/tiledbsoma_1683650279834/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehol/lib/R/library/00LOCK-r/00new/tiledbsoma/libs/tiledbsoma.dylib, 6): no suitable image found.  Did find:
    /Users/runner/miniforge3/conda-bld/tiledbsoma_1683650279834/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehol/lib/R/library/00LOCK-r/0
ERROR: installing Rd objects failed for package ‘tiledbsoma’
* removing ‘/Users/runner/miniforge3/conda-bld/tiledbsoma_1683650279834/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehol/lib/R/library/tiledbsoma’

Looking at the recipes for r-tiledb and tiledbsoma-py, I don't see anything overly obvious that I am doing wrong. Any suggestions?

eddelbuettel commented 1 year ago

The only difference I know of between macOS arm64 and macOS x86_64 is the imposition of the minimum-compilation standard for x86_64 only to permit use on previous releases.

Could that matter here, i.e. could we accidentally have -mmacosx-version-min=10.14 on for arm64 ? Otherwise I am more than stumped.

jdblischak commented 1 year ago

Could that matter here, i.e. could we accidentally have -mmacosx-version-min=10.14 on for arm64 ? Otherwise I am more than stumped.

Thanks Dirk. If I understand your suggestion correctly, I think the answer is no. The supplemental scripts that set -mmacosx-version-min=10.14 are only applied when the conda-build env var target_platform is equal to "osx-64". In the arm64 build it is set to "osx-arm64", and thus that code is skipped.

Checking the build log to confirm:

+ cd apis/r
+ export DISABLE_AUTOBREW=1
+ DISABLE_AUTOBREW=1
+ [[ osx-arm64 == osx-64 ]]
+ export 'CXX17FLAGS=-Wno-deprecated-declarations -Wno-deprecated'
+ CXX17FLAGS='-Wno-deprecated-declarations -Wno-deprecated'
+ /Users/runner/miniforge3/conda-bld/tiledbsoma_1683650279834/_build_env/bin/R CMD INSTALL --build . --library=/Users/runner/miniforge3/conda-bld/tiledbsoma_1683650279834/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehol/lib/R/library --no-test-load
* installing *source* package ‘tiledbsoma’ ...
** using staged installation

jdblischak commented 1 year ago

Since there have been multiple updates to the R client since last week, I restarted the previously failed osx-arm64 build. This new build used the TileDB-SOMA source repo from commit 18f0394

The error this time is similar, though it includes the name of the help file that was being processed when the error was triggered, EphemeralCollection.Rd. Assuming that the help files are processed alphabetically, this means that ConfigList.Rd was able to be processed without error

** byte-compile and prepare package for lazy loading
** help
Error : EphemeralCollection.Rd:7: unable to load shared object '/Users/runner/miniforge3/conda-bld/tiledbsoma_1684257316766/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehol/lib/R/library/00LOCK-r/00new/tiledbsoma/libs/tiledbsoma.dylib':
  dlopen(/Users/runner/miniforge3/conda-bld/tiledbsoma_1684257316766/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehol/lib/R/library/00LOCK-r/00new/tiledbsoma/libs/tiledbsoma.dylib, 6): no suitable image found.  Did find:
    /Users/runner/miniforge3/conda-bld/tiledbsoma_1684257316766/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehol/lib/R/library/00LOCK-r/0
ERROR: installing Rd objects failed for package ‘tiledbsoma’
* removing ‘/Users/runner/miniforge3/conda-bld/tiledbsoma_1684257316766/_h_env_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehold_placehol/lib/R/library/tiledbsoma’

jdblischak commented 1 year ago

My troubleshooting progress was slow today. My ideas related to editing configure and Makevars.in for the conda build were a dead end, and seemed to hurt more than help anything.

One useful thing I did was decrease the installation prefix length so that we can see the full error messages from the macOS builds (see the conda build docs on making packages relocatable for the justification for using the long installation prefix).

For the osx-64 build (macOS amd64), the build works with R 4.2. The failure comes when trying to build with R 4.1. For some reason, tiledbsoma.dylib appears to require R 4.2+

installing to /Users/runner/miniforge3/conda-bld/tiledbsoma_1684350979543/_h_env_placehold_placehold_placehold_placehold_placehold_pla/lib/R/library/00LOCK-r/00new/tiledbsoma/libs
** R
** inst
** byte-compile and prepare package for lazy loading
** help
Error :  unable to load shared object '/Users/runner/miniforge3/conda-bld/tiledbsoma_1684350979543/_h_env_placehold_placehold_placehold_placehold_placehold_pla/lib/R/library/00LOCK-r/00new/tiledbsoma/libs/tiledbsoma.dylib':
  dlopen(/Users/runner/miniforge3/conda-bld/tiledbsoma_1684350979543/_h_env_placehold_placehold_placehold_placehold_placehold_pla/lib/R/library/00LOCK-r/00new/tiledbsoma/libs/tiledbsoma.dylib, 6): Library not loaded: @rpath/R/lib/libR.dylib
  Referenced from: /Users/runner/miniforge3/conda-bld/tiledbsoma_1684350979543/_h_env_placehold_placehold_placehold_placehold_placehold_pla/lib/R/library/00LOCK-r/00new/tiledbsoma/libs/tiledbsoma.dylib
  Reason: Incompatible library version: tiledbsoma.dylib requires version 4.2.0 or later, but libR.dylib provides version 4.1.0
ERROR: installing Rd objects failed for package ‘tiledbsoma’
* removing ‘/Users/runner/miniforge3/conda-bld/tiledbsoma_1684350979543/_h_env_placehold_placehold_placehold_placehold_placehold_pla/lib/R/library/tiledbsoma’

The key error message is:

Reason: Incompatible library version: tiledbsoma.dylib requires version 4.2.0 or later, but libR.dylib provides version 4.1.0

I couldn't figure out where this requirement comes from. The DESCRIPTION file states R (>= 4.0.0). Any insights?

For the osx-arm64 build, it is able to find libs/tiledbsoma.dylib, but complains that it is the wrong architecture (mach-o, but wrong architecture). To me this strongly implies there is something wrong with the cross-compilation.

installing to /Users/runner/miniforge3/conda-bld/tiledbsoma_1684350977931/_h_env_placehold_placehold_placehold_placehold_placehold_pla/lib/R/library/00LOCK-r/00new/tiledbsoma/libs
** R
** inst
** byte-compile and prepare package for lazy loading
** help
Error :  unable to load shared object '/Users/runner/miniforge3/conda-bld/tiledbsoma_1684350977931/_h_env_placehold_placehold_placehold_placehold_placehold_pla/lib/R/library/00LOCK-r/00new/tiledbsoma/libs/tiledbsoma.dylib':
  dlopen(/Users/runner/miniforge3/conda-bld/tiledbsoma_1684350977931/_h_env_placehold_placehold_placehold_placehold_placehold_pla/lib/R/library/00LOCK-r/00new/tiledbsoma/libs/tiledbsoma.dylib, 6): no suitable image found.  Did find:
    /Users/runner/miniforge3/conda-bld/tiledbsoma_1684350977931/_h_env_placehold_placehold_placehold_placehold_placehold_pla/lib/R/library/00LOCK-r/00new/tiledbsoma/libs/tiledbsoma.dylib: mach-o, but wrong architecture
    /Users/runner/miniforge3/conda-bld/tiledbsoma_1684350977931/_h_env_placehold_placehold_placehold_placehold_placehold_pla/lib/R/library/00LOCK-r/00new/tiledbsoma/libs/tiledbsoma.dylib: mach-o, but wrong architecture
ERROR: installing Rd objects failed for package ‘tiledbsoma’
* removing ‘/Users/runner/miniforge3/conda-bld/tiledbsoma_1684350977931/_h_env_placehold_placehold_placehold_placehold_placehold_pla/lib/R/library/tiledbsoma’

In summary, I don't think this is an issue with rpath or in general finding the libraries. The problem is that the tiledbsoma.dylib that is created and found is incompatible for some reason.

jdblischak commented 1 year ago

This osx-64 (macOS x86) build error is so frustrating. Once again the error has disappeared despite the fact that I didn't change anything relevant. Now it builds just fine with R 4.1.3, but next time is anyone's guess

INFO (r-tiledbsoma,lib/R/library/tiledbsoma/libs/tiledbsoma.dylib): Needed DSO lib/R/lib/libR.dylib found in conda-forge::r-base-4.1.3-h7a6543b_8

Actually, I have a hunch. I think the build order (R 4.1 vs 4.2) is playing a role. The order is randomly decided for each job. This most recent one passed when the R 4.1 build preceded the R 4.2 build:

BUILD START: ['libtiledbsoma-1.2.2-h2650b1e_0.conda', 'r-tiledbsoma-0.0.0.9024-r41hfb802ea_0.conda', 'r-tiledbsoma-0.0.0.9024-r42hfb802ea_0.conda', 'tiledbsoma-py-1.2.2-py39hc51d931_0.conda']

And yesterday's build failed when the R 4.2 build was first:

BUILD START: ['libtiledbsoma-1.2.2-h2650b1e_0.conda', 'r-tiledbsoma-0.0.0.9022-r42hfb802ea_0.conda', 'r-tiledbsoma-0.0.0.9022-r41hfb802ea_0.conda', 'tiledbsoma-py-1.2.2-py39hc51d931_0.conda']

This suggests that something from the 4.2 build is leaking outside of the conda env, and is then found again during the 4.1 build

jdblischak commented 1 year ago

Alright. I finally figured out the problem with the osx-64 build, that technically also applied to the linux-64 build even though it didn't cause an error. The compiled files are saved in the source directory, and they weren't being cleaned up between builds, and thus they weren't being recompiled with the next version of R. The fix was adding the flag --clean

jdblischak commented 1 year ago

Just as the osx-64 build was fixed with the deceptively simple --clean, the osx-arm64 build was fixed with --no-help. I had already observed this above, but I didn't understand why it worked. Now I understand why. The help pages in TileDB-SOMA-R use the macro \Sexpr{} to dynamically evaluate R code when rendering the help pages. I didn't have to use --no-help when cross-compiling TileDB-R because it doesn't use \Sexpr{} in its help pages.

eddelbuettel commented 1 year ago

Yay:

jdblischak commented 1 year ago

After the next TileDB-SOMA release, I'll rebase, cleanup, and remove the draft status

johnkerl commented 1 year ago

Thanks @jdblischak !!! :)

jdblischak commented 1 year ago

Superseded by #24. The R client output was included in the 1.2.4 release

TileDB-Inc / tiledbsoma-feedstock

Add recipe output for r-tiledbsoma #22