[gentoo-user] Broken update

[Daniel Frey]

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

[Neil Bothwick]

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.

[Daniel Frey]

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