2014/1/22 Pierre M.R. <[email protected]> > Enrique Larraia wrote: > > Not sure how to check this. > To be rude. I would edit gcc-build/libtool to add at line 1121: echo $PATH >
Yeah, this solved the issue. Now I figured out what was going on. On adding echo $PATH at the beginning of the problematic function in libtools script it was revealed that PATH was set to a different value. The key is in running 'make install' as 'sudo make install'. From man sudoers: "Since environment variables can influence program behavior, sudoers provides a means to restrict which variables from the user's environment are inherited by the command to be run. There are two distinct ways sudoers can deal with environment variables. By default, the env_reset option is enabled. This causes commands to be executed with a minimal environment containing TERM, PATH, HOME, MAIL, SHELL, LOGNAME, USER and USERNAME in addition to variables from the invoking process permitted by the env_check and env_keep options. This is effectively a whitelist for environment variables." Thus, in theory PATH is kept in the environment, then I had a look at /etc/sudoers and found this option enbaled: Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" Which indeed matched the PATH value given in the libtool script. I commented it out, and 'sudo make install' went through. I guess sudo overwrites PATH if the option is enabled. Thank to all! > Pierre > -- > http://linuxfromscratch.org/mailman/listinfo/lfs-support > FAQ: http://www.linuxfromscratch.org/lfs/faq.html > Unsubscribe: See the above information page >
-- http://linuxfromscratch.org/mailman/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/lfs/faq.html Unsubscribe: See the above information page
