On Wed, 2 Nov 2005, Todd Vierling wrote:

> On Wed, 2 Nov 2005, Todd Vierling wrote:
>
> > I wouldn't be surprised if the Darwin-supplied bsd.*.mk files set these,
> > causing a failure similar to the one I've run into on Interix.
> >
> > I'm trying to track down the include ordering problem now.
>
> OK, so MAKESYSPATH doesn't work as an override.  If I change (in
> makefile.boot.in):
>
> 	${BMAKE_ENV} ./bmake.boot -f Makefile
>
> to:
>
> 	${BMAKE_ENV} ./bmake.boot -m ${MK} -f Makefile
>
> it manages to start building the non-bootstrap bmake.
>
> Besides that, however, I don't think pkgsrc-supplied bmake should be
> searching the alternate paths -- ever.  From a truss(1) output, I see it
> opening *all* incarnations of a .mk file and parsing them -- which is very
> harmful to bmake.  System-supplied "BSD make" .mk fragments are somewhat
> make version specific, so if the OS supplies such files, they should be used
> only by the native make, not pkgsrc-supplied bmake.
>
> I highly recommend changing both bootstrap and devel/bmake such that the
> path passed to boot-strap contains $prefix/share/mk and nothing else.  This
> will remove the need for both MAKESYSPATH and -m, and will prevent the
> read-'em-all lunacy I am seeing.

Might the behavior you describe above have any bearing on the problem
I noticed and posted about in:

    http://mail-index.netbsd.org/tech-pkg/2005/10/24/0001.html

Where packages are linking against the wrong instance of libz (and
other libs supplied by the base system but also installed via pkgsrc)?

The PR mentioned in the posting describes a similar problem under
Jaguar 10.2.8.  10.3.9 appears not to exhibit the problem, though.

-- 
John D. Baker, KN5UKS                    NetBSD     Darwin/MacOS X
jdbaker(at)mylinuxisp(dot)com                 OpenBSD            FreeBSD
BSD -- It just sits there and _works_!