Created attachment 653280 [details] Build log made with a normal emerge of this individual package This package reports: "/bin/sh: i486-pc-linux-gnu-gcc: command not found" The computer has a K6-III processor, which is i586, and the Gentoo install was started from a normal i486 stage3, since there are no i586 stage3 archives provided. CHOST was then changed to i586 in order to reflect the processor. I went through the steps on how to change the CHOST, emerged binutils, gcc and glibc. Both gcc-config and binutils-config report i586-pc-linux-gnu-*version* as the only option and also the active option. Binutils says 2.33.1 and gcc says 9.3.0. Attaching make.conf, the outputs of emerge -pqv and emerge --info, and build.log made with a normal emerge of this individual package.
Created attachment 653282 [details] make.conf file of the system
Created attachment 653284 [details] the output of emerge --info
Created attachment 653286 [details] the output of emerge -pqv
I'm going to naively suggest re-emerging libtool as well because it seems highly unlikely this is specific to this library. It's possibly relevant that autotools calls the *right* toolchain, but later on, ninja doesn't: Traceback (most recent call last): File "/usr/lib/python3.7/distutils/unixccompiler.py", line 110, in preprocess self.spawn(pp_args) File "/usr/lib/python3.7/distutils/ccompiler.py", line 910, in spawn spawn(cmd, dry_run=self.dry_run) File "/usr/lib/python3.7/distutils/spawn.py", line 36, in spawn _spawn_posix(cmd, search_path, dry_run=dry_run) File "/usr/lib/python3.7/distutils/spawn.py", line 159, in _spawn_posix % (cmd, exit_status)) distutils.errors.DistutilsExecError: command 'i486-pc-linux-gnu-gcc' failed with exit status 1 During handling of the above exception, another exception occurred: Traceback (most recent call last): File "tools/g-ir-scanner", line 100, in <module> sys.exit(scanner_main(sys.argv)) File "/var/tmp/portage/dev-libs/gobject-introspection-1.62.0-r1/work/gobject-introspection-1.62.0-build/giscanner/scannermain.py", line 570, in scanner_main ss, filenames = create_source_scanner(options, args) File "/var/tmp/portage/dev-libs/gobject-introspection-1.62.0-r1/work/gobject-introspection-1.62.0-build/giscanner/scannermain.py", line 443, in create_source_scanner ss.parse_files(filenames) File "/var/tmp/portage/dev-libs/gobject-introspection-1.62.0-r1/work/gobject-introspection-1.62.0-build/giscanner/sourcescanner.py", line 259, in parse_files self._parse(headers) File "/var/tmp/portage/dev-libs/gobject-introspection-1.62.0-r1/work/gobject-introspection-1.62.0-build/giscanner/sourcescanner.py", line 307, in _parse self._cpp_options) File "/var/tmp/portage/dev-libs/gobject-introspection-1.62.0-r1/work/gobject-introspection-1.62.0-build/giscanner/ccompiler.py", line 276, in preprocess extra_postargs=extra_postargs) File "/usr/lib/python3.7/distutils/unixccompiler.py", line 112, in preprocess raise CompileError(msg) I wonder if the CHOST got somehow embedded in some Python lib. Seems odd though.
Same story happens with dev-perl/Net-DBus and a maintainer told me to try executing perl -V:cc which promptly reported i486-pc-linux-gnu-gcc Now re-emerging perl (emerge --oneshot perl) and then will try again. If it fails, then will re-emerge libtool.
(In reply to subzero_ro from comment #5) > Same story happens with dev-perl/Net-DBus and a maintainer told me to try > executing > > perl -V:cc > > which promptly reported > > i486-pc-linux-gnu-gcc > > Now re-emerging perl (emerge --oneshot perl) and then will try again. If it > fails, then will re-emerge libtool. Perl is one of those which embeds CC at time of compile. I imagine some core "things" will nee rebuilding, Perl included (use perl-cleaner because the rest of Perl will need rebuilding afterwards too; this has been the source of a lot of bugs and kent\n is trying to improve it).
(In reply to Sam James from comment #6) > Perl is one of those which embeds CC at time of compile. I imagine some core > "things" will nee rebuilding, Perl included (use perl-cleaner because the > rest of Perl will need rebuilding afterwards too; this has been the source > of a lot of bugs and kent\n is trying to improve it). Well, re-emerged perl, used perl-cleaner which emerged 10 packages and then 50 packages, re-emerged libtool and even ninja itself. Tried to re-emerge python, but the first thing it does is attempt to re-emerge this very package. The CHOST changing wiki page says I should, at some point, emerge --emptytree @world and they also say sometimes one may get away without doing that. I'm hoping I can avoid doing that and just nail down the offending package, or packages, because this scenario should be pretty standard - installing Gentoo on an i586 processor from an i486 stage3.
Ok, I restarted the installation from scratch. Remember, my point is to have an i586 install, starting from an i486 stage3. Following the installation tutorial, you get to a point where you emerge @world - I did that with the default i486 CHOST value, march=i486, but with CPU_FLAGS_X86 declared in make.conf as reported by the utility app-portage/cpuid2cpuflags. Emerging @world failed at some point, I think that happened because of bug #707390 which is probably unrelated to this one. At that point I changed the CHOST value to i586, ran emerge --oneshot sys-devel/binutils, then sys-devel/gcc, then sys-libs/glibc, then ran emerge --emptytree @system (During one of these two emerge commands, some package failed because it couldn't find two dependencies: dev-libs/libgpg-error and dev-libs/libgcrypt. Emerging the two separately fixed the problem.) Trying to emerge @system failed at dev-libs/gobject-introspection again. I remembered how I noticed dev-libs/vala-common being emerged previously, so I looked it up and noticed dev-lang/vala, which is described as "compiler for the GObject type system" - I thought it may be connected. So I installed that one, too. Still, dev-libs/gobject-introspection wouldn't compile. So I installed app-portage/gentoolkit, to get the equery tool. And then I ran equery y python. I had three python versions installed! 2.7.18-r1, 3.7.8-r2 and 3.8.4-r1. I ran emerge --oneshot python and 3.8.4-r1 was emerged successfully. Then I did emerge --oneshot python-3.7.8-r2 and this one also emerged successfully. Then I tried to emerge --oneshot gobject-introspection and it finally worked. I hope I remembered this right, it happened over several days of compiling on a 450 MHz processor. It is now emerging with --emptytree @world.
And then after all this adventure, you --emptytree anyhow :)
Well, the difference is that it seems to work if you do all this while still inside the usual installation chroot, from a boot CD. Last time the computer was already made bootable as I had compiled a kernel, installed Grub, etc.
