Re: [gentoo-user] what test gets done in pcre makefile to find gcc won't work?
On Mon, Oct 05, 2020 at 01:51:45PM -0400, Jude DaShiell wrote: > emerge --ask --verbose --update --deep --newuse @world > Would it have been best to refuse to do the emerges at that point in the > installation? The handbook was silent on that point except to say > updates could be done after installation. I would usually wait to get a working, bootable system before worrying about updating everything to the newest version possible, however I'm still surprised that the configure script took issue with GCC this early in the installation process. > The gcc compiler works this time though the pcre package continues to > break. I'll get the output for it and share with the list as soon as I > have it together. OK, thank you. Please remember to post the entire log of emerge, and the output of `emerge --info `. Gzip the former if it is very large. BTW: please stop top-posting (that is, quoting the entire thread and then prepending your response). It is not only a tremendous waste of disk space, but also makes it unclear as to which part of the quoted message you're replying. Interleaved style seems to be the most commonly used here. [1] [1] https://en.wikipedia.org/wiki/Posting_style#Interleaved_style -- Ashley Dixon suugaku.co.uk 2A9A 4117 DA96 D18A 8A7B B0D2 A30E BF25 F290 A8AA signature.asc Description: PGP signature
Re: [gentoo-user] what test gets done in pcre makefile to find gcc won't work?
Oops, correction the emerge offers where pcre broke happened after:
emerge --ask --verbose --update --deep --newuse @world
Would it have been best to refuse to do the emerges at that point in the
installation? The handbook was silent on that point except to say
updates could be done after installation.
The gcc compiler works this time though the pcre package continues to
break. I'll get the output for it and share with the list as soon as I
have it together.
On Sun, 4 Oct 2020, Ashley Dixon wrote:
> Date: Sun, 4 Oct 2020 02:59:18
> From: Ashley Dixon
> 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
>
>
--
Re: [gentoo-user] what test gets done in pcre makefile to find gcc won't work?
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
> 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
> > 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
> > hand
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
> 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
>
>
--
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
--
Ashley Dixon
suugaku.co.uk
2A9A 4117
DA96 D18A
8A7B B0D2
A30E BF25
F290 A8AA
signature.asc
Description: PGP signature
