Well,

I was updating a system and gcc got broken somehow, and it doesn't seem
to be possible to fix it.

Problem:
# gcc -v
gcc: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by gcc)

OK, no biggie, I have a binpkg:

# emerge -1Ka glibc pax-utils

These are the packages that would be merged, in order:

Calculating dependencies... done!
[binary U ] app-misc/pax-utils-1.3.2 [1.2.9] PYTHON_SINGLE_TARGET="python3_9* (-python3_10) -python3_8*"
[binary U ] sys-libs/glibc-2.33-r1 [2.32-r7] USE="-multilib-bootstrap%"


But:

Running pre-merge checks for sys-libs/glibc-2.33-r1

* glibc-2.33-r1.tbz2 MD5 SHA1 size ;-) ...
[ ok ]
* Checking general environment sanity.
x86_64-pc-linux-gnu-gcc -m64 -pipe -march=corei7 -O2 -Wl,-O1
-Wl,--as-needed glibc-test.c -o glibc-test
* Checking gcc for __thread support ...


[ !! ]

* Could not find a gcc that supports the __thread directive!
* Please update your binutils/gcc and try again.
* ERROR: sys-libs/glibc-2.33-r1::gentoo failed (pretend phase):
* No __thread support in gcc!
*
* Call stack:
* ebuild.sh, line 125: Called pkg_pretend
* environment, line 2739: Called sanity_prechecks
* environment, line 3337: Called die
* The specific snippet of code:
* die "No __thread support in gcc!";
*
* If you need support, post the output of `emerge --info '=sys-libs/glibc-2.33-r1::gentoo'`,
* the complete build log and the output of `emerge -pqv '=sys-libs/glibc-2.33-r1::gentoo'`.
* The complete build log is located at '/var/tmp/portage/sys-libs/glibc-2.33-r1/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/sys-libs/glibc-2.33-r1/temp/environment'.
* Working directory: '/var/tmp/portage/sys-libs/glibc-2.33-r1/homedir'
* S: '/var/tmp/portage/sys-libs/glibc-2.33-r1/work/glibc-2.33'

Failed to emerge sys-libs/glibc-2.33-r1, Log file:

Why is it checking the build environment for a binary package?

As it stands, I can't fix this problem.

I tried editing the ebuild (removing the __thread check) and rebuilding
the manifest but it still fails at the same place. I've double- and triple-checked it's the right ebuild but it's still running the checks!

Some assistance on installing glibc would be much appreciated!

Dan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 7 Sep 2021 09:32:41 -0700, Daniel Frey wrote:

Why is it checking the build environment for a binary package?

I was wondering the same.

As it stands, I can't fix this problem.

I tried editing the ebuild (removing the __thread check) and rebuilding
the manifest but it still fails at the same place. I've double- and triple-checked it's the right ebuild but it's still running the checks!

Some assistance on installing glibc would be much appreciated!

You can untar the binary package into /, which bypasses the checks. Then
you can emerge it so that portage knows where it stands.

The usual guarantees apply: if it breaks your system, you get to keep the pieces. I'd backup / first.


--
Neil Bothwick

*Libra*: /(Sept 23--Oct 23)/ An unfortunate typo on your application
results in your being accepted into the Legion Of Superherpes.

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEE8k9T/rX16EJxEKG692eFu0QSMJgFAmE3ufUACgkQ92eFu0QS MJh4Dw//Wutv7DVjjelBa7Y9YQZsMjZmyMHy1uSvlSL6G4GQEmfDfqwd5KfYUk5p InePY19bVE7pwkrOy08ez7hagq5U2NZZMMVqZoAQ72Tp42zfWi1y8Xb6ZQzBI0iJ U81M0vsBRWSrtIWQ3LuLq54HAp7ZEWAn5wueAJPXC/BSJt/f1IIGeuW6TgAg46up 16hOF4MVki1SQP0Qm5ygIm1DHz069FVfUTLjLFThDg+vOU4sB6J//43pQAjveRvh Wfr7xi+XMVzrwiX2pU0Qo/FRUZOlGUvKlswumyHnuywVICx8Ft4CC2XbIjcJlqEM RuwM+jDCiX3YF7gWYOQYH9MsSuWQKyz16/WS+SA2HVfL9hEBVdJEGLPlO98yzi7J 5Yh60st4mncjKahnLCXDg+JvZMxDTd3AK9CwXgJR3v2+2hJQFygWrLW7mPbZSOAJ ZXdTFwVIIKGveZw/qIRzMgxxZcnl9bCItFgV//UtTnPSFdKbp8VPnALnPWvMF7To dh75ApzRlOACzXOc3MueyuTTuiwcy+ILSdJqVazvGMo7VF85E7/+hp4lEUpA9FYk edXfykvqBsyGxlhSELJzTfaD8bt5Z557GyhK0LiS9GiysXVo9qlPp3YcANiFccvG OzWf379OmkY2i7CiWK9Cti0orQL9YSIuoMs82DbL08EFDm5SgJU=
=kzWG
-----END PGP SIGNATURE-----

--- SoupGate-Wi

On 9/7/21 12:13 PM, Neil Bothwick wrote:

On Tue, 7 Sep 2021 09:32:41 -0700, Daniel Frey wrote:

Why is it checking the build environment for a binary package?

I was wondering the same.

As it stands, I can't fix this problem.

I tried editing the ebuild (removing the __thread check) and rebuilding
the manifest but it still fails at the same place. I've double- and
triple-checked it's the right ebuild but it's still running the checks!

Some assistance on installing glibc would be much appreciated!

You can untar the binary package into /, which bypasses the checks. Then
you can emerge it so that portage knows where it stands.

The usual guarantees apply: if it breaks your system, you get to keep the pieces. I'd backup / first.

Thanks Neil, I just unpacked it manually and it fixed my problem.

gcc actually works now so I've remerged (emerge -K1) glibc and pax-utils.

I had a *really* old stage4-esque backup if it really came down to it. I
think that's the first time a binary update (I have two identical PCs, a
bit on the slow side - so one binpkgs them and I install them on the
second one, lessening the compiling load.)

Still don't know why glibc was checking the build environment for a
binary package though, that was really strange. As gcc was broken and
not providing any meaningful output for checks, it fails immediately.

Dan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)