Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 29 Sep 2008 02:10:37 +0100
From:      Bruce M Simpson <bms@incunabulum.net>
To:        Andrey Chernov <ache@nagual.pp.ru>, Bruce M Simpson <bms@incunabulum.net>, freebsd-embedded@FreeBSD.org
Subject:   Re: r181397 of src/usr.bin/make/job.c breaks cross-compiles
Message-ID:  <48E02B0D.9030806@incunabulum.net>
In-Reply-To: <20080929002040.GA64397@nagual.pp.ru>
References:  <48E001DC.9010503@incunabulum.net> <20080929002040.GA64397@nagual.pp.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
Andrey Chernov wrote:
> Please explain, how it may cause problem? In 'make world' or 'make 
> buildworld;make installworld' headers and libraries was builded first with 
> old make, _then_ the new make is builded. 'make' is not a bootstrap tool 
> builded first (at -current, I don't check -stable branch)
>   

When I use NanoBSD to build a system image for the ARM, nanobsd.sh 
invokes the "make" targets in the source tree which I imagine most 
developers are familiar with; the build system attempts to build "make" 
first thing in the host's staging area under MAKEOBJDIRPREFIX, as one 
would normally expect.

What is strange about this failure, is the fact that the "buildworld" 
target does not stop due to the error until after the dependency pass is 
made over the tree.

I traced the problem back in logs to the "make" failing to find 
arc4random_uniform() during link. Given that it's building a "make" 
executable for the *host*, not the *target*, I would expect to see this 
error, as this function doesn't exist in FreeBSD 7.1.

It looks to me as if the change to "make" assumes that the FreeBSD 8.x 
versions of the arc4 library functions are always available, even for 
cross compilation. This assumption doesn't seem to be robust, and it 
breaks down in this cross-compilation use case.

Can you please advise what the best way to fix this in the source is?

It looks as though the change should either be backed out, so the 
cross-compilation use case is unbroken, or wrapped with a 
__FreeBSD_version guard.

thanks again for all your help
BMS



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48E02B0D.9030806>