Install libstdc++6:amd64 in the container#5
Merged
EliahKagan merged 3 commits intorun-ci/32bitfrom Nov 14, 2024
Merged
Conversation
With only `libssl3:amd64` and its dependencies, `actions/checkout`
did fail, but with a different error than before, showing a clear
error about a missing library, `libstdc++`.
/usr/bin/docker exec c1e55a75713e2c4fd08241fae9f4fecbe3cbb179be45174b3138390a1238090e sh -c "cat /etc/*release | grep ^ID"
/__e/node20/bin/node: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
Before trying adding that, I want to check that enabling `amd64` in
`dpkg` has the expected *no effect* on the error messages, compared
to not enabling it.
This does not add back libssl3:amd64 yet, in case it is not needed, though I expect that it will be needed.
EliahKagan
added a commit
that referenced
this pull request
Nov 14, 2024
Installing `nodejs:amd64` in a 32-bit container to work around actions/checkout#334 works by causing 64-bit libraries the external mapped `node20` needs (even though `nodejs:amd64` in Debian is Node 18), as described in actions/checkout#334 (comment). But this installed more packages than are needed. It turns out that, at least with this image, the only libraries the container is missing are the 32-bit libstdc++ and its dependencies. It is therefore sufficient to install the `libstdc++6:amd64` package. This commit makes that change, squashing a few investigatory steps that led to it (#5). * See if libssl3:amd64 is all we need * Temporarily omit even libssl3:amd64 With only `libssl3:amd64` and its dependencies, `actions/checkout` did fail, but with a different error than before, showing a clear error about a missing library, `libstdc++`. /usr/bin/docker exec c1e55a75713e2c4fd08241fae9f4fecbe3cbb179be45174b3138390a1238090e sh -c "cat /etc/*release | grep ^ID" /__e/node20/bin/node: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Before trying adding that, I want to check that enabling `amd64` in `dpkg` has the expected *no effect* on the error messages, compared to not enabling it. * Install libstdc++6:amd64 in the container This does not add back libssl3:amd64 yet, in case it is not needed, though I expect that it will be needed.
EliahKagan
added a commit
that referenced
this pull request
Nov 14, 2024
Installing `nodejs:amd64` in a 32-bit container to work around actions/checkout#334 works by causing 64-bit libraries the external mapped `node20` needs (even though `nodejs:amd64` in Debian is Node 18), as described in actions/checkout#334 (comment). But this installed more packages than are needed. It turns out that, at least with this image, the only libraries the container is missing are the 32-bit libstdc++ and its dependencies. It is therefore sufficient to install the `libstdc++6:amd64` package. This commit makes that change, squashing a few investigatory steps that led to it (#5). * See if libssl3:amd64 is all we need * Temporarily omit even libssl3:amd64 With only `libssl3:amd64` and its dependencies, `actions/checkout` did fail, but with a different error than before, showing a clear error about a missing library, `libstdc++`. /usr/bin/docker exec c1e55a75713e2c4fd08241fae9f4fecbe3cbb179be45174b3138390a1238090e sh -c "cat /etc/*release | grep ^ID" /__e/node20/bin/node: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Before trying adding that, I want to check that enabling `amd64` in `dpkg` has the expected *no effect* on the error messages, compared to not enabling it. * Install libstdc++6:amd64 in the container This does not add back libssl3:amd64 yet, in case it is not needed, though I expect that it will be needed.
EliahKagan
added a commit
that referenced
this pull request
Nov 14, 2024
Installing `nodejs:amd64` in a 32-bit container to work around actions/checkout#334 works by causing 64-bit libraries the external mapped `node20` needs (even though `nodejs:amd64` in Debian is Node 18), as described in actions/checkout#334 (comment). But this installed more packages than are needed. It turns out that, at least with this image, the only libraries the container is missing are the 32-bit libstdc++ and its dependencies. It is therefore sufficient to install the `libstdc++6:amd64` package. This commit makes that change, squashing a few investigatory steps that led to it (#5). * See if libssl3:amd64 is all we need * Temporarily omit even libssl3:amd64 With only `libssl3:amd64` and its dependencies, `actions/checkout` did fail, but with a different error than before, showing a clear error about a missing library, `libstdc++`. /usr/bin/docker exec c1e55a75713e2c4fd08241fae9f4fecbe3cbb179be45174b3138390a1238090e sh -c "cat /etc/*release | grep ^ID" /__e/node20/bin/node: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Before trying adding that, I want to check that enabling `amd64` in `dpkg` has the expected *no effect* on the error messages, compared to not enabling it. * Install libstdc++6:amd64 in the container This does not add back libssl3:amd64 yet, in case it is not needed, though I expect that it will be needed.
EliahKagan
added a commit
that referenced
this pull request
Nov 15, 2024
Installing `nodejs:amd64` in a 32-bit container to work around actions/checkout#334 works by causing 64-bit libraries the external mapped `node20` needs (even though `nodejs:amd64` in Debian is Node 18), as described in actions/checkout#334 (comment). But this installed more packages than are needed. It turns out that, at least with this image, the only libraries the container is missing are the 32-bit libstdc++ and its dependencies. It is therefore sufficient to install the `libstdc++6:amd64` package. This commit makes that change, squashing a few investigatory steps that led to it (#5). * See if libssl3:amd64 is all we need * Temporarily omit even libssl3:amd64 With only `libssl3:amd64` and its dependencies, `actions/checkout` did fail, but with a different error than before, showing a clear error about a missing library, `libstdc++`. /usr/bin/docker exec c1e55a75713e2c4fd08241fae9f4fecbe3cbb179be45174b3138390a1238090e sh -c "cat /etc/*release | grep ^ID" /__e/node20/bin/node: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Before trying adding that, I want to check that enabling `amd64` in `dpkg` has the expected *no effect* on the error messages, compared to not enabling it. * Install libstdc++6:amd64 in the container This does not add back libssl3:amd64 yet, in case it is not needed, though I expect that it will be needed.
EliahKagan
added a commit
that referenced
this pull request
Nov 15, 2024
Installing `nodejs:amd64` in a 32-bit container to work around actions/checkout#334 works by causing 64-bit libraries the external mapped `node20` needs (even though `nodejs:amd64` in Debian is Node 18), as described in actions/checkout#334 (comment). But this installed more packages than are needed. It turns out that, at least with this image, the only libraries the container is missing are the 32-bit libstdc++ and its dependencies. It is therefore sufficient to install the `libstdc++6:amd64` package. This commit makes that change, squashing a few investigatory steps that led to it (#5). * See if libssl3:amd64 is all we need * Temporarily omit even libssl3:amd64 With only `libssl3:amd64` and its dependencies, `actions/checkout` did fail, but with a different error than before, showing a clear error about a missing library, `libstdc++`. /usr/bin/docker exec c1e55a75713e2c4fd08241fae9f4fecbe3cbb179be45174b3138390a1238090e sh -c "cat /etc/*release | grep ^ID" /__e/node20/bin/node: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Before trying adding that, I want to check that enabling `amd64` in `dpkg` has the expected *no effect* on the error messages, compared to not enabling it. * Install libstdc++6:amd64 in the container This does not add back libssl3:amd64 yet, in case it is not needed, though I expect that it will be needed.
EliahKagan
added a commit
that referenced
this pull request
Nov 17, 2024
Installing `nodejs:amd64` in a 32-bit container to work around actions/checkout#334 works by causing 64-bit libraries the external mapped `node20` needs (even though `nodejs:amd64` in Debian is Node 18), as described in actions/checkout#334 (comment). But this installed more packages than are needed. It turns out that, at least with this image, the only libraries the container is missing are the 32-bit libstdc++ and its dependencies. It is therefore sufficient to install the `libstdc++6:amd64` package. This commit makes that change, squashing a few investigatory steps that led to it (#5). * See if libssl3:amd64 is all we need * Temporarily omit even libssl3:amd64 With only `libssl3:amd64` and its dependencies, `actions/checkout` did fail, but with a different error than before, showing a clear error about a missing library, `libstdc++`. /usr/bin/docker exec c1e55a75713e2c4fd08241fae9f4fecbe3cbb179be45174b3138390a1238090e sh -c "cat /etc/*release | grep ^ID" /__e/node20/bin/node: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Before trying adding that, I want to check that enabling `amd64` in `dpkg` has the expected *no effect* on the error messages, compared to not enabling it. * Install libstdc++6:amd64 in the container This does not add back libssl3:amd64 yet, in case it is not needed, though I expect that it will be needed.
EliahKagan
added a commit
that referenced
this pull request
Nov 17, 2024
Installing `nodejs:amd64` in a 32-bit container to work around actions/checkout#334 works by causing 64-bit libraries the external mapped `node20` needs (even though `nodejs:amd64` in Debian is Node 18), as described in actions/checkout#334 (comment). But this installed more packages than are needed. It turns out that, at least with this image, the only libraries the container is missing are the 32-bit libstdc++ and its dependencies. It is therefore sufficient to install the `libstdc++6:amd64` package. This commit makes that change, squashing a few investigatory steps that led to it (#5). * See if libssl3:amd64 is all we need * Temporarily omit even libssl3:amd64 With only `libssl3:amd64` and its dependencies, `actions/checkout` did fail, but with a different error than before, showing a clear error about a missing library, `libstdc++`. /usr/bin/docker exec c1e55a75713e2c4fd08241fae9f4fecbe3cbb179be45174b3138390a1238090e sh -c "cat /etc/*release | grep ^ID" /__e/node20/bin/node: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Before trying adding that, I want to check that enabling `amd64` in `dpkg` has the expected *no effect* on the error messages, compared to not enabling it. * Install libstdc++6:amd64 in the container This does not add back libssl3:amd64 yet, in case it is not needed, though I expect that it will be needed.
EliahKagan
added a commit
that referenced
this pull request
Nov 17, 2024
Installing `nodejs:amd64` in a 32-bit container to work around actions/checkout#334 works by causing 64-bit libraries the external mapped `node20` needs (even though `nodejs:amd64` in Debian is Node 18), as described in actions/checkout#334 (comment). But this installed more packages than are needed. It turns out that, at least with this image, the only libraries the container is missing are the 32-bit libstdc++ and its dependencies. It is therefore sufficient to install the `libstdc++6:amd64` package. This commit makes that change, squashing a few investigatory steps that led to it (#5). * See if libssl3:amd64 is all we need * Temporarily omit even libssl3:amd64 With only `libssl3:amd64` and its dependencies, `actions/checkout` did fail, but with a different error than before, showing a clear error about a missing library, `libstdc++`. /usr/bin/docker exec c1e55a75713e2c4fd08241fae9f4fecbe3cbb179be45174b3138390a1238090e sh -c "cat /etc/*release | grep ^ID" /__e/node20/bin/node: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Before trying adding that, I want to check that enabling `amd64` in `dpkg` has the expected *no effect* on the error messages, compared to not enabling it. * Install libstdc++6:amd64 in the container This does not add back libssl3:amd64 yet, in case it is not needed, though I expect that it will be needed.
EliahKagan
added a commit
that referenced
this pull request
Nov 17, 2024
Installing `nodejs:amd64` in a 32-bit container to work around actions/checkout#334 works by causing 64-bit libraries the external mapped `node20` needs (even though `nodejs:amd64` in Debian is Node 18), as described in actions/checkout#334 (comment). But this installed more packages than are needed. It turns out that, at least with this image, the only libraries the container is missing are the 32-bit libstdc++ and its dependencies. It is therefore sufficient to install the `libstdc++6:amd64` package. This commit makes that change, squashing a few investigatory steps that led to it (#5). * See if libssl3:amd64 is all we need * Temporarily omit even libssl3:amd64 With only `libssl3:amd64` and its dependencies, `actions/checkout` did fail, but with a different error than before, showing a clear error about a missing library, `libstdc++`. /usr/bin/docker exec c1e55a75713e2c4fd08241fae9f4fecbe3cbb179be45174b3138390a1238090e sh -c "cat /etc/*release | grep ^ID" /__e/node20/bin/node: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory Before trying adding that, I want to check that enabling `amd64` in `dpkg` has the expected *no effect* on the error messages, compared to not enabling it. * Install libstdc++6:amd64 in the container This does not add back libssl3:amd64 yet, in case it is not needed, though I expect that it will be needed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a fork-internal PR to update a feature branch with a squash, so the original history can be indefinitely preserved by reference to this PR. See 54c3f79 for context.
Installing
nodejs:amd64in a 32-bit container to work around actions/checkout#334 works by causing 64-bit libraries the external mappednode20needs (even thoughnodejs:amd64in Debian is Node 18), as described in actions/checkout#334 (comment). But this installed more packages than are needed.It turns out that, at least with this image, the only libraries the container is missing are the 32-bit libstdc++ and its dependencies. It is therefore sufficient to install the
libstdc++6:amd64package. This makes that change, squashing a few investigatory steps that led to it.