Re: [gentoo-user] pcre build failure

[Jude DaShiell]

On Tue, 6 Oct 2020, Ashley Dixon wrote:

> Date: Mon, 5 Oct 2020 19:55:50
> From: Ashley Dixon <ash@××××××××××.uk>
> Reply-To: gentoo-user@l.g.o
> To: gentoo-user@l.g.o
> 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.
>
> > livecd / # exit
>
>         $ ansifilter <<< "livecd / # 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.