| Summary: | crossdev avr build fails because of nonexistent gcc folder (mv: cannot stat '/var/tmp/portage/cross-avr/gcc-12.2.1_p20230428-r1/image/usr/lib64/libcc1*': No such file or directory) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | mrhel <clink.6> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | ezzieyguywuf, jcalligeros99, jlee, nvinson234 |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=930712 https://bugs.gentoo.org/show_bug.cgi?id=547754 https://bugs.gentoo.org/show_bug.cgi?id=794181 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | small enough logs | ||
|
Description
mrhel
2023-06-13 15:42:36 UTC
There's no attachments/logs here.. Apologies, the file turned out to be too big, but the website didn't alert me to this for some reason while submitting.
Here is the relevant part of the log:
/usr/lib/portage/python3.11/ebuild-helpers/xattr/install -c -m 644 /var/tmp/portage/cross-avr/gcc-12.2.1_p20230428-r1/work/gcc-12-20230428/libgcc/gcov.h /var/tmp/portage/cross-avr/gcc-12.2.1_p20230428-r1/image/usr/lib/gcc/avr/12/include
make[4]: Leaving directory '/var/tmp/portage/cross-avr/gcc-12.2.1_p20230428-r1/work/build/avr/avrtiny/long-double32/libgcc'
make[3]: Leaving directory '/var/tmp/portage/cross-avr/gcc-12.2.1_p20230428-r1/work/build/avr/libgcc'
make[2]: Leaving directory '/var/tmp/portage/cross-avr/gcc-12.2.1_p20230428-r1/work/build/avr/libgcc'
make[1]: Leaving directory '/var/tmp/portage/cross-avr/gcc-12.2.1_p20230428-r1/work/build'
mv: cannot stat '/var/tmp/portage/cross-avr/gcc-12.2.1_p20230428-r1/image/usr/lib64/libcc1*': No such file or directory
* ERROR: cross-avr/gcc-12.2.1_p20230428-r1::crossdev failed (install phase):
* (no error message)
*
* Call stack:
* ebuild.sh, line 136: Called src_install
* environment, line 2677: Called toolchain_src_install
* environment, line 4112: Called gcc_movelibs
* environment, line 1425: Called die
* The specific snippet of code:
* mv "${ED}"/usr/$(get_libdir)/libcc1* "${D}${HOSTLIBPATH}" || die;
*
* If you need support, post the output of `emerge --info '=cross-avr/gcc-12.2.1_p20230428-r1::crossdev'`,
* the complete build log and the output of `emerge -pqv '=cross-avr/gcc-12.2.1_p20230428-r1::crossdev'`.
*
* Please include /var/tmp/portage/cross-avr/gcc-12.2.1_p20230428-r1/work/gcc-build-logs.tar.xz in your bug report.
*
* The complete build log is located at '/var/tmp/portage/cross-avr/gcc-12.2.1_p20230428-r1/temp/build.log'.
* The ebuild environment file is located at '/var/tmp/portage/cross-avr/gcc-12.2.1_p20230428-r1/temp/environment'.
* Working directory: '/var/tmp/portage/cross-avr/gcc-12.2.1_p20230428-r1/work/build'
* S: '/var/tmp/portage/cross-avr/gcc-12.2.1_p20230428-r1/work/gcc-12-20230428'
>>> Failed to emerge cross-avr/gcc-12.2.1_p20230428-r1, Log file:
>>> '/var/tmp/portage/cross-avr/gcc-12.2.1_p20230428-r1/temp/build.log'
* Messages for package cross-avr/gcc-12.2.1_p20230428-r1:
* ERROR: cross-avr/gcc-12.2.1_p20230428-r1::crossdev failed (install phase):
* (no error message)
*
* Call stack:
* ebuild.sh, line 136: Called src_install
* environment, line 2677: Called toolchain_src_install
* environment, line 4112: Called gcc_movelibs
* environment, line 1425: Called die
* The specific snippet of code:
* mv "${ED}"/usr/$(get_libdir)/libcc1* "${D}${HOSTLIBPATH}" || die;
*
* If you need support, post the output of `emerge --info '=cross-avr/gcc-12.2.1_p20230428-r1::crossdev'`,
804476,0-1 99%
Thanks. Could you include the full build.log compressed as well? username234 hit something like this recently with mingw... (In reply to Sam James from comment #3) > Thanks. Could you include the full build.log compressed as well? > > username234 hit something like this recently with mingw... It's too big, even when compressed, 154MB. Can I upload a subset of it? (In reply to mrhel from comment #4) > (In reply to Sam James from comment #3) > > Thanks. Could you include the full build.log compressed as well? > > > > username234 hit something like this recently with mingw... > > It's too big, even when compressed, 154MB. Can I upload a subset of it? That's surprising, I've never heard that before for gcc. Could you maybe try ansifiltering first, then xz -9? Created attachment 863794 [details]
small enough logs
To be clear, the reason I say a folder is missing is because there isn’t even a lib64 folder, just a lib folder I've confirmed this in 908455 *** Bug 919860 has been marked as a duplicate of this bug. *** This is also affecting my bare-metal riscv64 build.
make[1]: Leaving directory '/var/tmp/portage/cross-riscv64-unknown-elf/gcc-13.2.1_p20240210/work/build'
/usr/bin/mv: cannot stat '/var/tmp/portage/cross-riscv64-unknown-elf/gcc-13.2.1_p20240210/image/usr/lib64/libcc1*': No such file or directory
* ERROR: cross-riscv64-unknown-elf/gcc-13.2.1_p20240210::nest failed (install phase):
* (no error message)
*
* Call stack:
* ebuild.sh, line 136: Called src_install
* environment, line 2437: Called toolchain_src_install
* environment, line 3862: Called gcc_movelibs
* environment, line 1383: Called die
* The specific snippet of code:
* mv "${ED}"/usr/$(get_libdir)/libcc1* "${D}${HOSTLIBPATH}" || die;
# ls /var/tmp/portage/cross-riscv64-unknown-elf/gcc-13.2.1_p20240210/image/usr/lib
gcc libcc1.la libcc1.so libcc1.so.0 libcc1.so.0.0.0
I can't tell who's doing the wrong thing here, but I trust the gcc build a lot more than the toolchain eclass, so I updated the eclass in my overlay thusly:
- mv "${ED}"/usr/$(get_libdir)/libcc1* "${D}${HOSTLIBPATH}" || die
+ mv "${ED}"/usr/lib*/libcc1* "${D}${HOSTLIBPATH}" || die
A little inelegant as a workaround because now I have to maintain the eclass in my overlay, but it does work.
Passing EXTRA_ECONF to set libdir feels like a better workaround. crossdev --env 'EXTRA_ECONF="--libdir=/usr/lib64"' --stable --target riscv64-unknown-elf Discussing this with chadmed, I feel like it's now obvious why this appears "suddenly".
It must have been when I added various missing error handling ('|| die') into the eclass, and it was just doing nothing before but nobody noticed.
|
