1 |
On Tue, Aug 15, 2017 at 7:14 PM, John Blinka <john.blinka@×××××.com> wrote: |
2 |
> On Tue, Aug 15, 2017 at 6:51 PM, Rich Freeman <rich0@g.o> wrote: |
3 |
>> |
4 |
>> Yes, and in fact it is in the output when emerge fails: |
5 |
>> /var/tmp/portage/sys-kernel/spl-0.7.1/work/spl-0.7.1/config.log |
6 |
> |
7 |
|
8 |
Digging into config.log after a hiatus to attend to other demands of |
9 |
life. Comparing config.log output to the code in the corresponding |
10 |
"configure" script was a little enlightening - at least it was clear |
11 |
what the configure script was trying to do when it failed. In |
12 |
anticipation of throwing some echo statements into a modified script |
13 |
to help debug further, I tried to see if the configure script could be |
14 |
invoked using the command line arguments documented in config.log. To |
15 |
my surprise, when invoking configure that way, the script proceeded to |
16 |
completion without any problems. There's a clue. Executing on the |
17 |
command line as user root and group root leads to success, and |
18 |
executing through portage as portage:portage (judging from the |
19 |
ownership of files in |
20 |
/var/tmp/portage/sys-kernel/spl-0.7.1/work/spl-0.7.1) leads to |
21 |
failure. |
22 |
|
23 |
Thanks for the hint. back to debugging. |
24 |
|
25 |
John |