Repository: spack/spack

Issue:
Installation issue: clingo-bootsrap
### Steps to reproduce the issue

```console
$ spack solve zlib
```

### Information on your system

* **Spack:** 0.16.3
* **Python:** 3.6.8
* **Platform:** linux-rhel8-power9le

### Additional information

@alalazo 
[clingo-bootstrap-error.txt](https://github.com/spack/spack/files/7270917/clingo-bootstrap-error.txt)

I just cleared out the cache to test the solution, so hopefully this output from `spack -d solve zlib` will be enough. If not, I will go back to a clean slate and rebuild the bootstrap phase.

It looks like the bootstrap clingo installation assumes that the static version of libstdc++ exists by adding the option `-static-libstdc++`. See here: https://github.com/spack/spack/blob/314f5fdb974260c31e84245513756f5ca67b06f6/var/spack/repos/builtin/packages/clingo-bootstrap/package.py#L63

My system doesn't have static libstdc++ installed, so static linking was causing an issue. The build error on my system was resolved by removing the `-static-libstdc++` and `-static-libgcc` flags.


### 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


Discussion:
@alalazo: should we disable `-static-libstdc++` when building from source? 
Let me check what are our defaults for installing GCC. The issue here is that to solve this long term we need compiler as dependencies (i.e. we need to be able to say `clingo` has a dependency on `libstdc++` and have that reflected in the spec and DB). 

Relaxing the requirement on having a static `libstdc++` when building from sources means trading errors of this type (which occur upfront) with errors occurring because the shared library clingo depends on disappeared. Think for instance uninstalling the compiler used for `clingo` because a newer one was installed.

Also, starting with v0.17.0 (or current `develop`) this should be less problematic since we bootstrap from binaries by default.
@alalazo: I'm saying that for the bootstrapped binaries we'd still use `--static-libstdc++`, but when bootstrapping from source we'd turn it off.  So the source bootstrap and binary bootstrap would actually be building different specs.  I think this is a fairly simple tweak to the code that builds the bootstrap clingo, right?
> I'm saying that for the bootstrapped binaries we'd still use --static-libstdc++, but when bootstrapping from source we'd turn it off. 

@tgamblin Sure, that was clear. What I'm saying is that relying on shared libraries in the latter case doesn't solve all the issues. It solves this one, but opens for others related to Spack not tracking the `libstdc++` dependency.

Here's an example use case that I have in mind. Say we have a Spack installed GCC (from previous versions or a buildcache). Spack installs by default:
```console
$ ls store/linux-ubuntu20.04-icelake/gcc-9.3.0/gcc-11.2.0-pkrjhy4suh6f2ucppcte4tw65hbmmako/lib64/
libasan.a           libcc1.so             libgfortran.spec  libitm.so.1.0.0    libquadmath.so.0      libstdc++fs.a               libtsan.so.0
libasan_preinit.o   libcc1.so.0           libgomp.a         libitm.spec        libquadmath.so.0.0.0  libstdc++.so                libtsan.so.0.0.0
libasan.so          libcc1.so.0.0.0       libgomp.so        liblsan.a          libsanitizer.spec     libstdc++.so.6              libubsan.a
libasan.so.6        libgcc_s.so           libgomp.so.1      liblsan_preinit.o  libssp.a              libstdc++.so.6.0.29         libubsan.so
libasan.so.6.0.0    libgcc_s.so.1         libgomp.so.1.0.0  liblsan.so         libssp_nonshared.a    libstdc++.so.6.0.29-gdb.py  libubsan.so.1
libatomic.a         libgfortran.a         libgomp.spec      liblsan.so.0       libssp.so             libsupc++.a                 libubsan.so.1.0.0
libatomic.so        libgfortran.so        libitm.a          liblsan.so.0.0.0   libssp.so.0           libtsan.a
libatomic.so.1      libgfortran.so.5      libitm.so         libquadmath.a      libssp.so.0.0.0       libtsan_preinit.o
libatomic.so.1.2.0  libgfortran.so.5.0.0  libitm.so.1       libquadmath.so     libstdc++.a           libtsan.so
```
so static libraries are there. If we bootstrap `clingo` right now and later uninstall this GCC things continue working. If we rely on shared libraries we'll have errors saying that clingo can't load `libstdc++.so` as soon as we uninstall that GCC (and no warning that say that the GCC is used by another spec).

> I think this is a fairly simple tweak to the code that builds the bootstrap clingo, right?

Sure, even though I need to check if it is better for maintainability to add a variant to `clingo-bootstrap` or rather change the package used in from source build to be regular `clingo`. I think it might be best to do the latter, but need to check the details.
@jacobmerson My understanding is that this happen with v0.16.3 Can you check if `develop` bootstraps (from binaries) correctly for you?

I'll be submitting a PR shortly relaxing the requirements when building from sources but I'd like to confirm that the bootstrapping logic in its current state on `develop` is working on your platform.

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/clingo-bootstrap/package.py b/var/spack/repos/builtin/packages/clingo-bootstrap/package.py
--- a/var/spack/repos/builtin/packages/clingo-bootstrap/package.py
+++ b/var/spack/repos/builtin/packages/clingo-bootstrap/package.py
@@ -14,6 +14,9 @@ class ClingoBootstrap(Clingo):
     variant('build_type', default='Release', values=('Release',),
             description='CMake build type')
 
+    variant('static_libstdcpp', default=False,
+            description='Require a static version of libstdc++')
+
     # CMake at version 3.16.0 or higher has the possibility to force the
     # Python interpreter, which is crucial to build against external Python
     # in environment where more than one interpreter is in the same prefix
@@ -56,14 +59,17 @@ def cmake_args(self):
         return args
 
     def setup_build_environment(self, env):
+        opts = None
         if '%apple-clang platform=darwin' in self.spec:
             opts = '-mmacosx-version-min=10.13'
         elif '%gcc' in self.spec:
-            # This is either linux or cray
-            opts = '-static-libstdc++ -static-libgcc -Wl,--exclude-libs,ALL'
+            if '+static_libstdcpp' in self.spec:
+                # This is either linux or cray
+                opts = '-static-libstdc++ -static-libgcc -Wl,--exclude-libs,ALL'
         else:
             msg = 'unexpected compiler for spec "{0}"'.format(self.spec)
             raise RuntimeError(msg)
 
-        env.set('CXXFLAGS', opts)
-        env.set('LDFLAGS', opts)
+        if opts:
+            env.set('CXXFLAGS', opts)
+            env.set('LDFLAGS', opts)


Test patch: