Describe the bug

The build using climbfuji:feature/merge_spack_develop_20230710 branch fails on macos with unreferenced symbols related to the iconv library. One example of an unresolved reference is _iconv.

Briefly, the issue is that GNU, in their iconv library, switched the names of several symbols by prepending "lib" in front of the older names. Eg, _iconv changed to _libiconv. On macos these symbol name changes have not occurred. Unfortunately, these changes are installed in the same file name as the macos iconv: libiconv.dylib which leads to much confusion.

Dom discovered that the way to get spack-stack to build, using his feature branch (ie, spack updates from the authoritative spack repo) on the mac was to force spack-stack to use the system (/usr/lib/libconv.dylib) iconv library.

This is compounded by a change Apple did back in the Big Sur timeframe (perhaps earlier) where the library files in /usr/lib were removed from disk, are loaded into memory in a section of the kernel, and the build tools (clang, ld, dyld, etc) on the macos make it appear that the /usr/lib files are still there when compiling and linking code. This was done to speed up app startup and to save disk space.

So, this change is designed to force the use of /usr/lib/libiconv.dylib for linking and shared library execution by declaring that libiconv.dylib is not buildable, and is located in /usr/lib. The "magic" of the macos build tools takes over at that point and makes it appear that /usr/lib/libiconv.dylib does indeed exist, can be linked against and can be "loaded" at runtime.

I picked an arbitrary version number (happens to be the latest version, 1.17, that is available today) for libiconv because spack concretize wouldn't accept the externals spec line without a version number. It doesn't matter what the version number is, since the macos "magic" ignores all of that; the version number is only there to make spack happy.

I put the these changes in the site template for macos since I wanted these changes to only be applied to the mac platform.

I'm open to suggestions if there is another way to accomplish this without having to use a fake version number in these changes, or any suggestion about a better way for that matter.

To Reproduce

build spack-stack using the current feature/merge_spack_develop_20230710 branches.

Expected behavior

The spack-stack build using the feature/merge_spack_develop_20230710 branches successfully complets.

System:

macos, ventura 13.5.1 (c), apple [email protected], [email protected]

Additional context

None