Repository: spack/spack

Issue:
Installation issue: gdal+lerc
### Steps to reproduce the issue

```console
spack install -j 16 --verbose --reuse gdal@3.5.1%gcc@11.3.0+python+png+curl+sqlite3 ^python@3.9.13+ssl ^cmake@3.23.2%gcc@11.3.0
```


### Error message

<details><summary>Error message</summary><pre>
==> Error: NoLibrariesError: Unable to recursively locate lerc libraries in /sw/spack/hydrogpu-2022-06/apps/lerc/3.0-gcc-11.3.0-6qfhczi

/mnt/a/sw/spack/spackgpu/develop-20220714/var/spack/repos/builtin/packages/gdal/package.py:398, in setup_run_environment:
        395        libs = []
        396        for dep in self.spec.dependencies(deptype='link'):
        397            query = self.spec[dep.name]
  >>    398            libs.extend(filter_system_paths(query.libs.directories))
        399        if sys.platform == 'darwin':
        400            env.prepend_path('DYLD_FALLBACK_LIBRARY_PATH', ':'.join(libs))
        401        else:

See build log for details:
  /tmp/svcbwswmanage/spack-stage/spack-stage-gdal-3.5.1-s5t4d4w5dzr4y74cohvfpkqg54ohumqf/spack-build-out.txt
</pre></details>


### Information on your system

$ spack debug report
* **Spack:** 0.19.0.dev0 (875b032151b550001a52a17fe7044116eea20ad7)
* **Python:** 3.6.8
* **Platform:** linux-rhel8-sandybridge
* **Concretizer:** clingo

### Additional information

This seems similar to several other issues related to build problems where a dependency does not have a +shared variant. In this case, gdal depends on the lerc package, which produces apps/lerc/3.0-gcc-11.3.0-6qfhczi/lib64/liblerc.so. My workaround is to build gdal with ~lerc. Another solution is to add a libs() property to the lerc package.py. However, I think the logic in lib/spack/spack/spec.py for ` _libs_default_handler(descriptor, spec, cls)`might be wrong. It seems like it should find liblerc.so for a package named "lerc" without requiring specific code, and I think the case where there is no +shared property is falling through the loop and throwing the NoLibrariesError when it should have found the library.

As I mentioned, this is fixable by changing lerc/package.py, but appears to apply to other packages as well.

[spack-build-out.txt](https://github.com/spack/spack/files/9161287/spack-build-out.txt)
[spack-build-env.txt](https://github.com/spack/spack/files/9161288/spack-build-env.txt)

Tagging @adamjstewart who maintains gdal, but this probably is not really a gdal issue. There is no maintainer for lerc listed by `spack maintainers lerc`

### General information

- [X] I have run `spack debug report` and reported the version of Spack/Python/Platform
- [X] I have run `spack maintainers <name-of-the-package>` and **@mentioned** any maintainers
- [X] I have uploaded the build log and environment files
- [X] I have searched the issues of this repo and believe this is not a duplicate
GDAL: external LERC only available in 3.3+
User reported a build issue when linking to external LERC for older GDAL. According to https://gdal.org/drivers/raster/gtiff.html:

> `LERC` and `LERC_DEFLATE` are available only when using internal libtiff for GDAL < 3.3.0. Since GDAL 3.3.0, LERC compression is also available when building GDAL against external libtiff >= 4.3.0, built itself against https://github.com/esri/lerc

Actually, now that I look at this, I'm not sure if it even makes sense to have a `+lerc` variant/dependency. @rouault is LERC actually used in GDAL or is it only used when building the internal copy of libtiff? Since we don't use internal copies of any dependencies, we may be able to remove the `+lerc` variant. Are there any other dependencies listed at https://gdal.org/build_hints.html that are secretly dependencies of dependencies?


Discussion:
My colleague with sharper eyes than mine notes that the library is named "libLerc.so", rather than "liblerc.so", so the spec.py code is probably okay, but lerc/package.py needs a proper libs() property defined.
Good catch! I was wondering why I didn't encounter this issue and then remembered that all the testing on the last big GDAL PR was done on macOS where the filesystem is case-insensitive. PR incoming.
> @rouault is LERC actually used in GDAL or is it only used when building the internal copy of libtiff?

the story depends on versions. LERC can be used by the MRF driver too. I'm not sure if it is from 3.5.0 or master, but previously only the internal copy of libLERC could be used by the MRF driver. Now it can be the external copy too.

Looks like that may also be the case with zstd: https://github.com/spack/spack/pull/26809#issuecomment-946486379

I would love to know which dependencies are actually used in GDAL and from which versions those deps are supported externally.

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/lerc/package.py b/var/spack/repos/builtin/packages/lerc/package.py
--- a/var/spack/repos/builtin/packages/lerc/package.py
+++ b/var/spack/repos/builtin/packages/lerc/package.py
@@ -20,3 +20,7 @@ class Lerc(CMakePackage):
     version("3.0", sha256="8c0148f5c22d823eff7b2c999b0781f8095e49a7d3195f13c68c5541dd5740a1")
 
     depends_on("cmake@3.11:", type="build")
+
+    @property
+    def libs(self):
+        return find_libraries(["libLerc"], root=self.prefix, recursive=True)


Test patch: