Steps to reproduce
I am updating our spack code from March this year to July, and I am having real problems with libiconv. Previously, it worked just fine using homebrew’s cmake, curl, wget etc. Now I am getting all these undefined symbols _iconv which have to do with inconsistencies how these symbols are called (see https://stackoverflow.com/questions/57734434/libiconv-or-iconv-undefined-symbol-on-mac-osx).
An easy solution seems to be to tell spack to just use homebrew’s libiconv so that they are all consistent, but: making libiconv available as external package, setting it to buildable: False, and even making it a conflict for Darwin is all ignored by spack.
- Update: even if I manually force spack to use the homebrew iconv, this has no effect whatsoever, still getting the same undefined symbols error.
- Update: I can force the concretizer by setting the external package as
buildable: False and using spack concretize --reuse.
--- a/var/spack/repos/builtin/packages/libiconv/package.py
+++ b/var/spack/repos/builtin/packages/libiconv/package.py
@@ -33,6 +33,27 @@ class Libiconv(AutotoolsPackage, GNUMirrorPackage):
conflicts("@1.14", when="%gcc@5:")
+ # Don't build on Darwin to avoid problems with _iconv vs _libiconv; use brew/macports - see
+ # https://stackoverflow.com/questions/57734434/libiconv-or-iconv-undefined-symbol-on-mac-osx
+ conflicts("platform=darwin")
+
+ # For spack external find
+ executables = ["^iconv$"]
+
+ @classmethod
+ def determine_version(cls, exe):
+ import re
+ # We only need to find libiconv on macOS to avoid problems with _iconv vs _libiconv - see
+ # https://stackoverflow.com/questions/57734434/libiconv-or-iconv-undefined-symbol-on-mac-osx
+ macos_pattern = re.compile("\(GNU libiconv (\w+\.\w+)\)")
+ version_string = Executable(exe)("--version", output=str, error=str)
+ match = macos_pattern.search(version_string)
+ version = None
+ if match:
+ version = match.group(1)
+ #raise InstallError(f"{version_string} --> {match} --> {match.group(1)}")
+ return version # Executable(exe)("--version", output=str, error=str)
In packages.yaml:
libiconv:
buildable: False
externals:
- spec: libiconv@1.17
prefix: /opt/homebrew/opt/libiconv
- spec: libiconv@1.11
prefix: /usr
Does anyone know why spack is ignoring the conflict statement and the external package / buildable: False flag?
Error message
Output of the concretizer:
> cat log.concretize.unified-en4.001 | grep iconv
[e] cpbzujy ^libiconv@1.17%apple-clang@13.1.6 build_system=autotools libs=shared,static arch=darwin-monterey-m1
- 3kqzjx5 ^libiconv@1.17%apple-clang@13.1.6 build_system=autotools libs=shared,static arch=darwin-monterey-m1
[e] cpbzujy ^libiconv@1.17%apple-clang@13.1.6 build_system=autotools libs=shared,static arch=darwin-monterey-m1
- 3kqzjx5 ^libiconv@1.17%apple-clang@13.1.6 build_system=autotools libs=shared,static arch=darwin-monterey-m1
- i3pq7bh ^gdal@3.7.0%apple-clang@13.1.6~armadillo~arrow~basisu~blosc~brunsli~cfitsio~crnlib~cryptopp~csharp+curl~deflate~ecw+expat~filegdb~freexl~fyba+geos~gif~gta~hdf4~hdf5~hdfs~heif~iconv~idb~ipo~java+jpeg~jxl~kdu~kea~lerc~libcsf~libkml~liblzma~libxml2~luratech~lz4~mongocxx~mrsid~mssql_ncli~mssql_odbc~mysql~netcdf~odbc~odbccpp~ogdi~opencad~opencl~openexr~openjpeg~openssl~oracle~parquet~pcidsk~pcre~pdfium~pic+png~podofo~poppler~postgresql+python~qb3~qhull~rasterlite2~rdb~sfcgal+shared~spatialite+sqlite3~teigha~tiledb~webp~xercesc~zstd build_system=cmake build_type=Release generator=ninja arch=darwin-monterey-m1
[e] cpbzujy ^libiconv@1.17%apple-clang@13.1.6 build_system=autotools libs=shared,static arch=darwin-monterey-m1
- 3kqzjx5 ^libiconv@1.17%apple-clang@13.1.6 build_system=autotools libs=shared,static arch=darwin-monterey-m1
[e] cpbzujy ^libiconv@1.17%apple-clang@13.1.6 build_system=autotools libs=shared,static arch=darwin-monterey-m1
- 3kqzjx5 ^libiconv@1.17%apple-clang@13.1.6 build_system=autotools libs=shared,static arch=darwin-monterey-m1
[e] cpbzujy ^libiconv@1.17%apple-clang@13.1.6 build_system=autotools libs=shared,static arch=darwin-monterey-m1
- 3kqzjx5 ^libiconv@1.17%apple-clang@13.1.6 build_system=autotools libs=shared,static arch=darwin-monterey-m1
[e] cpbzujy ^libiconv@1.17%apple-clang@13.1.6 build_system=autotools libs=shared,static arch=darwin-monterey-m1
- 3kqzjx5 ^libiconv@1.17%apple-clang@13.1.6 build_system=autotools libs=shared,static arch=darwin-monterey-m1
[e] cpbzujy ^libiconv@1.17%apple-clang@13.1.6 build_system=autotools libs=shared,static arch=darwin-monterey-m1
- 3kqzjx5 ^libiconv@1.17%apple-clang@13.1.6 build_system=autotools libs=shared,static arch=darwin-monterey-m1
[e] cpbzujy ^libiconv@1.17%apple-clang@13.1.6 build_system=autotools libs=shared,static arch=darwin-monterey-m1
- 3kqzjx5 ^libiconv@1.17%apple-clang@13.1.6 build_system=autotools libs=shared,static arch=darwin-monterey-m1
- 3kqzjx5 ^libiconv@1.17%apple-clang@13.1.6 build_system=autotools libs=shared,static arch=darwin-monterey-m1
[e] cpbzujy ^libiconv@1.17%apple-clang@13.1.6 build_system=autotools libs=shared,static arch=darwin-monterey-m1
[e] cpbzujy ^libiconv@1.17%apple-clang@13.1.6 build_system=autotools libs=shared,static arch=darwin-monterey-m1
[e] cpbzujy ^libiconv@1.17%apple-clang@13.1.6 build_system=autotools libs=shared,static arch=darwin-monterey-m1
Information on your system
* **Spack:** 0.21.0.dev0 (98957cf32aa809e831bee4af2bf642e2bd038c04)
* **Python:** 3.8.9
* **Platform:** darwin-monterey-m1
* **Concretizer:** clingo
and same for
* **Spack:** 0.21.0.dev0 (98957cf32aa809e831bee4af2bf642e2bd038c04)
* **Python:** 3.9.13
* **Platform:** darwin-monterey-x86_64
* **Concretizer:** clingo
Our previous spack version does not have the _iconv vs _libiconv problem:
* **Spack:** 0.20.0.dev0 (a041f7d05c59a90c2a37b281ac73052c9786a130)
* **Python:** 3.9.13
* **Platform:** darwin-monterey-x86_64
* **Concretizer:** clingo
Note that I have not yet run the "failing" commands in debug mode and reported the output. Waiting for my current spack install to finish.
General information
Steps to reproduce
I am updating our spack code from March this year to July, and I am having real problems with
libiconv. Previously, it worked just fine using homebrew’scmake,curl,wgetetc. Now I am getting all these undefined symbols_iconvwhich have to do with inconsistencies how these symbols are called (see https://stackoverflow.com/questions/57734434/libiconv-or-iconv-undefined-symbol-on-mac-osx).An easy solution seems to be to tell spack to just use homebrew’s
libiconvso that they are all consistent, but: makinglibiconvavailable as external package, setting it tobuildable: False, and even making it a conflict for Darwin is all ignored by spack.buildable: Falseand usingspack concretize --reuse.In packages.yaml:
Does anyone know why spack is ignoring the conflict statement and the external package / buildable: False flag?
Error message
Output of the concretizer:
Information on your system
and same for
Our previous spack version does not have the
_iconvvs_libiconvproblem:Note that I have not yet run the "failing" commands in debug mode and reported the output. Waiting for my current spack install to finish.
General information
spack debug reportand reported the version of Spack/Python/Platform