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
--
Ashley Dixon
suugaku.co.uk
2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA
signature.asc
Description: PGP signature
