Re: Where are the original commands defined?

[Eric Blake]

On 1/24/19 10:00 AM, Peng Yu wrote:
> Please answer my original question.
> 
> I know the things that you answered.
> 
> - I know the problem is fPIC was not enabled.
> - I use root as its just a docker image with root as the default login.
> 

Even if you don't care whether the configure could have trashed your
system, running configure as root may compute different answers to
questions being probed, and cause the package to behave differently than
if you had run configure as a normal user.  In general, you do NOT want
to run configure as root, regardless of whatever other sandboxing is in
place.

> 
> On Thu, Jan 24, 2019 at 9:54 AM Zack Weinberg <address@hidden> wrote:
>>
>> On Thu, Jan 24, 2019 at 10:48 AM Peng Yu <address@hidden> wrote:
>>> I got the following int config.log when I run
>>> http://git.savannah.gnu.org/cgit/bash.git/tree/configure
>> ...
>>> configure also runs many other commands. How to figure out where the
>>> original commands are defined? Thanks.

As in, how do you correlate the line numbers reported in config.log
(such as the "configure:3772: gcc -g -finstrument-functions" in your
snippet) back to the line numbers in configure.ac that produced those
lines in configure?  One trick is to add harmless witness statements in
your configure.ac, such as:

: probe point

then after rerunning autoreconf, search for where the probe points got
omitted, to see if their location in configure.ac is before or after the
macro that expanded to the line in question.  Use echo instead of : if
you also need help in comparing the output of configure to spot where
your probe point was executed in relation to the other things being run.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

signature.asc
Description: OpenPGP digital signature