On Tue, 6 Oct 2020, Ashley Dixon wrote: > Date: Mon, 5 Oct 2020 19:55:50 > From: Ashley Dixon <a...@suugaku.co.uk> > Reply-To: gentoo-user@lists.gentoo.org > To: gentoo-user@lists.gentoo.org > Subject: Re: [gentoo-user] pcre build failure > > This is confusing me to no end, partly because you seem to have included > the > same text twice? The information posted seems to contradict itself, > particularly > with the USE-flags. For example, here you have the `static-libs` flag > disabled: > > On Mon, Oct 05, 2020 at 02:40:47PM -0400, Jude DaShiell wrote: > > [ebuild R ] dev-libs/libpcre-8.44:3::gentoo USE="bzip2 cxx jit > > readline recursion-limit (split-usr) (unicode) zlib -libedit -pcre16 > > -pcre32 -static-libs*" ABI_X86="(64) -32 (-x32)" 0 KiB > > ... which is supported by the output of the configure script: > > > checking whether to build static libraries... no > [...] > > Build static libs ............... : no > > ... but then in the output of `emerge --info`, which displays the flags of the > currently installed version, the `static-libs` flag is enabled: > > > dev-libs/libpcre-8.44::gentoo was built with the following: > > USE="bzip2 cxx jit readline recursion-limit (split-usr) static-libs > > (unicode) zlib -libedit -pcre16 -pcre32" ABI_X86="(64) -32 (-x32)" > > As the asterisk in the first emerge output would suggest, the flag is only > now > being disabled for the package. Such a change is very dangerous, and > although I > can't imagine why PCRE was built to use static libraries in the first place, > I > can assume this might be the cause of the error. I am still unable to > reproduce > this behaviour on my own system. > > PCRE depends on the following packages, so you will want to make sure that > all > of these agree on the nature of the libraries: static or dynamic? > > $ equery g libpcre > * Searching for libpcre ... > * dependency graph for dev-libs/libpcre-8.44 > `-- dev-libs/libpcre-8.44 amd64 > `-- app-arch/bzip2-1.0.6-r11 (app-arch/bzip2) amd64 > `-- sys-libs/zlib-1.2.11-r2 (sys-libs/zlib) amd64 > `-- dev-libs/libedit-20191211.3.1 (dev-libs/libedit) amd64 > `-- sys-libs/readline-8.0_p4 (sys-libs/readline) amd64 > `-- virtual/pkgconfig-2 (virtual/pkgconfig) amd64 > `-- app-portage/elt-patches-20170815 > (>=app-portage/elt-patches-20170815) amd64 > [ dev-libs/libpcre-8.44 stats: packages (7), max depth (1) ] > > > Irrelevant aside: you see these annoying ANSI colour codes captured by > `script`? > You can strip them out with the `ansifilter` program, provided by the > `app-text/ > ansifilter` package in gentoo.git. It takes standard input or a file name, > and > without any arguments, will erase all ANSI escape sequences. > > > [01;31mlivecd[01;34m / #[00m exit > > $ ansifilter <<< "[01;31mlivecd[01;34m / #[00m exit" # bash syntax > livecd / # exit > > In future, if you just want to capture the output of a (possibly > interactive) > command, `tee` is better than `script`. It usually strips escape sequences > and > such. However, it does not capture standard error to the output file, so > you'll > want to redirect it into standard output, like so: > > $ ./prog 2>&1 | tee prog-log > >
-- When the failure happened on the computer I neglected to braille the commands that would have only produced a single copy of the text. In order to get the content from the second file, I needed to run the emerge update world command again then locate the command for the second file then cat that command. Braille paper is available here so I won't make that mistake again.
