Re: [RFC] Reliable compiler specification setting (at least include/lib dirs) through the process environment

[Joseph Myers <joseph at codesourcery dot com>]

On Sun, 16 Oct 2016, Shea Levy wrote:

> options) and clearly have the semantics we want. Ideally we would be
> able to specify something on the level of abstraction of "this directory
> should be treated like you would normally treat /usr" and get
> e.g. /include, /lib, frameworks on OS X, etc. handled properly.

What that suggests to me is options for having multiple sysroots (which 
are treated like / not like /usr, but that's the existing concept for a 
directory containing both header and library subdirectories, and you could 
combine this with a Hurd-style configuration of the expected sysroot 
subdirectories, i.e. no /usr inside the sysroot).  That would however be 
rather complex; both GCC and ld presume there is a single global sysroot 
(modulo SYSROOT_SUFFIX_SPEC / SYSROOT_HEADERS_SUFFIX_SPEC that append to 
it), as do the interfaces for other specs that pass down sysroot 
information to cc1 etc. - and ld then interprets absolute paths in linker 
scripts such as libc.so in a sysroot relative to that sysroot (so would 
need to track which sysroot a particular linker script was found in to 
know how to interpret absolute paths in it), and options such as -I=dir 
for a sysroot-relative include don't have a clear meaning with multiple 
sysroots.

I'm wary of adding environment variables as they tend to make debugging 
hard when the same compiler behaves differently for different people for 
no obvious reason.

You should not need to exclude linker options (as opposed to linker input 
files) from the command line when not linking, or compiler options when 
linking.

-- 
Joseph S. Myers
joseph@codesourcery.com