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 <zackw@xxxxxxxxx> wrote: >> >> On Thu, Jan 24, 2019 at 10:48 AM Peng Yu <pengyu.ut@xxxxxxxxx> 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
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx https://lists.gnu.org/mailman/listinfo/autoconf
