Date: Tue, 29 Mar 2011 14:20:30 -0700 From: mdf@FreeBSD.org To: freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Include file search path Message-ID: <AANLkTi=BiUVnzsGg83wwWPHjnTDR=XukhJ3UK6Bd5hvF@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
I thought I knew something about how the compiler looks for include files, but now I think maybe I don't know much. :-) So here's what I'm pondering. When I build a library, like e.g. libc, where do the include files get pulled from? They can't (shouldn't) be the ones in /usr/include, but I don't see a -nostdinc like for the kernel. There are -I directives in the Makefile for -I${.CURDIR}/include -I${.CURDIR}/../../include, etc., but that won't remove /usr/include from the search path. I see in the gcc documentation that -I paths are searched before the standards paths. But isn't the lack of -nostdinc a bug (not just for libc, but for any library in /usr/src/lib)? It somewhat feels to me that all of the libraries and binaries in the source distribution should use -nostdinc and include only from the source distribution itself. This isn't always an issue, but for source upgrades it seems crucial, and for a hacker it saves difficulties with having to install headers before re-building. Is that the intent, and it's not fully implemented? How badly would things break if -nostdinc was included in e.g. bsd.lib.mk? (This would break non-base libraries, yes? But as a thought experiment for the base, how far off are we?) Thanks, matthew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=BiUVnzsGg83wwWPHjnTDR=XukhJ3UK6Bd5hvF>