| View previous topic :: View next topic |
| Author |
Message |
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20390
|
 Posted: Mon Jun 03, 2024 5:59 am Post subject: Profile 23 binutils failure |
 |
|
This was the only thing that seemed notable: | Code: | checking for CET support... configure: error: compiler and assembler with CET support are required for --enable-cet
make[1]: *** [Makefile:8820: configure-libiberty] Error 1 |
emerge --info '=sys-devel/binutils-2.42-r1::gentoo'
https://bpa.st/NBIQ
emerge -pqv '=sys-devel/binutils-2.42-r1::gentoo'
https://bpa.st/7BOQ
build.log
https://bpa.st/U3WA
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
 |
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3630
Location: Rasi, Finland
|
| Posted: Mon Jun 03, 2024 3:24 pm Post subject: |
|
|
To me this looks like chicken & egg -problem.
Maybe gcc needs USE="cet" before starting switching profile?
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20390
|
| Posted: Mon Jun 03, 2024 4:51 pm Post subject: |
|
|
Surely that would have been caught by now?
I do have some CFLAGS from one of the CPU problems (spectre?). | Code: | | -mindirect-branch=thunk -mfunction-return=thunk |
I'm vaguely recalling something like that in a post, but I don't recall if it was for the profile upgrade. I need to see if I can find it.
EDIT:
I took those options out of CFLAGS leaving only CFLAGS="-O2 -pipe", but "ebuild ... compile" seems to produce the same error.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Zucca
Moderator
Joined: 14 Jun 2007
Posts: 3630
Location: Rasi, Finland
|
| Posted: Wed Jun 05, 2024 8:26 am Post subject: |
|
|
| Code: | $ quse cet | awk '(!seen[$1]++) {print substr($1,1,length($1)-1)}'
dev-debug/gdb
dev-lang/gnat-gpl
dev-lang/ocaml
media-tv/mythtv
sys-devel/binutils
sys-devel/binutils-hppa64
sys-devel/clang-common
sys-devel/gcc
sys-libs/binutils-libs
sys-libs/glibc |
Wild guessing, but is your glibc and binutils-libs compiled with USE="cet".
I wonder how the configuration script of binutils detects if cet was enabled for compiler and assembler... an assembler which is part of binutils itself.
But yeah, I too wonder why you seem to be the only one who stumbled upon this.
_________________
..: Zucca :..
Gentoo IRC channels reside on Libera.Chat.
--
| Quote: | | I am NaN! I am a man! |
|
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2219
|
| Posted: Wed Jun 05, 2024 8:29 am Post subject: |
|
|
| pjp wrote: |
I took those options out of CFLAGS leaving only CFLAGS="-O2 -pipe", but "ebuild ... compile" seems to produce the same error. |
Did you clean the temp directory? If not, it's keeping the old configuration
p.s. weren't you going to use a binary package for binutils?
Also there were important notes in the news item which should be done before which.
Best Regards,
Georgi |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20390
|
| Posted: Wed Jun 05, 2024 8:38 pm Post subject: |
|
|
| Zucca wrote: | Wild guessing, but is your glibc and binutils-libs compiled with USE="cet".
I wonder how the configuration script of binutils detects if cet was enabled for compiler and assembler... an assembler which is part of binutils itself.
But yeah, I too wonder why you seem to be the only one who stumbled upon this. |
| Code: | [ebuild R ] sys-libs/binutils-libs-2.42-r1:0/2.42.0::gentoo USE="nls -64-bit-bfd -cet -multitarget -static-libs -test" 0 KiB
[ebuild R ] sys-libs/glibc-2.39-r6:2.2::gentoo USE="multiarch ssp (static-libs) -audit -caps -cet -compile-locales (-custom-cflags) -doc -gd -hash-sysv-compat -headers-only (-multilib) -multilib-bootstrap -nscd -perl -profile (-selinux) (-stack-realign) -suid -systemd -systemtap -test (-vanilla)" 0 KiB |
I can't imagine it would matter, but I did upgrade to python 3.12 before trying the profile migration.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20390
|
| Posted: Wed Jun 05, 2024 8:56 pm Post subject: |
|
|
| logrusx wrote: | Did you clean the temp directory? If not, it's keeping the old configuration
p.s. weren't you going to use a binary package for binutils?
Also there were important notes in the news item which should be done before which.
Best Regards,
Georgi |
Not specifically... I thought emerge took care of that. To clarify, I used emerge for the first failure, then ebuild ... compile for the next attempt. Now that you mention it though, I see your point. I switched back to 17.1, but I'll try again tonight.
I'm only planning on using the binary packages for gcc, clang and some other big stuff. I wasn't planning on binutils, glibc, or libtool (the other 3 that get updated before "emptytree." I was planning to pre-fetch the binary packages, adjusting USE flags, then --getbinpkg should prefer the local copy of the package. I'll also try to pre-fetch all binary packages before doing emptytree. Then I'll know what if anything else gets installed that way and can rebuild it later.
Step 9 mentions this order: - binutils
- gcc (without glibc)
- glibc
libtool isn't until several steps later.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20390
|
| Posted: Thu Jun 06, 2024 4:27 am Post subject: |
|
|
| logrusx wrote: | | Did you clean the temp directory? If not, it's keeping the old configuration |
| ebuild ... compile: | | >>> Source compiled. |
Hah! Good catch. That appears to have been it. I'll give the migration another try when I have a bit more time.
I can remember an odd thread mentioning something that may or may not be relevant, but I can't remember to clean up a build failure.
Since it seems relevant, the thread:
Stuck 23.0 update, step 9, gcc rebuild fails [SOLVED]
There, binutils compiled, but not gcc.
I had CFLAGS="-O2 -pipe -mindirect-branch=thunk -mfunction-return=thunk" and not -fcf-protection.
For the heck of it, I'm going to put those back and see if the config.log has any relevant information, since that's where -mindirect-branch was called out as incompatible.
If I had found the thread sooner, that may also have helped. Oh well.
Thanks again for catching that!
EDIT: The config.log, although I didn't see any similar 'not compatible' messaging.
https://bpa.st/JTCA
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
logrusx
Advocate
Joined: 22 Feb 2018
Posts: 2219
|
| Posted: Thu Jun 06, 2024 3:30 pm Post subject: |
|
|
I didn't follow your though, it's a bit beyond me to figure out what you meant without additional clarifications.
For the record, when you resume an ebuild, if you've changed the environment, it's not going to take effect. The environment is already created and stored into a file or even propagated into other files. You must be very familiar with what portage does as well as what the particular build system does to know what files to edit to reflect that environment change. Even then sometimes the changes may be at so many places that it'll take too much time. Cleaning the temp directory will make portage recreate the environment and reflect your changes. Resuming an ebuild is only an option when you've fixed something that does not depend on the environment.
Best Regards,
Georgi |
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20390
|
| Posted: Thu Jun 06, 2024 4:19 pm Post subject: |
|
|
Yeah, I just didn't think to do it.
I'm not sure which part was confusing, so I'll recap.
I originally tried to install using the instruction in the news item: emerge --ask --oneshot sys-devel/binutils.
That failed. I then remembered the thread I posted regarding some CFLAGS settings that caused their problem for gcc. I had one of them set and another, so I removed those options.
What I should have done was cleaned the previous failure. But instead, I ran: ebuild /var/db/repos/gentoo/sys-devel/binutils/binutils-<version> compile.
That of course did as you described, but I didn't think of having to clean it first.
So when I retested and the compile completed, it worked because there was no failure in place.
I may try the profile change again next week. I'll update here when I'm done.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
|
Portage & Programming
