gcc-runtime: add separate package for gcc runtime libs by haampie · Pull Request #41104 · spack/spack

haampie · 2023-11-16T09:09:02Z

The gcc-runtime package adds a separate node for gcc's dynamic runtime
libraries.

The good:

Fixes a bug where references to gcc runtime libs are not relocated when
installing from build cache, since we don't keep track of their location.
Allows users to create minimal containers easily: no need to keep the
compilers around or do multistage builds where the second stage needs to run
another package manager for compiler support libs.
spack uninstall gcc without breaking binaries built with that gcc.
With multiple %gcc versions, the newest GCC's runtime libs are used and
this node is unique. A spec pkg%gcc@x.y.z always means that pkg was
linked to GCC x.y.z runtime libraries, even if its ^gcc-runtime is newer.

The bad:

GCC only (and not on Windows)

The ugly:

Does not specify conflicts between mixing GCC runtimes that have seen an
ABI breaking change (e.g. gcc 7 vs 8 has a libgfortran soname bump). I'll leave
this for later when we do provides("fortran@...") etc.

Notice: Libraries are copied with filename = soname. Only the compiler package
has the "linkable" library w/o suffix. This ensures that the %gcc@x compiler
property is correct, even if ^gcc-runtime@y is at a newer version.

Future ideas

If packages specify:

class Pkg:
  language("fortran")

  depends_on("gcc-runtime@x:", when="%gcc@x") # compat triangle

  with when("language=fortran"):
    depends_on("gfortran@3", when="%gcc@:6")
    depends_on("gfortran@4", when="%gcc@7")
    depends_on("gfortran@5", when="%gcc@8:")

and gcc-runtime provides those:

class GccRuntime:
  provides("gfortran@3", when="%gcc@:6")
  provides("gfortran@4", when="%gcc@7")
  provides("gfortran@5", when="%gcc@8:")

we can ensure that there's only one unique ABI for libgfortran.so.X

Notice that there is no immediate need to specify the language of all 7K
packages. It can be done package by package going forward, since the
language only imposes additional constraints on gcc-runtime.

Only when we've identified all C, C++, and Fortran packages can we
proceed with dropping the compiler attribute / node so that pure python
packages et cetera won't need a compiler to install.

lib/spack/spack/directives.py

haampie · 2023-11-16T09:13:40Z

@gartung / @giordano this might be of interest to you

haampie · 2023-11-16T10:34:29Z

@giordano I tested that julia docker image again, and it works out of the box now:

$ docker run -it --rm ghcr.io/haampie/testing:julia-1.8.5-4zau5qa2smow3zety5zye23iocqjox6y.spack julia
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.8.5 (2023-01-08)
 _/ |\__'_|_|_|\__'_|  |  
|__/                   |

julia> 1+2
3

(don't ask me why I started building julia 1.8, somehow the concretizer picked that 😆)

Had to still set SSL_CERT_FILE though to make julia locate ssl certs from ca-certificates-mozilla

haampie · 2023-11-16T12:59:22Z

@alalazo we should really find a way to ensure that changes to build systems / base package do not affect tests, it's a bit annoying

gartung · 2023-11-17T18:27:45Z

Built gcc12 with system compiler (gcc11 on AlmaLinux9) and the gcc-runtime was correctly created for that. Add that compiler to the config and built boost@gcc12 cxxstd=20. No gcc-runtime install for gcc12. The gcc12 rpaths are added but the gcc-runtime paths are from gcc11.

[jenkins@buildservice101 lib]$ ldd libboost_atomic.so
        linux-vdso.so.1 (0x00007ffc1538b000)
        libstdc++.so.6 => /scratch/workspace/SE-376/label1/ALMA9/spack_env/opt/spack/linux-almalinux9-x86_64_v2/gcc-11.3.1/gcc-12.2.0-lsevyxfpza75ujetp4dzulu54irim46l/lib64/libstdc++.so.6 (0x000015487e800000)
        libm.so.6 => /lib64/libm.so.6 (0x000015487ea51000)
        libgcc_s.so.1 => /scratch/workspace/SE-376/label1/ALMA9/spack_env/opt/linux-almalinux9-x86_64_v2/gcc-11.3.1/gcc-12.2.0-lsevyxfpza75ujetp4dzulu54irim46l/lib64/libgcc_s.so.1 (0x000015487e7de000)
        libc.so.6 => /lib64/libc.so.6 (0x000015487e400000)
        /lib64/ld-linux-x86-64.so.2 (0x000015487eb52000)

[jenkins@buildservice101 lib]$ patchelf --print-rpath libboost_atomic.so | tr ':' '\n'
/scratch/workspace/SE-376/label1/ALMA9/spack_env/opt/spack/linux-almalinux9-x86_64_v2/gcc-11.3.1/gcc-12.2.0-lsevyxfpza75ujetp4dzulu54irim46l/lib64
/scratch/workspace/SE-376/label1/ALMA9/spack_env/opt/spack/linux-almalinux9-x86_64_v2/gcc-12.2.0/boost-1.82.0-zch3yj3oy4pqxgbf7pylp3nm2hgcglbk/lib
/scratch/workspace/SE-376/label1/ALMA9/spack_env/opt/spack/linux-almalinux9-x86_64_v2/gcc-11.3.1/gcc-runtime-1.0-pk65rthwwqlsqwf5pp5ttwzgfvghmbv3/lib
/scratch/workspace/SE-376/label1/ALMA9/spack_env/opt/spack/linux-almalinux9-x86_64_v2/gcc-11.3.1/gcc-12.2.0-lsevyxfpza75ujetp4dzulu54irim46l/lib/gcc/x86_64-pc-linux-gnu/12.2.0

lib/spack/spack/package_base.py

haampie · 2023-11-20T14:00:51Z

Currently this requires specifying %gcc because it's "better" to use %clang to avoid picking an "old" gcc-runtime.

gartung · 2023-11-22T16:31:53Z

Did a quick test with gcc@12.1.1 from RedHat gcc-toolset-12. I needed to add 12.1.1 to the list of versions but after that boost concretized.

haampie · 2023-11-22T16:34:31Z

Yeah, RedHat uses unofficial GCC versions

gartung · 2023-11-22T16:39:48Z

I am trying a build now with a Spack built compiler and a package that builds binaries. Boost doesn't build libraries by default.

gartung · 2023-11-22T16:59:41Z

When I concretize a package individually the implicit dependence on gcc_runtime shows up. When I concretize an environment with the same package in it, the implicit dependence on gcc_runtime does not show up.

haampie · 2023-12-15T15:34:31Z

I just spent some time debugging an issue reported on Slack where cmake%gcc@13 was installed on Ubuntu 22.04 with spack installed GCC, which segfaulted later cause system libstdc++ was picked up instead of original libstdc++ (same issue as reported by @gartung).

Let's get this PR in... it solves tons of annoying issues.

gartung · 2023-12-18T14:19:26Z

@alalazo It appears that I can merge this pull request. Should I merge it?

haampie · 2023-12-18T14:28:04Z

Let's give @tgamblin a moment to look at it too

gartung · 2023-12-18T14:46:44Z

Was I given merge privileges because I was "assigned" to this PR?

haampie · 2023-12-18T14:54:31Z

You're member of the spack/merge-to-develop group, for a long time I think, meaning you can merge any pr.

var/spack/repos/compiler_runtime.test/repo.yaml

haampie · 2023-12-20T21:02:14Z

I don't see the point of merging the commits separately, they can't be reverted out of order.

Feel free to squash merge.

lib/spack/spack/solver/asp.py

var/spack/repos/builtin/packages/gcc/package.py

lib/spack/spack/test/conftest.py

share/spack/gitlab/cloud_pipelines/stacks/e4s-cray-rhel/spack.yaml

share/spack/gitlab/cloud_pipelines/stacks/e4s-oneapi/spack.yaml

lib/spack/spack/solver/asp.py

var/spack/repos/builtin/packages/gcc-runtime/package.py

tgamblin · 2023-12-21T00:26:00Z

var/spack/repos/builtin/packages/gcc-runtime/package.py

+            if not os.path.isabs(path):
+                continue


This and the other continue below worry me because I think this loop can fail if we encounter a weird gcc.

I think this should fail if it doesn't find at least gcc_s. Are there others in LIBRARIES that we'd always expect to find? Seems worthwhile to include some minimum set of requirements on the library list produced here, and fail if we do not find those. Better to fail fast than to give someone a gcc-runtime that does nothing.

Would make spack unusable when gcc is configured with --disable-shared

I've pushed a commit that warns when nothing is found. It's certainly wrong to error.

If it’s wrong to error with disable-shared, maybe leaving it is fine. Warning is probably good for now… ideally we could tell if it’s supposed to have —disable-shared and only fail when we expect no runtime libs.

With disable-shared there’s not really a dependency on the runtime libs anyway, or at least not the same sort of dep, so that’s yet another modeling problem to deal with.

Yeah, unfortunately that info is not part of the spec, so gcc-runtime in a build cache is no guarantee it'll work with other people's gcc at the same version when building on top of it : (. We could deal with it later: gcc-runtime +shared-X or something. Or always splice gcc-runtime to get the local gcc's version of it.

We can also split libraries according to e.g. languages later

var/spack/repos/builtin/packages/gcc-runtime/package.py

alalazo · 2023-12-21T07:44:58Z

I don't see the point of merging the commits separately, they can't be reverted out of order. Feel free to squash merge.

For what is worth, I don't think we'll revert this - in the worst case we can just comment out / remove the few lines in GCC. Having two separate commits has the slight benefit of leaving blame traces, and allowing more specific details in the commit comments without getting the commit message too long.

TL;DR I still prefer "rebase and merge", but am fine with both.

tgamblin · 2023-12-21T08:23:28Z

I'll make a revert for both if needed (you can squash it on a separate branch, revert the squash, and cherry pick it)

The gcc-runtime package adds a separate node for gcc's dynamic runtime libraries. This should help with: 1. binary caches where rpaths for compiler support libs cannot be relocated because the compiler is missing on the target system 2. creating "minimal" container images The package is versioned like `gcc` (in principle it could be unversioned, but Spack doesn't always guarantee not mixing compilers)

* Restore PackageBase class, and modify only ASP This prevents a noticeable slowdown in concretization due to the number of directives involved. * Fix issue with 'clang' being preferred to 'gcc', due to runtime version weights * Constraints on runtimes are declared by compilers The declaration of available runtime versions, and of their compatibility constraints are in the associated compiler class. Co-authored-by: Harmen Stoppels <harmenstoppels@gmail.com>

haampie · 2023-12-21T12:06:30Z

Let's avoid further changes to gcc-runtime unless necessary, cause it causes rebuilds of 1000s of packages

spackbot-app bot added core PR affects Spack core functionality dependencies directives new-package new-version labels Nov 16, 2023

haampie commented Nov 16, 2023

View reviewed changes

lib/spack/spack/directives.py Outdated Show resolved Hide resolved

haampie force-pushed the feature/gcc-runtime-package branch 2 times, most recently from 44c3b7b to e37cd18 Compare November 16, 2023 09:12

haampie force-pushed the feature/gcc-runtime-package branch from e37cd18 to b11ec0e Compare November 16, 2023 09:53

spackbot-app bot added the libraries label Nov 16, 2023

haampie force-pushed the feature/gcc-runtime-package branch from b11ec0e to 81ee5ea Compare November 16, 2023 11:37

gartung approved these changes Nov 16, 2023

View reviewed changes

tldahlgren assigned gartung Nov 16, 2023

gartung requested changes Nov 17, 2023

View reviewed changes

lib/spack/spack/package_base.py Outdated Show resolved Hide resolved

gartung self-requested a review November 17, 2023 19:37

spackbot-app bot added the tests General test capability(ies) label Nov 20, 2023

haampie force-pushed the feature/gcc-runtime-package branch from c2d7e06 to 88837ea Compare November 20, 2023 13:06

haampie force-pushed the feature/gcc-runtime-package branch 2 times, most recently from d86e754 to b8ed70e Compare November 20, 2023 18:15

spackbot-app bot added the headers label Nov 20, 2023

haampie force-pushed the feature/gcc-runtime-package branch from b8ed70e to d7b4493 Compare November 20, 2023 18:28

alalazo self-assigned this Dec 15, 2023

gartung self-requested a review December 18, 2023 14:17

gartung previously approved these changes Dec 18, 2023

View reviewed changes

haampie dismissed stale reviews from gartung and alalazo via 1ae88dc December 20, 2023 19:41

haampie force-pushed the feature/gcc-runtime-package branch from 1ae88dc to aff4c95 Compare December 20, 2023 20:13

haampie commented Dec 20, 2023

View reviewed changes

var/spack/repos/compiler_runtime.test/repo.yaml Outdated Show resolved Hide resolved

haampie force-pushed the feature/gcc-runtime-package branch 2 times, most recently from befb3bb to c717b24 Compare December 20, 2023 21:01

haampie force-pushed the feature/gcc-runtime-package branch from c717b24 to 7df24ef Compare December 20, 2023 21:40

tgamblin requested changes Dec 21, 2023

View reviewed changes

haampie and others added 2 commits December 21, 2023 12:00

alalazo force-pushed the feature/gcc-runtime-package branch from 0bb4198 to 9437139 Compare December 21, 2023 11:16

tgamblin approved these changes Dec 21, 2023

View reviewed changes

tgamblin enabled auto-merge (rebase) December 21, 2023 15:17

tgamblin merged commit ea7e3e4 into spack:develop Dec 21, 2023

haampie deleted the feature/gcc-runtime-package branch December 22, 2023 18:47

w8jcik mentioned this pull request Feb 13, 2024

Installation issue: zlib #41528

Closed

4 tasks

tgamblin mentioned this pull request Apr 29, 2024

Implement relocation for compiler runtime paths #7120

Closed

2 tasks

marcodelapierre mentioned this pull request May 17, 2024

Update Spack templates/tests: add OS packages seqeralabs/libseqera#10

Closed

Conversation

haampie commented Nov 16, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Future ideas

Uh oh!

Uh oh!

haampie commented Nov 16, 2023

Uh oh!

haampie commented Nov 16, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

haampie commented Nov 16, 2023

Uh oh!

gartung commented Nov 17, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

haampie commented Nov 20, 2023

Uh oh!

gartung commented Nov 22, 2023

Uh oh!

haampie commented Nov 22, 2023

Uh oh!

gartung commented Nov 22, 2023

Uh oh!

gartung commented Nov 22, 2023

Uh oh!

haampie commented Dec 15, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

gartung commented Dec 18, 2023

Uh oh!

haampie commented Dec 18, 2023

Uh oh!

gartung commented Dec 18, 2023

Uh oh!

haampie commented Dec 18, 2023

Uh oh!

Uh oh!

haampie commented Dec 20, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

tgamblin Dec 21, 2023

Choose a reason for hiding this comment

Uh oh!

haampie Dec 21, 2023

Choose a reason for hiding this comment

Uh oh!

haampie Dec 21, 2023

Choose a reason for hiding this comment

Uh oh!

tgamblin Dec 21, 2023

Choose a reason for hiding this comment

Uh oh!

haampie Dec 21, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alalazo Dec 21, 2023

Choose a reason for hiding this comment

Uh oh!

Uh oh!

alalazo commented Dec 21, 2023

Uh oh!

tgamblin commented Dec 21, 2023

Uh oh!

haampie commented Dec 21, 2023 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

haampie commented Nov 16, 2023 •

edited

Loading

haampie commented Nov 16, 2023 •

edited

Loading

gartung commented Nov 17, 2023 •

edited

Loading

haampie commented Dec 15, 2023 •

edited

Loading

haampie commented Dec 20, 2023 •

edited

Loading

haampie Dec 21, 2023 •

edited

Loading

haampie commented Dec 21, 2023 •

edited

Loading