Repository: spack/spack

Issue:
Installation issue: boost@1.70.0 on Fedora 35
### Steps to reproduce the issue

On an installation of fedora 35:
```shell
$ spack install boost@1.70.0 cxxstd=17 %gcc9.4.0
```
The outcome is a variety of error messages like:

```shell
 >> 16215    ./boost/thread/pthread/thread_data.hpp:60:5: error: missing binary operator before token "("
     16216       60 | #if PTHREAD_STACK_MIN > 0
...
```

### Information on your system

```shell
$ spack debug report
* **Spack:** 0.17.1-730-a4f0fbafbb
* **Python:** 3.10.1
* **Platform:** linux-fedora35-broadwell
* **Concretizer:** clingo
```

### Additional information

[spack-build-out.txt](https://github.com/spack/spack/files/7818378/spack-build-out.txt)
[spack-build-env.txt](https://github.com/spack/spack/files/7818379/spack-build-env.txt)

@hainest 

As far as I can tell this is an issue related to recent changes in glibc.  Here's how they fixed it in other package managers: https://github.com/Ma27/nixpkgs/commit/87a628b1027363e8756c8bef7f6e4b71f190ee54

### 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:
@pbrady As much as I'd like to avoid adding yet another patch, it looks like we'll need to use the one you linked to. Have you tried building with that patch?
I haven't tried yet but I can give it a whirl tomorrow and put together a pull request if it works
@hainest I have a problem I'm not sure how to solve.  It seems that compilers I install with spack continue to use my system headers.  I say this because when I was on fedora 34, I could build `boost@1.70.0 %gcc@9.4.0` without any problems.  But on f35, the command triggers the above errors. So what is the correct way to restrict the patch?

If I do ` patch("pthread-stack-min-fix.patch", when="@1.69.0:1.72.0%gcc@11:")` then it compiles fine with my system compiler but still fails if I build via gcc@9.4.0 since it's pulling in my system headers.  I can loosen the restriction to something `%gcc@8:` but then it will be needlessly applying the patch to many non-broken versions.

What's the best path here? 
Actually, restricting on the compiler doesn't work since clang uses the the same system pthread headers (or has the same version) so on fedora35, the following also fails and should be patched:

`spack install boost@1.70.0 cxxstd=17 %clang`

Resolving patch:
diff --git a/var/spack/repos/builtin/packages/boost/package.py b/var/spack/repos/builtin/packages/boost/package.py
--- a/var/spack/repos/builtin/packages/boost/package.py
+++ b/var/spack/repos/builtin/packages/boost/package.py
@@ -310,6 +310,10 @@ def libs(self):
           when="@1.77.0",
           working_dir="tools/build")
 
+    # Fix issues with PTHREAD_STACK_MIN not being a DEFINED constant in newer glibc
+    # See https:://github.com/spack/spack/issues/28273
+    patch("pthread-stack-min-fix.patch", when="@1.69.0:1.73.0")
+
     def patch(self):
         # Disable SSSE3 and AVX2 when using the NVIDIA compiler
         if self.spec.satisfies('%nvhpc'):


Test patch: