| 1 |
On 9/7/21 12:13 PM, Neil Bothwick wrote: |
| 2 |
> On Tue, 7 Sep 2021 09:32:41 -0700, Daniel Frey wrote: |
| 3 |
> |
| 4 |
>> Why is it checking the build environment for a binary package? |
| 5 |
> |
| 6 |
> I was wondering the same. |
| 7 |
> |
| 8 |
>> As it stands, I can't fix this problem. |
| 9 |
>> |
| 10 |
>> I tried editing the ebuild (removing the __thread check) and rebuilding |
| 11 |
>> the manifest but it still fails at the same place. I've double- and |
| 12 |
>> triple-checked it's the right ebuild but it's still running the checks! |
| 13 |
>> |
| 14 |
>> Some assistance on installing glibc would be much appreciated! |
| 15 |
> |
| 16 |
> You can untar the binary package into /, which bypasses the checks. Then |
| 17 |
> you can emerge it so that portage knows where it stands. |
| 18 |
> |
| 19 |
> The usual guarantees apply: if it breaks your system, you get to keep the |
| 20 |
> pieces. I'd backup / first. |
| 21 |
> |
| 22 |
> |
| 23 |
|
| 24 |
Thanks Neil, I just unpacked it manually and it fixed my problem. |
| 25 |
|
| 26 |
gcc actually works now so I've remerged (emerge -K1) glibc and pax-utils. |
| 27 |
|
| 28 |
I had a *really* old stage4-esque backup if it really came down to it. I |
| 29 |
think that's the first time a binary update (I have two identical PCs, a |
| 30 |
bit on the slow side - so one binpkgs them and I install them on the |
| 31 |
second one, lessening the compiling load.) |
| 32 |
|
| 33 |
Still don't know why glibc was checking the build environment for a |
| 34 |
binary package though, that was really strange. As gcc was broken and |
| 35 |
not providing any meaningful output for checks, it fails immediately. |
| 36 |
|
| 37 |
Dan |
Archives