[cfe-dev] [RFC] Reliable compiler specification setting (at least include/lib dirs) through the process environment
Joseph Myers via cfe-dev
cfe-dev at lists.llvm.org
Mon Oct 17 10:21:42 PDT 2016
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 at codesourcery.com
More information about the cfe-dev
mailing list