| 1 |
This is confusing me to no end, partly because you seem to have included the |
| 2 |
same text twice? The information posted seems to contradict itself, particularly |
| 3 |
with the USE-flags. For example, here you have the `static-libs` flag disabled: |
| 4 |
|
| 5 |
On Mon, Oct 05, 2020 at 02:40:47PM -0400, Jude DaShiell wrote: |
| 6 |
> [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 |
| 7 |
|
| 8 |
... which is supported by the output of the configure script: |
| 9 |
|
| 10 |
> checking whether to build static libraries... no |
| 11 |
[...] |
| 12 |
> Build static libs ............... : no |
| 13 |
|
| 14 |
... but then in the output of `emerge --info`, which displays the flags of the |
| 15 |
currently installed version, the `static-libs` flag is enabled: |
| 16 |
|
| 17 |
> dev-libs/libpcre-8.44::gentoo was built with the following: |
| 18 |
> USE="bzip2 cxx jit readline recursion-limit (split-usr) static-libs (unicode) zlib -libedit -pcre16 -pcre32" ABI_X86="(64) -32 (-x32)" |
| 19 |
|
| 20 |
As the asterisk in the first emerge output would suggest, the flag is only now |
| 21 |
being disabled for the package. Such a change is very dangerous, and although I |
| 22 |
can't imagine why PCRE was built to use static libraries in the first place, I |
| 23 |
can assume this might be the cause of the error. I am still unable to reproduce |
| 24 |
this behaviour on my own system. |
| 25 |
|
| 26 |
PCRE depends on the following packages, so you will want to make sure that all |
| 27 |
of these agree on the nature of the libraries: static or dynamic? |
| 28 |
|
| 29 |
$ equery g libpcre |
| 30 |
* Searching for libpcre ... |
| 31 |
* dependency graph for dev-libs/libpcre-8.44 |
| 32 |
`-- dev-libs/libpcre-8.44 amd64 |
| 33 |
`-- app-arch/bzip2-1.0.6-r11 (app-arch/bzip2) amd64 |
| 34 |
`-- sys-libs/zlib-1.2.11-r2 (sys-libs/zlib) amd64 |
| 35 |
`-- dev-libs/libedit-20191211.3.1 (dev-libs/libedit) amd64 |
| 36 |
`-- sys-libs/readline-8.0_p4 (sys-libs/readline) amd64 |
| 37 |
`-- virtual/pkgconfig-2 (virtual/pkgconfig) amd64 |
| 38 |
`-- app-portage/elt-patches-20170815 (>=app-portage/elt-patches-20170815) amd64 |
| 39 |
[ dev-libs/libpcre-8.44 stats: packages (7), max depth (1) ] |
| 40 |
|
| 41 |
|
| 42 |
Irrelevant aside: you see these annoying ANSI colour codes captured by `script`? |
| 43 |
You can strip them out with the `ansifilter` program, provided by the `app-text/ |
| 44 |
ansifilter` package in gentoo.git. It takes standard input or a file name, and |
| 45 |
without any arguments, will erase all ANSI escape sequences. |
| 46 |
|
| 47 |
> [01;31mlivecd[01;34m / #[00m exit |
| 48 |
|
| 49 |
$ ansifilter <<< "[01;31mlivecd[01;34m / #[00m exit" # bash syntax |
| 50 |
livecd / # exit |
| 51 |
|
| 52 |
In future, if you just want to capture the output of a (possibly interactive) |
| 53 |
command, `tee` is better than `script`. It usually strips escape sequences and |
| 54 |
such. However, it does not capture standard error to the output file, so you'll |
| 55 |
want to redirect it into standard output, like so: |
| 56 |
|
| 57 |
$ ./prog 2>&1 | tee prog-log |
| 58 |
|
| 59 |
-- |
| 60 |
|
| 61 |
Ashley Dixon |
| 62 |
suugaku.co.uk |
| 63 |
|
| 64 |
2A9A 4117 |
| 65 |
DA96 D18A |
| 66 |
8A7B B0D2 |
| 67 |
A30E BF25 |
| 68 |
F290 A8AA |
Archives