| Summary: | sys-libs/glibc-2.34-r8 fails to compile (stddef.h: No such file or directory) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Courier6 <maxbottman1> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | sam |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| See Also: |
https://sourceware.org/bugzilla/show_bug.cgi?id=28183 https://bugs.gentoo.org/show_bug.cgi?id=643302 |
||
| Whiteboard: | Need to add check in ebuild | ||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 803482 | ||
| Attachments: |
build.log
emerge log since the 18th of january |
||
|
Description
Courier6
2022-02-18 19:34:00 UTC
Snippet:
x86_64-pc-linux-gnu-nptl/cpu-features-offsets.h'" \
../sysdeps/x86/cpu-features-offsets.sym > /var/tmp/portage/sys-libs/glibc-2.34-r8/work/build-x86-x86_64-pc-linux-gnu-nptl/cpu-features-offsets.hT
/bin/sh ../scripts/move-if-change /var/tmp/portage/sys-libs/glibc-2.34-r8/work/build-x86-x86_64-pc-linux-gnu-nptl/gnu/lib-names-32.T /var/tmp/portage/sys-libs/glibc-2.34-r8/work/build-x86-x86_64-pc-linux-gnu-nptl/gnu/lib-names-32.h
touch /var/tmp/portage/sys-libs/glibc-2.34-r8/work/build-x86-x86_64-pc-linux-gnu-nptl/gnu/lib-names-32.stmp
if test -r /var/tmp/portage/sys-libs/glibc-2.34-r8/work/build-x86-x86_64-pc-linux-gnu-nptl/csu/abi-tag.h.new; then mv -f /var/tmp/portage/sys-libs/glibc-2.34-r8/work/build-x86-x86_64-pc-linux-gnu-nptl/csu/abi-tag.h.new /var/tmp/portage/sys-libs/glibc-2.34-r8/work/build-x86-x86_64-pc-linux-gnu-nptl/csu/abi-tag.h; \
else echo >&2 'This configuration not matched in ../abi-tags'; exit 1; fi
[01m[K<stdin>:1:10:[m[K [01;31m[Kfatal error: [m[Kstddef.h: No such file or directory
compilation terminated.
Traceback (most recent call last):
File "/var/tmp/portage/sys-libs/glibc-2.34-r8/work/glibc-2.34/csu/../scripts/gen-as-const.py", line 120, in <module>
main()
File "/var/tmp/portage/sys-libs/glibc-2.34-r8/work/glibc-2.34/csu/../scripts/gen-as-const.py", line 116, in main
consts = glibcextract.compute_c_consts(sym_data, args.cc)
File "/var/tmp/portage/sys-libs/glibc-2.34-r8/work/glibc-2.34/scripts/glibcextract.py", line 62, in compute_c_consts
subprocess.check_call(cmd, shell=True)
File "/usr/lib/python3.9/subprocess.py", line 373, in check_call
raise CalledProcessError(retcode, cmd)
Thanks for reporting this. It looks like it's an issue in the GCC 11 snapshot (something got backported to the stable branch upstream) but it might/is actually a glibc bug. Please hold while we look into it. (In reply to Sam James from comment #2) > Thanks for reporting this. It looks like it's an issue in the GCC 11 > snapshot (something got backported to the stable branch upstream) but it > might/is actually a glibc bug. > > Please hold while we look into it. You are very welcome, I can't thank you enough for looking into this! Could you tar up /var/tmp/portage/sys-libs/glibc-2.34-r8/work and upload it compressed here? (In reply to Sam James from comment #4) > Could you tar up /var/tmp/portage/sys-libs/glibc-2.34-r8/work and upload it > compressed here? I wonder if you have a /usr/lib/include or /usr/lib64/include. If not, we'll need to do some digging like in bug 643302. Did anything change on your system recently? Obvious example would be 17.0->17.1 profile migration. The interesting part is you managed to install glibc-2.34-r7. Could you share 'qlop' output or /var/log/emerge.log, to see what you installed _after_ glibc-2.34-r7 up until now? I'm really interested in what's changed. Created attachment 765691 [details] emerge log since the 18th of january (In reply to Sam James from comment #4) > Could you tar up /var/tmp/portage/sys-libs/glibc-2.34-r8/work and upload it > compressed here? sure thing! I just got home from work, also here is the emerge.log file of everything I did since installing sys-libs/glibc-2.34-r7. I checked to see if I have /usr/lib/include and /usr/lib64/include and both directories were not present so that is quite odd. link to working directory of sys-libs/glibc-2.34-r8 https://www.sharebylink.fr/?C5cXyekkdsjM do not use the sharebylink url, use this instead link that works: https://drive.google.com/file/d/1JHKuzA4kfjg7z3JsDnVYmRZYSnCjquuv/view?usp=sharing (In reply to Sam James from comment #5) Nothing really major changed on my system software or hardware wise, and I am perplexed on out I got 2.34-r7 installed, as it just came in when I did an "emerge -j5 --ask --update --deep --with-bdeps=y --newuse @world" command as a routine update. Also I had misread the /usr/lib directory to find that it has an "include" directory, while the /usr/lib64 directory does not contain the "include" directory. I'm very sorry to waste your time. (In reply to Courier6 from comment #8) > (In reply to Sam James from comment #5) > Nothing really major changed on my system software or hardware wise, and I > am perplexed on out I got 2.34-r7 installed, as it just came in when I did > an "emerge -j5 --ask --update --deep --with-bdeps=y --newuse @world" command > as a routine update. Also I had misread the /usr/lib directory to find that > it has an "include" directory, while the /usr/lib64 directory does not > contain the "include" directory. I'm very sorry to waste your time. Could you do: ls /usr/lib/include? Then mv /usr/lib/include /usr/lib/include.bak/ and try emerge -v1 glibc again? Also, could you try attach all these files, rather than use external services? Sometimes we can't reach them due to firewalls and we also want to keep them here for posterity. Thanks in advance! (In reply to Sam James from comment #9) I tried using the "mv /usr/lib/include /usr/lib/include.bak" command, and then I tried updating glibc, and what do you know, it worked! I now have the latest version of glibc! also I tried attaching the working directory of 2.34-r8 but I couldn't compress it to be below 1000kb as the original directory was 224mb, but I totally understand keeping the files here for posterity sake and firewalls being a thing. thank you so much for your help (In reply to Courier6 from comment #10) > (In reply to Sam James from comment #9) > > I tried using the "mv /usr/lib/include /usr/lib/include.bak" command, and > then I tried updating glibc, and what do you know, it worked! I now have the > latest version of glibc! also I tried attaching the working directory of > 2.34-r8 but I couldn't compress it to be below 1000kb as the original > directory was 224mb, but I totally understand keeping the files here for > posterity sake and firewalls being a thing. thank you so much for your help No problem. I think we'll add some check in pkg_pretend or similar and warn at least. Cheers! The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b522ecb1078aad753b3970d91699053974440e2f commit b522ecb1078aad753b3970d91699053974440e2f Author: Sam James <sam@gentoo.org> AuthorDate: 2022-03-20 21:13:16 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-03-20 21:13:16 +0000 sys-libs/glibc: add safety check for /usr/lib/include This directory isn't used by anything legitimate but it breaks the build in a confusing way. Add a check for it & bail out if it exists. If you do have this directory on your system, back up its contents, then move it away/delete it. Closes: https://bugs.gentoo.org/643302 Closes: https://bugs.gentoo.org/833620 Signed-off-by: Sam James <sam@gentoo.org> sys-libs/glibc/glibc-2.34-r10.ebuild | 8 ++++++++ sys-libs/glibc/glibc-2.35.ebuild | 8 ++++++++ sys-libs/glibc/glibc-9999.ebuild | 8 ++++++++ 3 files changed, 24 insertions(+) |
