Building environment using system headers instead of the in-tree headers

Simon J. Gerraty sjg at juniper.net
Fri Oct 12 17:38:34 UTC 2012


On Mon, 08 Oct 2012 17:14:18 -0700, Xin Li writes:
>As it turns out, this was caused by addition of xlocale functionality
>on FreeBSD 9.1, which uses macros and expects some new functions found
>in more recent FreeBSD releases.  On the other hand, we do not pass
>e.g. -I${.CURDIR}/../../include so the header is preferred than system
>header.

Ideally anything which needs to build for the "host" should be
sufficiently portable/generic that it can build on *any* host.

There are better ways to tackle this than sprinkling
-I${.CURDIR}/../../include everywhere - which only addresses a small
fraction of the issue anyway (src/include contains only a fraction of
what ends up in /usr/include).

I think many/most of these sorts of issues will be neatly addressed by
the changes we are planning to introduce to the FreeBSD build.
The build infrastructure should understand the difference b/w building
for host and target, and the correct -I's added automatically.

In the Junos build for example we have the notion of PURE_HOSTPROG.
"yes" means the app can build cleanly using only the host env
"no" means it needs to use  headers (perhaps generated code
etc) from the src tree and so picks up additional -I's.
By default hostpog's use the host's libs, but that can be overridden
when needed (eg. an ATF test being built for the host, but wants to link
the lib from the src tree that it is trying to test).

--sjg



More information about the freebsd-arch mailing list