GLibC cannot be found..?

[leyvi]

Check this out; basically all my packages are failing to build for similar reasons. Always some part of glibc is missing. The libraries are definitely there, and I even rebuilt them. No luck though.

What on earth is going on? How do I fix this?

[sam_]

../fuse-3.18.1/lib/meson.build:40:14: ERROR: C shared or static library 'rt' not found

A full log can be found at /var/tmp/portage/sys-fs/fuse-3.18.1/work/fuse-3.18.1-abi_x86_32.x86/meson-logs/meson-log.txt
[31;01m*[0m ERROR: sys-fs/fuse-3.18.1::gentoo failed (configure phase):
[...]
[31;01m*[0m If you need support, post the output of `emerge --info '=sys-fs/fuse-3.18.1::gentoo'`,
[31;01m*[0m the complete build log and the output of `emerge -pqv '=sys-fs/fuse-3.18.1::gentoo'`.
[31;01m*[0m The complete build log is located at '/var/log/portage/build-logs/sys-fs:fuse-3.18.1:20260127-020040.log'.
[31;01m*[0m The ebuild environment file is located at '/var/tmp/portage/sys-fs/fuse-3.18.1/temp/environment'.
[31;01m*[0m Working directory: '/var/tmp/portage/sys-fs/fuse-3.18.1/work/fuse-3.18.1-abi_x86_32.x86'
[31;01m*[0m S: '/var/tmp/portage/sys-fs/fuse-3.18.1/work/fuse-3.18.1'

You know more than well enough how to help us help you.

[leyvi]

../fuse-3.18.1/lib/meson.build:40:14: ERROR: C shared or static library 'rt' not found

A full log can be found at /var/tmp/portage/sys-fs/fuse-3.18.1/work/fuse-3.18.1-abi_x86_32.x86/meson-logs/meson-log.txt
[31;01m*[0m ERROR: sys-fs/fuse-3.18.1::gentoo failed (configure phase):
[...]
[31;01m*[0m If you need support, post the output of `emerge --info '=sys-fs/fuse-3.18.1::gentoo'`,
[31;01m*[0m the complete build log and the output of `emerge -pqv '=sys-fs/fuse-3.18.1::gentoo'`.
[31;01m*[0m The complete build log is located at '/var/log/portage/build-logs/sys-fs:fuse-3.18.1:20260127-020040.log'.
[31;01m*[0m The ebuild environment file is located at '/var/tmp/portage/sys-fs/fuse-3.18.1/temp/environment'.
[31;01m*[0m Working directory: '/var/tmp/portage/sys-fs/fuse-3.18.1/work/fuse-3.18.1-abi_x86_32.x86'
[31;01m*[0m S: '/var/tmp/portage/sys-fs/fuse-3.18.1/work/fuse-3.18.1'

You know more than well enough how to help us help you.

Yeah, sorry about that. This is the output of emerge --info, I'm leaving town now so I don't have time to post any additional information, like the environment file. Note that there's nothing of interest in emerge -pqv '=sys-fs/fuse-3.18.1::gentoo'.

[Hu]

It seems fair to assume that this is a local issue, not something that a Gentoo developer broke for everyone. If we assume that, then only someone with access to the broken system, or with access to significant logs from that system, can possibly help you. Although emerge -pqv output is probably not needed, I believe that as a matter of course, if the developers thought it important enough to have Portage prompt you to share it, then you should share it. It's short, and quite possibly would have been simpler to share than to write your statement assuring us that it has nothing useful. Following the rest of the instructions you quoted, particularly around meson-log.txt, has a good chance of being interesting.

[flexibeast]

Fwiw, my own heuristic is: As a starting point, assume that the issue is something specific to my system first, particularly if the problem involves a component that's either core or widely used, yet doesn't seem to have many (or any) other people encountering the issue. There might indeed turn out to be a bug in the libc, or the compiler, or whatever, but there are other things that are more likely - including misconfiguration / incorrect usage on my part - that need to be ruled out first.

[leyvi]

Yes, I assume that the issue is with my configuration.

Now that I'm back home, I'm going to get that environment file.

One moment, please.

[leyvi]

Alright, here is a list of environment files from all the packages that failed, labeled:

• app-crypt/johntheripper-jumbo-1.9.0_p20250703
• app-crypt/p11-kit-0.25.10
• dev-libs/expat-2.7.4
• dev-libs/jemalloc-5.3.0-r2
• dev-libs/libxml2-2.15.1
• dev-libs/openssl-3.5.5
• media-libs/libpng-1.6.54
• sys-apps/systemd-utils-259-r2
• sys-fs/fuse-3.18.1
• sys-kernel/dracut-109-r1
• sys-libs/pam-1.7.2

[SCR4MBL3]

Hello!

As you may see in my profile I am a 'N00b', so don't expect me to be a professional or anything...

But, the first log says that the library missing is 'rt'. If I were you, I would search for some information related to USE flags and rt, because most of this problems are related to USE flags issues.

PS: This may be helpful... https://github.com/abhiTronix/raspberry ... issues/106

[Hu]

As OP determined, sys-libs/glibc is the typical provider of librt.so.1. I see no USE flags on glibc that seem likely to allow removing it. However, per the build.log that sam_ quoted when hinting to the OP that Portage's instructions are important, the 32-bit rt was not found. That is why I reiterated to OP that he should provide meson-log.txt. We are currently waiting for him to do so.

[NeddySeagoon]

Team,

I'll put two shillings 'on the nose' that we have a no-multilib profile in use on a multilib install.
This can/will break 32 bit support.

For a place, the kernel does not support 32 bit code' so the test fails.

[Hu]

OP's pastebin'd emerge --info starts:

Code: Select all

Portage 3.0.77 (python 3.14.2-final-0, default/linux/amd64/23.0/split-usr/desktop/plasma, gcc-15, glibc-2.42-r5, 6.17.5-gentoo-r1 x86_64)

So it's not currently a no-multilib profile. However, OP might have run no-multilib at some point, and later performed an incorrect conversion. The output of emerge --pretend --verbose sys-libs/glibc might be interesting.

[leyvi]

The output of emerge --pretend --verbose sys-libs/glibc might be interesting.

Code: Select all

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

Calculating dependencies... done!
Dependency resolution took 4.40 s (backtrack: 0/500).

[ebuild   R    ] sys-libs/glibc                                        [2.42-r5:2.2::gentoo]         USE="cet doc gd hash-sysv-compat multiarch (multilib) profile ssp stack-realign (static-libs) verify-sig -audit -caps -compile-locales (-custom-cflags) -headers-only -multilib-bootstrap -nscd -perl (-selinux) -sframe -suid (-systemd) -systemtap -test (-vanilla)" 0 KiB

Total: 1 package (1 reinstall), Size of downloads: 0 KiB

!!! The following installed packages are masked:
- dev-lang/rust-1.87.0-r1::gentoo (masked by: package.mask)
- dev-lang/rust-1.84.1-r2::gentoo (masked by: package.mask)
- dev-lang/rust-1.89.0::gentoo (masked by: package.mask)
For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

[leyvi]

OP's pastebin'd emerge --info starts:

Code: Select all

Portage 3.0.77 (python 3.14.2-final-0, default/linux/amd64/23.0/split-usr/desktop/plasma, gcc-15, glibc-2.42-r5, 6.17.5-gentoo-r1 x86_64)

So it's not currently a no-multilib profile. However, OP might have run no-multilib at some point, and later performed an incorrect conversion. The output of emerge --pretend --verbose sys-libs/glibc might be interesting.

When I installed, I think I was using a multilib profile. I thought I still was... guess not

How do I properly convert?

[leyvi]

Team,

I'll put two shillings 'on the nose' that we have a no-multilib profile in use on a multilib install.
This can/will break 32 bit support.

For a place, the kernel does not support 32 bit code' so the test fails.

I think you might be right...

[NeddySeagoon]

leyvi,

You can't install 32 bit code with a /no-multilib/ install. All the /no-multilib/ profiles say no-multilib in the name as in

Code: Select all

$ emerge --info
Portage 3.0.77 (python 3.13.11-final-0, default/linux/amd64/23.0/split-usr/no-multilib, gcc-15, glibc-2.42-r4, 6.18.5-gentoo x86_64)

If you have

Code: Select all

$ grep IA32 /usr/src/linux/.config
# CONFIG_IA32_EMULATION is not set

your kernel cannot support 32 bit code so configure tests will fail if they try to run any 32 bit code.

[leyvi]

leyvi,

You can't install 32 bit code with a /no-multilib/ install. All the /no-multilib/ profiles say no-multilib in the name as in

Code: Select all

$ emerge --info
Portage 3.0.77 (python 3.13.11-final-0, default/linux/amd64/23.0/split-usr/no-multilib, gcc-15, glibc-2.42-r4, 6.18.5-gentoo x86_64)

If you have

Code: Select all

$ grep IA32 /usr/src/linux/.config
# CONFIG_IA32_EMULATION is not set

your kernel cannot support 32 bit code so configure tests will fail if they try to run any 32 bit code.

On my system, it is like this:

Code: Select all

 $ zgrep IA32 /proc/config.gz
CONFIG_IA32_EMULATION=y
# CONFIG_IA32_EMULATION_DEFAULT_DISABLED is not set

Profile is default/linux/amd64/23.0/split-usr/desktop/plasma, which doesn't contain the term "muiltilib", but someone here said it is?

[NeddySeagoon]

leyvi,

amd64 profiles are multilib by default. That is, they do not have multilib in their names.

We need the log from the configure stage.

[leyvi]

leyvi,

amd64 profiles are multilib by default. That is, they do not have multilib in their names.

We need the log from the configure stage.

Sorry to ask, but could you please remind me what the path of that would be (within temp, I assume)?

[Hu]

According to the build.log that sam_ quoted from your pastebin, it would be:

Code: Select all

A full log can be found at /var/tmp/portage/sys-fs/fuse-3.18.1/work/fuse-3.18.1-abi_x86_32.x86/meson-logs/meson-log.txt

[leyvi]

According to the build.log that sam_ quoted from your pastebin, it would be:

Code: Select all

A full log can be found at /var/tmp/portage/sys-fs/fuse-3.18.1/work/fuse-3.18.1-abi_x86_32.x86/meson-logs/meson-log.txt

Sorry for being relatively dumb earlier. This isn't from the same package, but it's the same corresponding file: /var/tmp/portage/media-libs/libdisplay-info-0.3.0/work/libdisplay-info-0.3.0-abi_x86_32.x86/meson-logs/meson-log.txt.

I'm noticing that everything seems to want to build exclusively with the GNU toolchain, now that I've installed the binary package for LLVM. Is that intentional, and if so, how do I fix it? (What I mean is that suddenly, all my ebuilds are checking if GCC is present, and failing in the LLVM-only environments. They didn't used to do that.)

[sam_]

But it looks like Meson succeeded there? We need the build.log, fresh emerge --info, and a meson-log.txt that corresponds to that.

[leyvi]

OK, here it is for sys-fs/fuse:

1. build.log
2. meson-log.txt
3. emerge --info
4. environment

Though I don't know if this is the same issue. The thing is, I explicitly gave it ld.lld, but here it's trying to use ld.bfd instead. This is from app-crypt/p11-kit, it contains all 4 files, separated by comments.

[Hu]

Code: Select all

stderr:
/usr/bin/x86_64-pc-linux-gnu-ld: unrecognized option '--lto-O3'

Checking emerge --info, we see:

Code: Select all

LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,--lto-O3"

You set LDFLAGS that don't work with this linker, and the package reported a somewhat misleading error message when the linker failed. A more cautious build system would have done a "checking whether environment is sane" test where it tries to build a trivial C program with your flags, and reports an error when, due to your bad LDFLAGS, even that trivial test fails.

[leyvi]

Code: Select all

stderr:
/usr/bin/x86_64-pc-linux-gnu-ld: unrecognized option '--lto-O3'

Checking emerge --info, we see:

Code: Select all

LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-z,pack-relative-relocs -Wl,--lto-O3"

You set LDFLAGS that don't work with this linker, and the package reported a somewhat misleading error message when the linker failed. A more cautious build system would have done a "checking whether environment is sane" test where it tries to build a trivial C program with your flags, and reports an error when, due to your bad LDFLAGS, even that trivial test fails.

This works fine with ld.lld, but not with ld.bfd, and the former is explicitly set in the environment file, so there's no reason why my extra flag should cause problems.

[sam_]

Yet that is clearly what is happening and -fuse-ld=lld isn't anywhere in the environment file either in your supplied flags. Setting LD is not sufficient.