I suspect the earlier failure may have been due to a package integrity
issue. One of the problems is links doesn't let me know when a download
is finished the way I have it configured now. Also, using speakup I had
to turn on links are numbered in html options then save html options to
even download the stage3 file. The accessibility use flag wasn't in
effect and I could move with down arrow onto the stage3 file according
to speakup but the links cursor didn't follow and would only allow me to
download some image file.
On Mon, 5 Oct 2020, Jude DaShiell wrote:
> Date: Mon, 5 Oct 2020 13:24:22
> From: Jude DaShiell <jdash...@panix.com>
> Reply-To: gentoo-user@lists.gentoo.org
> To: gentoo-user@lists.gentoo.org
> Subject: Re: [gentoo-user] what test gets done in pcre makefile to find gcc
> won't work?
>
> Ashley,
>
> Thanks much for help you provided. You should know, as a result of that
> help you got me all the way to kernel configuration.
>
> On Sun, 4 Oct 2020, Ashley Dixon wrote:
>
> > Date: Sun, 4 Oct 2020 02:59:18
> > From: Ashley Dixon <a...@suugaku.co.uk>
> > Reply-To: gentoo-user@lists.gentoo.org
> > To: gentoo-user@lists.gentoo.org
> > Subject: Re: [gentoo-user] what test gets done in pcre makefile to find gcc
> > won't work?
> >
> > On Sun, Oct 04, 2020 at 12:47:39AM -0400, Jude DaShiell wrote:
> > > I ran emerge-webrsync and agreed to merge some software titles from
> > > gentoo. The first one was pcre and so far as I can tell, all went fine
> > > until the makefile tested gcc and found gcc doesn't work. At that point
> > > the emerge errored out.
> >
> > I think you mean the configure script, not the Makefile? It is executed in
> > the
> > ebuild with the `econf` wrapper function [1, 2]; its output looks like
> > this:
> >
> > checking for a BSD-compatible install... /usr/bin/install -c
> > checking whether build environment is sane... yes
> > checking for a thread-safe mkdir -p... /bin/mkdir -p
> > [...]
> >
> > Can you post the full output of emerge? "The gcc test" is equivocal; the
> > GNU
> > configure script does lots of compiler tests, and it will be useful to
> > know
> > which one fails.
> >
> > > Now, it's possible everyone is using the systemd profile but I went with
> > > the default profile already used for amd64 installs so it could be that
> > > profile ran me into this particular error.
> >
> > I could be very mistaken, but I think that the majority of the Gentoo
> > community
> > uses an OpenRC profile, probably because it's the default. Gentoo supports
> > quite
> > a few init systems, if you'd like to have a play and see which one you like
> > the
> > most [3].
> >
> > > Something else that was strange, I had the gentoo-minimal cd in use and
> > > had downloaded a stage3 file and a snapshot. The package
> > > sys-libs/timezone-data did not download in those packages and the handbook
> > > provided no instructions on downloading and installing that package before
> > > trying to set the local time. Could it be failure to use systemd profile
> > > also brought me this error as well?
> >
> > Which profile have you chosen? The Stage 3 tarball consists of a system
> > set for
> > a particular profile [4], all of which inherit the base @system [5].
> > The
> > `timezone-data` package is not included in any of the default profile
> > system
> > sets, so it should not be expected to appear in a Stage 3:
> >
> > $ shopt -s globstar
> > $ grep timezone-data gentoo/profiles/**/packages
> > # or
> > $ find gentoo/profiles/ -type f -name "packages" -exec grep \
> > > timezone-data {} \;
> >
> > It should be pulled in a dependency of glibc, providing the `vanilla` flag
> > isn't
> > set, but you can just emerge it manually.
> >
> > $ equery d timezone-data # add `-a` after `d` for a full list
> > * These packages depend on timezone-data:
> > dev-libs/libical-3.0.8 (sys-libs/timezone-data)
> > sys-libs/glibc-2.31-r6 (!vanilla ? sys-libs/timezone-data)
> >
> > Anyway, this is independent of the init system you choose. Have you had a
> > look
> > at [6]? Find the relevant file in `/usr/share/zoneinfo` which
> > corresponds to
> > your timezone, write its relative path to the `/etc/timezone` file,
> > and
> > reconfigure the `timezone-data` package. To steal the example in the
> > handbook:
> >
> > $ ls -l /usr/share/zoneinfo
> > $ echo "Europe/Brussels" > /etc/timezone # Suppose you're in
> > Brussels
> > $ emerge --config sys-libs/timezone-data # Regenerate
> > `/etc/localtime`
> >
> > [1]
> > https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/libpcre2/libpcre2-10.35.ebuild#n74
> > [2] https://devmanual.gentoo.org/function-reference/build-functions/
> > [3] https://wiki.gentoo.org/wiki/Comparison_of_init_systems
> > [4] https://wiki.gentoo.org/wiki/Stage_tarball#Stage_3
> > [5] https://gitweb.gentoo.org/repo/gentoo.git/tree/profiles/base/packages
> > [6] https://wiki.gentoo.org/wiki/Handbook:AMD64/Full/Installation#Timezone
> >
> > P.S. You can examine the contents of `/etc/localtime`, and thus the
> > supported
> > timezones, with the `zdump` utility from the `timezone-data` package:
> >
> > $ zdump /etc/locatime
> > /etc/localtime Sun Oct 4 07:41:45 2020 BST
> >
> >
>
>
--
