DragonFly BSD
DragonFly bugs List (threaded) for 2005-09
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: make nrelease CCVER issues


From: Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>
Date: Thu, 1 Sep 2005 00:12:25 +0200
Mail-followup-to: bugs@crater.dragonflybsd.org

On Wed, Aug 31, 2005 at 08:55:12PM +0200, Simon 'corecode' Schubert wrote:
> Joerg Sonnenberger wrote:
> >>some people already wondered (including me) about why you had to set 
> >>CCVER=gcc34 manually when building -Devel nrelease isos on -Release.
> >As I tried to say before, does specifying HOST_CCVER=gcc34 for
> >buildworld help? The problem exists because of the oddities of rpcgen
> >and the default environment coming from the old share/mk.
> 
> The problem is that rpcgen uses cpp (=objdump) which wants to use gcc2 
> cpp because CCVER=gcc2 at this point, though it should be gcc34.

Yes and no. Part of the problem is exactly that rpcgen is calling cpp
directly and doesn't get the normal environment changes that e.g. cc
get.

> >>Bug!  It sets (internally) FOO to the override "gcc34", but the env FOO 
> >>doesn't change!  And as src/Makefile is just a wrapper which execs
> >>make -f Makefile.inc1, the CCVER=gcc34 override setting doesn't get 
> >>propagated.  Everything else uses CCVER=gcc2 again.
> >No, it is *not* a bug. It is documented behaviour a lot of people (have
> >to) relay on.
> 
> yes it is a bug.  did you read the code?  it is making FOO an env var 
> but doesn't allow to override it.  I didn't say it's a bug in make.  If 
> not in make, then in the makefile.  We need to fix it somehow, because 
> we don't support building -devel with gcc2.

The problems comes from the default value of CCVER from the old .mk
files. It should go away when you either specify CCVER or HOST_CCVER.

Joerg



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]