NetBSD Problem Report #29142
From grant@mofo.grunta.com Fri Jan 28 13:14:42 2005
Return-Path: <grant@mofo.grunta.com>
Received: from mofo.grunta.com (mofo.grunta.com [203.55.81.8])
by narn.netbsd.org (Postfix) with ESMTP id CE55A63B400
for <gnats-bugs@gnats.NetBSD.org>; Fri, 28 Jan 2005 13:14:41 +0000 (UTC)
Message-Id: <200501281314.j0SDEXJ2005369@mofo.grunta.com>
Date: Sat, 29 Jan 2005 00:14:33 +1100 (EST)
From: grant@NetBSD.org
To: gnats-bugs@netbsd.org
Subject: bsd.wrapper.mk rev. 1.13 breaks non-gcc compilers
X-Send-Pr-Version: 3.95
>Number: 29142
>Category: pkg
>Synopsis: bsd.wrapper.mk rev. 1.13 breaks non-gcc compilers
>Confidential: no
>Severity: serious
>Priority: high
>Responsible: pkg-manager
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Jan 28 13:15:00 +0000 2005
>Closed-Date: Tue Mar 26 20:23:52 +0000 2013
>Last-Modified: Tue Mar 26 20:23:52 +0000 2013
>Originator: grant beattie
>Release: SunOS 5.9
>Organization:
>Environment:
System: SunOS u10 5.9 Generic_117171-02 sun4u sparc SUNW,Ultra-5_10
Architecture: sparc
Machine: sun4u
>Description:
the changes in bsd.wrapper.mk rev. 1.13 break the ${CC} and ${CXX}
(and maybe other?) compiler variables, in that the variables are
assigned the values for gcc, not the selected compiler:
% grep PKGSRC_COMPILER /etc/mk.conf
PKGSRC_COMPILER= sunpro
% bmake show-vars VARNAMES=CC PKG_PHASE=build
gcc
% bmake show-vars VARNAMES=CXX PKG_PHASE=build
g++
this causes packages to get confused about the compiler because the
value of ${CC}, ${CXX} is not the compiler being used.
WRAPPER_CC is being set to the wrong wrapper name:
% bmake show-vars VARNAMES=WRAPPER_CC PKG_PHASE=build
/tmp/pkgbuild/archivers/bzip2/work/.wrapper/bin/gcc
reverting bsd.wrapper.mk to revision 1.12 fixes the problem:
% bmake show-vars VARNAMES=CC PKG_PHASE=build
cc
% bmake show-vars VARNAMES=CXX PKG_PHASE=build
CC
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: pkg-manager->jlam
Responsible-Changed-By: ben@netbsd.org
Responsible-Changed-When: Fri, 28 Jan 2005 15:20:03 +0000
Responsible-Changed-Why:
Assigned to jlam, he volunteered to take care of this.
From: Johnny Lam <jlam@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc: grant@NetBSD.org
Subject: Re: pkg/29142: bsd.wrapper.mk rev. 1.13 breaks non-gcc compilers
Date: Tue, 01 Feb 2005 10:28:00 -0500
grant@NetBSD.org wrote:
>
> the changes in bsd.wrapper.mk rev. 1.13 break the ${CC} and ${CXX}
> (and maybe other?) compiler variables, in that the variables are
> assigned the values for gcc, not the selected compiler:
>
> % grep PKGSRC_COMPILER /etc/mk.conf
> PKGSRC_COMPILER= sunpro
> % bmake show-vars VARNAMES=CC PKG_PHASE=build
> gcc
> % bmake show-vars VARNAMES=CXX PKG_PHASE=build
> g++
>
> this causes packages to get confused about the compiler because the
> value of ${CC}, ${CXX} is not the compiler being used.
>
> WRAPPER_CC is being set to the wrong wrapper name:
>
> % bmake show-vars VARNAMES=WRAPPER_CC PKG_PHASE=build
> /tmp/pkgbuild/archivers/bzip2/work/.wrapper/bin/gcc
>
> reverting bsd.wrapper.mk to revision 1.12 fixes the problem:
>
> % bmake show-vars VARNAMES=CC PKG_PHASE=build
> cc
> % bmake show-vars VARNAMES=CXX PKG_PHASE=build
> CC
The code is intended to allow a user to set both CC and PKGSRC_COMPILER
in /etc/mk.conf, e.g.
CC= /my/beta/sunpro/cc -super-optimize
PKGSRC_COMPILER= sunpro
The problem here, which I didn't detect on my GCC system, is that the
value of CC in sys.mk is implicitly set before any CC in /etc/mk.conf is
set. I verified this on my system by adding:
CC?= myflargle
to /etc/mk.conf and running "make show-var VARNAME=CC" in
pkgsrc/security/priv, which yielded "cc", the value set from sys.mk.
By the time compiler.mk is included, there isn't any way to determine
where CC is being set -- all we know is that it's been pre-defined
before compiler.mk is included.
This problem is somewhat tricky to fix because there are several
conditions that must be preserved in any fix to the system, and I'll
need to first write some regression tests for them. It will be hard to
simply back out the change because many other commits subsequent to it
that depended upon that change being present.
For now, one workaround is to simply add:
CC= /opt/SUNWspro/bin/cc
CXX= /opt/SUNWspro/bin/CC
PKGSRC_COMPILER= sunpro
to your /etc/mk.conf.
Cheers,
-- Johnny Lam <jlam@NetBSD.org>
From: georg.schwarz@freenet.de (Georg Schwarz)
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: pkg/29142
Date: Fri, 4 Feb 2005 23:32:53 +0100
As a related problem, I find that work/.wrapper/bin/ld lately sets the
actual ld command to $LOCALBASE/bin/ld (typing out my $LOCALBASE that
is) instead of the system /usr/bin/ld one.
$LOCALBASE/bin/ld does exist on my system, but $LOCALBASE/bin is not in
the shell path.
--
Georg Schwarz http://home.pages.de/~schwarz/
georg.schwarz@freenet.de +49 177 8811442
From: grant beattie <grant@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc: jlam@netbsd.org, gnats-admin@netbsd.org, pkgsrc-bugs@netbsd.org
Subject: Re: pkg/29142: bsd.wrapper.mk rev. 1.13 breaks non-gcc compilers
Date: Wed, 23 Feb 2005 19:23:28 +1100
On Tue, Feb 01, 2005 at 03:28:02PM +0000, Johnny Lam wrote:
> The code is intended to allow a user to set both CC and PKGSRC_COMPILER
> in /etc/mk.conf, e.g.
>
> CC= /my/beta/sunpro/cc -super-optimize
> PKGSRC_COMPILER= sunpro
I suppose this is a desirable thing to support, since outside
pkgsrc-land, one is usually able to set CC to something like the above
and have things Just Work. this desire might rule out adding something
new like PKGSRC_CFLAGS ...
> The problem here, which I didn't detect on my GCC system, is that the
> value of CC in sys.mk is implicitly set before any CC in /etc/mk.conf is
> set. I verified this on my system by adding:
>
> CC?= myflargle
>
> to /etc/mk.conf and running "make show-var VARNAME=CC" in
> pkgsrc/security/priv, which yielded "cc", the value set from sys.mk.
right, I'd forgotten about this...
> By the time compiler.mk is included, there isn't any way to determine
> where CC is being set -- all we know is that it's been pre-defined
> before compiler.mk is included.
I've been trying to think of ways that we could possibly remove the
definition of CC/CXX (and others) from sys.mk, but that may pose a
problem with using bmake for non-pkgsrc purposes.
grant.
State-Changed-From-To: open->analyzed
State-Changed-By: jlam@netbsd.org
State-Changed-When: Mon, 06 Jun 2005 08:06:41 +0000
State-Changed-Why:
This PR will be addressed after the upcoming 2005Q2 branch. The
solution involves changing some fundamental design decisions in the
wrapper and compiler frameworks.
State-Changed-From-To: analyzed->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Tue, 09 Feb 2010 21:21:26 +0000
State-Changed-Why:
Is this problem still relevant?
Responsible-Changed-From-To: jlam->pkg-manager
Responsible-Changed-By: wiz@NetBSD.org
Responsible-Changed-When: Sun, 21 Mar 2010 16:05:32 +0000
Responsible-Changed-Why:
Back to role account, jlam lost his commit bit.
State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Fri, 09 Apr 2010 06:38:58 +0000
State-Changed-Why:
grant retired too, so this one is now completely in limbo.
From: Benny Siegert <bsiegert@gmail.com>
To: gnats-bugs@netbsd.org
Cc: David Holland <dholland-pkgtech@netbsd.org>, Thomas Klausner <wiz@netbsd.org>
Subject: Re: pkg/29142
Date: Tue, 26 Mar 2013 20:46:59 +0100
Is there any way this bug report can move forward _at all_?
There have been updates to sunpro on Solaris since this bug has been
filed, the submitter _and_ the analyzer are no longer with the
project, and probably nobody has a Solaris 9 system to test whether
the bug is still in there.
I am inclined to just closed the report.
--Benny.
State-Changed-From-To: open->closed
State-Changed-By: wiz@NetBSD.org
State-Changed-When: Tue, 26 Mar 2013 20:23:52 +0000
State-Changed-Why:
Let's discuss this problem if it occurs again, in a new PR.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.