NetBSD Problem Report #21932

Received: (qmail 12960 invoked by uid 605); 19 Jun 2003 17:56:10 -0000
Message-Id: <200306191756.h5JHu3f20427@digital.clock.org>
Date: Thu, 19 Jun 2003 10:56:03 -0700 (PDT)
From: fair@netbsd.org
Sender: gnats-bugs-owner@netbsd.org
Reply-To: fair@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Subject: pkgsrc should support CPUFLAGS from /etc/mk.conf
X-Send-Pr-Version: 3.95

>Number:         21932
>Category:       pkg
>Synopsis:       pkgsrc should support CPUFLAGS from /etc/mk.conf
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Thu Jun 19 17:57:02 +0000 2003
>Closed-Date:    
>Last-Modified:  Thu Jun 26 10:48:01 +0000 2003
>Originator:     Erik E. Fair
>Release:        NetBSD-current
>Organization:
The NetBSD Project
>Environment:
>Description:
	NetBSD sets its compilers to deliver maximum binary compatability
	across the series of platforms that share a CPU, e.g. all NetBSD/alpha
	systems have compilers that will compile to the 21064, the first alpha.
	This is great for an initial install, and for installations that have
	a wide range of a given family of systems which share binaries on NFS.
	This practice also means we can support the widest range of systems
	with one binary release per platform.

	However, this practice also means that NetBSD does not take advantage
	of performance enhancing improvements in the instruction sets of later
	models of the Alpha, e.g. the 21164a, which has the BWX instructions.
	In short, on single systems, we often do not perform as well as we
	could. GCC 3.3 promises to make this disparity worse, by providing
	more complete support for instruction sheduling, and CPU-specific
	instruction generation.

	In order to make it easier to compile CPU-specific binaries, Jason
	Thorpe recently added CPUFLAGS to the /usr/share/mk/* files, as
	distinct from CFLAGS, so that they can be easily included without
	stomping on other things that are added to CFLAGS (e.g. optimization
	flags).

	I think that pkgsrc should support this also, to the extent that it
	is possible to do within the confines of third-party supplied "make"
	procedures which may or may not actually involve BSD make(1); it is
	especially important that those third party applications which we
	support perform as well as they can on the user's chosen platform when
	the user chooses to optimize for that platform.

>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:

From: David Brownlee <abs@netbsd.org>
To: fair@netbsd.org
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: pkg/21932: pkgsrc should support CPUFLAGS from /etc/mk.conf
Date: Fri, 20 Jun 2003 17:14:01 +0100 (BST)

 On Thu, 19 Jun 2003 fair@netbsd.org wrote:

 > 	In order to make it easier to compile CPU-specific binaries, Jason
 > 	Thorpe recently added CPUFLAGS to the /usr/share/mk/* files, as
 > 	distinct from CFLAGS, so that they can be easily included without
 > 	stomping on other things that are added to CFLAGS (e.g. optimization
 > 	flags).

 	I was under the impression that COPTS could be used for this
 	purpose in the base system.

 	devel/cpuflags installs a cpuflags.mk file that sets CPU_FLAGS
 	then:

 .ifdef BSD_PKG_MK                       # Try to catch various package opts
 CFLAGS+=${CPU_FLAGS}
 CXXFLAGS+=${CPU_FLAGS}
 MAKE_FLAGS+=CCOPTIONS="${CPU_FLAGS}"    # Override CCOPTIONS for imake

 .else                                   # Assume in base system, only COPTS
 COPTS?=${CPU_FLAGS} ${DEFCOPTS}
 # Include ${DEFCOPTS} and set ?= to allow overriding in kernel builds

 .endif

 	I would suggest adding something like the following to bsd.pkg.mk:

 .if defined(PKG_CPUFLAGS)
 CFLAGS+=${PKG_CPUFLAGS}
 CXXFLAGS+=${PKG_CPUFLAGS}
 MAKE_FLAGS+=CCOPTIONS="${PKG_CPUFLAGS}"    # Override CCOPTIONS for imake
 .endif

 	That would allow people to set PKG_CPUFLAGS and CPUFLAGS
 	differently.

 -- 
 		David/absolute          -- www.netbsd.org: No hype required --

From: fredb@immanent.net (Frederick Bruckman)
To: fair@netbsd.org, abs@netbsd.org, fredb@netbsd.org
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: pkg/21932: pkgsrc should support CPUFLAGS from /etc/mk.conf
Date: Mon, 23 Jun 2003 12:43:19 -0500 (CDT)

 In article <200306191756.h5JHu3f20427@digital.clock.org>,
 	fair@netbsd.org writes:
 > 
 > 	In order to make it easier to compile CPU-specific binaries, Jason
 > 	Thorpe recently added CPUFLAGS to the /usr/share/mk/* files, as
 > 	distinct from CFLAGS, so that they can be easily included without
 > 	stomping on other things that are added to CFLAGS (e.g. optimization
 > 	flags).
 > 
 > 	I think that pkgsrc should support this also, to the extent that it
 > 	is possible to do within the confines of third-party supplied "make"
 > 	procedures which may or may not actually involve BSD make(1)...

 I agree completely. I'd even thought of doing something similiar to that.

 From: David Brownlee <abs@netbsd.org>
 To: fair@netbsd.org
 Cc: gnats-bugs@gnats.netbsd.org
 Subject: Re: pkg/21932: pkgsrc should support CPUFLAGS from /etc/mk.conf
 Date: Fri, 20 Jun 2003 17:14:01 +0100 (BST)

 ....

         I would suggest adding something like the following to bsd.pkg.mk:

  .if defined(PKG_CPUFLAGS)
  CFLAGS+=${PKG_CPUFLAGS}
  CXXFLAGS+=${PKG_CPUFLAGS}
  MAKE_FLAGS+=CCOPTIONS="${PKG_CPUFLAGS}"    # Override CCOPTIONS for imake
  .endif

         That would allow people to set PKG_CPUFLAGS and CPUFLAGS
         differently.

 You can't... CPUFLAGS is automatically added to CFLAGS in <sys.mk> (for users
 of NetBSD 1.6U and newer), so every package that respects CFLAGS should get
 it already. Users can do the switch the ordinary way, with ".ifdef BSD_PKG_MK".
 Given that, the place to add it for the other folks is in "bsd.prefs.mk".

 More interesting, to me, is to find a way to distinguish the packages built
 with submodel flags that would make them unusable on other hosts. I feel that
 without this, a mixed collection will become unmanagable. My idea is to
 install the package with the same name as before, but only munge the name of
 the package tarball, by adding the contents of the "-march=" flag after the
 version number. The "-march" tag, I think is adequate for this -- builders
 of private collections can use that as a signal for less commonly used ABI
 breakers, if desired.

 The beauty of it, is, the dependency system in pkgsrc is ignorant of the
 name of the original tarball, so it's not affected, and the point of putting
 the tag after the version number, rather than before, is so that the wildcard
 dependencies will mostly take care of matching the slightly changed name by
 "pkg_add". (A few packages which don't use wildcards for dependencies would
 need fixing.)

 The following patch accomplishes this goal. Please test. The "pkg_add" part
 only mostly works: You can leave the suffix off of the invocation of "pkg_add"
 for the package you're installing directly, but for the dependencies in the
 package to be found in $PKG_PATH, "pkg_add" says it can't find them, but then
 installs them anyway. I guess "pkg_add" would need some fixing, too, perhaps,
 even, to respect a preference for packages with certain $CPUFLAGS values?


 Index: bsd.pkg.mk
 ===================================================================
 RCS file: /cvsroot/pkgsrc/mk/bsd.pkg.mk,v
 retrieving revision 1.1202
 diff -u -r1.1202 bsd.pkg.mk
 --- bsd.pkg.mk	2003/06/23 14:26:32	1.1202
 +++ bsd.pkg.mk	2003/06/23 16:45:01
 @@ -1069,7 +1069,7 @@

  PKGREPOSITORYSUBDIR?=	All
  PKGREPOSITORY?=		${PACKAGES}/${PKGREPOSITORYSUBDIR}
 -PKGFILE?=		${PKGREPOSITORY}/${PKGNAME}${PKG_SUFX}
 +PKGFILE?=		${PKGREPOSITORY}/${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX}

  CONFIGURE_DIRS?=	${WRKSRC}
  CONFIGURE_SCRIPT?=	./configure
 @@ -2246,15 +2246,15 @@
  				exit 1;					\
  			fi;						\
  		fi;							\
 -		${RM} -f ${PACKAGES}/$$cat/${PKGNAME}${PKG_SUFX};	\
 -		${LN} -s ../${PKGREPOSITORYSUBDIR}/${PKGNAME}${PKG_SUFX} ${PACKAGES}/$$cat; \
 +		${RM} -f ${PACKAGES}/$$cat/${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX}; \
 +		${LN} -s ../${PKGREPOSITORYSUBDIR}/${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX} ${PACKAGES}/$$cat; \
  	done;
  .endif

  .if !target(delete-package-links)
  delete-package-links:
  	${_PKG_SILENT}${_PKG_DEBUG}\
 -	${FIND} ${PACKAGES} -type l -name ${PKGNAME}${PKG_SUFX} | ${XARGS} ${RM} -f
 +	${FIND} ${PACKAGES} -type l -name ${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX} | ${XARGS} ${RM} -f
  .endif

  .if !target(delete-package)
 @@ -3116,7 +3116,7 @@
  # Create a binary package from an install package using "pkg_tarup"
  tarup:
  	${_PKG_SILENT}${_PKG_DEBUG}					\
 -	${RM} -f ${PACKAGES}/All/${PKGNAME}${PKG_SUFX};			\
 +	${RM} -f ${PACKAGES}/All/${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX}; \
  	${SETENV} PKG_DBDIR=${PKG_DBDIR} PKG_SUFX=${PKG_SUFX}		\
  		PKGREPOSITORY=${PACKAGES}/All				\
  		${LOCALBASE}/bin/pkg_tarup ${PKGNAME};			\
 @@ -3124,7 +3124,7 @@
  		${MKDIR} ${PACKAGES}/$$CATEGORY;			\
  		cd ${PACKAGES}/$$CATEGORY;				\
  		${RM} -f ${PKGNAME}${PKG_SUFX};				\
 -		${LN} -s ../All/${PKGNAME}${PKG_SUFX};			\
 +		${LN} -s ../All/${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX};	\
  	done

  # shared code for replace and undo-replace
 @@ -3172,7 +3172,7 @@
  	${ECHO_MSG} "*** WARNING - experimental target - data loss may be experienced ***"; \
  	oldpkgname=${PKGNAME};						\
  	newpkgname=`${CAT} ${WRKDIR}/.replace`;				\
 -	replace_action="${SETENV} ${PKG_ADD} ${WRKDIR}/$$newpkgname${PKG_SUFX}"; \
 +	replace_action="${SETENV} ${PKG_ADD} ${WRKDIR}/$$newpkgname${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX}"; \
  	${_REPLACE};							\
  	${RM} ${WRKDIR}/.replace

 @@ -3552,8 +3552,8 @@
  		arch=${MACHINE_ARCH}; 					\
  		for site in ${BINPKG_SITES} ; do 			\
  			${ECHO} Trying `eval ${ECHO} $$site`/All ; 	\
 -			${SHCOMMENT} ${ECHO} ${SETENV} PKG_PATH="`eval ${ECHO} $$site`/All" ${PKG_ADD} ${BIN_INSTALL_FLAGS} ${PKGNAME}${PKG_SUFX} ; \
 -			if ${SETENV} PKG_PATH="`eval ${ECHO} $$site`/All" ${PKG_ADD} ${BIN_INSTALL_FLAGS} ${PKGNAME}${PKG_SUFX} ; then \
 +			${SHCOMMENT} ${ECHO} ${SETENV} PKG_PATH="`eval ${ECHO} $$site`/All" ${PKG_ADD} ${BIN_INSTALL_FLAGS} ${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX} ; \
 +			if ${SETENV} PKG_PATH="`eval ${ECHO} $$site`/All" ${PKG_ADD} ${BIN_INSTALL_FLAGS} ${PKGNAME}${CPUFLAGS:M-march=*:S/march=//}${PKG_SUFX} ; then \
  				${ECHO} "${PKGNAME} successfully installed."; \
  				break ; 				\
  			fi ; 						\
 @@ -4200,7 +4200,7 @@
  	if [ ! -d ${PKG_DBDIR}/${PKGNAME} ]; then			\
  		${ECHO_MSG} "${_PKGSRC_IN}> Registering installation for ${PKGNAME}"; \
  		${MKDIR} ${PKG_DBDIR}/${PKGNAME};			\
 -		${PKG_CREATE} ${PKG_ARGS_INSTALL} -O ${PKGFILE} > ${PKG_DBDIR}/${PKGNAME}/+CONTENTS; \
 +		${PKG_CREATE} ${PKG_ARGS_INSTALL} -O ${PKGNAME}${PKG_SUFX} > ${PKG_DBDIR}/${PKGNAME}/+CONTENTS; \
  		${CP} ${DESCR} ${PKG_DBDIR}/${PKGNAME}/+DESC;		\
  		${ECHO} ${COMMENT:Q} > ${PKG_DBDIR}/${PKGNAME}/+COMMENT; \
  		${CP} ${BUILD_VERSION_FILE} ${PKG_DBDIR}/${PKGNAME}/+BUILD_VERSION; \
 @@ -4380,7 +4380,8 @@
  #	the contents of ${PLIST_SRC}.
  #
  GENERATE_PLIST?=	${TRUE};
 -_GENERATE_PLIST=	${CAT} ${PLIST_SRC}; ${GENERATE_PLIST}
 +_GENERATE_PLIST=	${ECHO} "@name " ${PKGNAME};			\
 +			${CAT} ${PLIST_SRC}; ${GENERATE_PLIST}

  plist: ${PLIST}
  ${PLIST}: ${PLIST_SRC}
 Index: bsd.prefs.mk
 ===================================================================
 RCS file: /cvsroot/pkgsrc/mk/bsd.prefs.mk,v
 retrieving revision 1.113
 diff -u -r1.113 bsd.prefs.mk
 --- bsd.prefs.mk	2003/06/05 00:23:29	1.113
 +++ bsd.prefs.mk	2003/06/23 16:45:02
 @@ -259,6 +259,11 @@
  WHOLE_ARCHIVE_FLAG?=	${_OPSYS_WHOLE_ARCHIVE_FLAG}
  NO_WHOLE_ARCHIVE_FLAG?=	${_OPSYS_NO_WHOLE_ARCHIVE_FLAG}

 +# CPUFLAGS is automatically added to CFLAGS since about NetBSD 1.6U.
 +.if ${OPSYS} != "NetBSD" || (!empty(OS_VERSION:M1.5*) || !empty(OS_VERSION:M1.6[_.A-T]*))
 +CFLAGS+=		${CPUFLAGS}
 +.endif
 +
  .ifndef DIGEST
  DIGEST:=		${LOCALBASE}/bin/digest
  MAKEFLAGS+=		DIGEST=${DIGEST}


 Frederick

From: David Brownlee <abs@netbsd.org>
To: Frederick Bruckman <fredb@immanent.net>
Cc: fair@netbsd.org, fredb@netbsd.org, gnats-bugs@gnats.netbsd.org
Subject: Re: pkg/21932: pkgsrc should support CPUFLAGS from /etc/mk.conf
Date: Tue, 24 Jun 2003 11:17:35 +0100 (BST)

 On Mon, 23 Jun 2003, Frederick Bruckman wrote:

 > More interesting, to me, is to find a way to distinguish the packages built
 > with submodel flags that would make them unusable on other hosts. I feel that
 > without this, a mixed collection will become unmanagable. My idea is to
 > install the package with the same name as before, but only munge the name of
 > the package tarball, by adding the contents of the "-march=" flag after the
 > version number. The "-march" tag, I think is adequate for this -- builders
 > of private collections can use that as a signal for less commonly used ABI
 > breakers, if desired.
 >
 > The beauty of it, is, the dependency system in pkgsrc is ignorant of the
 > name of the original tarball, so it's not affected, and the point of putting
 > the tag after the version number, rather than before, is so that the wildcard
 > dependencies will mostly take care of matching the slightly changed name by
 > "pkg_add". (A few packages which don't use wildcards for dependencies would
 > need fixing.)
 >
 > The following patch accomplishes this goal. Please test. The "pkg_add" part
 > only mostly works: You can leave the suffix off of the invocation of "pkg_add"
 > for the package you're installing directly, but for the dependencies in the
 > package to be found in $PKG_PATH, "pkg_add" says it can't find them, but then
 > installs them anyway. I guess "pkg_add" would need some fixing, too, perhaps,
 > even, to respect a preference for packages with certain $CPUFLAGS values?

 	I tend to have the following in mk.conf

 .ifdef LINTPKGSRC
 PACKAGES=${PKGSRCDIR}/packages
 .else
 PACKAGES=${PKGSRCDIR}/packages/${OPSYS}-${OS_VERSION}-${LOWER_ARCH}${CPU_DIR}
 .endif

 	${CPU_DIR} is set automatically by cpuflags.mk to ${CPU_FLAGS}
 	with spaces stripped, which can end up with things like
 	'-march=armv3m-mtune=strongarm' or '-m68040-msoft-float'

 	We already have a situation where by default building binary
 	packages from two different architectures will result in
 	a mismatched collection of packages in pkgsrc/packages. Could
 	I suggest we set ${CPU_DIR} or similar from ${CPUFLAGS} and
 	have PACKAGES as above?

 -- 
 		David/absolute          -- www.netbsd.org: No hype required --

From: Frederick Bruckman <fredb@immanent.net>
To: David Brownlee <abs@netbsd.org>
Cc: fair@netbsd.org, gnats-bugs@gnats.netbsd.org
Subject: Re: pkg/21932: pkgsrc should support CPUFLAGS from /etc/mk.conf
Date: Tue, 24 Jun 2003 10:33:58 -0500 (CDT)

 On Tue, 24 Jun 2003, David Brownlee wrote:

 > On Mon, 23 Jun 2003, Frederick Bruckman wrote:
 >
 > > More interesting, to me, is to find a way to distinguish the packages built
 > > with submodel flags that would make them unusable on other hosts.

 > 	I tend to have the following in mk.conf
 >
 > .ifdef LINTPKGSRC
 > PACKAGES=${PKGSRCDIR}/packages
 > .else
 > PACKAGES=${PKGSRCDIR}/packages/${OPSYS}-${OS_VERSION}-${LOWER_ARCH}${CPU_DIR}
 > .endif

 Hmm. I think it was a mistake in the first place, not to have
 ${MACHINE_ARCH} embedded in the filename of the binary package, so I
 wanted to see if it was possible to make that different from the
 package name. I see that it is. Maybe we should just go all the way
 with the idea, and put <machine-arch>-<submodel> in each package name?

 > 	${CPU_DIR} is set automatically by cpuflags.mk to ${CPU_FLAGS}
 > 	with spaces stripped, which can end up with things like
 > 	'-march=armv3m-mtune=strongarm' or '-m68040-msoft-float'
 >
 > 	We already have a situation where by default building binary
 > 	packages from two different architectures will result in
 > 	a mismatched collection of packages in pkgsrc/packages. Could
 > 	I suggest we set ${CPU_DIR} or similar from ${CPUFLAGS} and
 > 	have PACKAGES as above?

 We have to be careful not to go too far. My favorite, this
 week is, "-O2 -march=k6-2 -ffast-math -finline-functions
 -maccumulate-outgoing-args -momit-leaf-frame-pointer".[*] The
 only part of that that actually matters, compatibility-wise, is the
 "-march=k6-2". Also keep in mind, that the user doesn't have to have
 cpuflags installed to set such options, and we really don't want to
 take chances that incompatible packages get mixed together on
 ftp.netbsd.org. Therefore, I feel we should calculate the tag
 in bsd.prefs.mk. Maybe something like this...?

 CPU_TAG=	${CPUFLAGS:M-march=*:S/march=//}
 CPU_TAG+=	${CPUFLAGS:M-m680*:S/-m//}
 CPU_TAG+=	${CPUFLAGS:M-msoft-float=*:S/-m//}

 ...and then, of course, that gets inserted in all the places I've
 already identified in the patch.

 Frederick


 [*] "-O3" turns on "-funroll-loops" and "-frename-registers", besides
 "-finline-functions". The documention points out that "-funroll-loops"
 isn't alway faster -- nor would you expect it to be -- and that
 "-frename-registers" is most useful on a architecture with lots of
 registers --- which i386 isn't. "-fomit-frame-pointer" doesn't even
 compile all of the time -- but "-momit-leaf-frame-pointer" hasn't
 given me any trouble, yet. "-maccumulate-outgoing-args" is
 speculative; it certainly does make the binary 5 - 10% bigger than
 without it (but not necessarily bigger than -funroll-loops), but I
 haven't done any benchmarks, yet.

From: David Brownlee <abs@netbsd.org>
To: Frederick Bruckman <fredb@immanent.net>
Cc: fair@netbsd.org, gnats-bugs@gnats.netbsd.org
Subject: Re: pkg/21932: pkgsrc should support CPUFLAGS from /etc/mk.conf
Date: Thu, 26 Jun 2003 11:47:28 +0100 (BST)

 On Tue, 24 Jun 2003, Frederick Bruckman wrote:

 > On Tue, 24 Jun 2003, David Brownlee wrote:
 >
 > > On Mon, 23 Jun 2003, Frederick Bruckman wrote:
 > >
 > > > More interesting, to me, is to find a way to distinguish the packages built
 > > > with submodel flags that would make them unusable on other hosts.
 >
 > > 	I tend to have the following in mk.conf
 > >
 > > .ifdef LINTPKGSRC
 > > PACKAGES=${PKGSRCDIR}/packages
 > > .else
 > > PACKAGES=${PKGSRCDIR}/packages/${OPSYS}-${OS_VERSION}-${LOWER_ARCH}${CPU_DIR}
 > > .endif
 >
 > Hmm. I think it was a mistake in the first place, not to have
 > ${MACHINE_ARCH} embedded in the filename of the binary package, so I
 > wanted to see if it was possible to make that different from the
 > package name. I see that it is. Maybe we should just go all the way
 > with the idea, and put <machine-arch>-<submodel> in each package name?

 	I would prefer to see at least machine_arch details in the
 	default PACKAGES directory, to somewhat match the binary
 	packages on ftp.netbsd.org, but that is not a strong
 	preference over embedding the details in the filename.
 	Either would be _much_ better than where we are now.

 	We should take this up on tech-pkg@ or packages@.

 > > 	${CPU_DIR} is set automatically by cpuflags.mk to ${CPU_FLAGS}
 > > 	with spaces stripped, which can end up with things like
 > > 	'-march=armv3m-mtune=strongarm' or '-m68040-msoft-float'
 > >
 > > 	We already have a situation where by default building binary
 > > 	packages from two different architectures will result in
 > > 	a mismatched collection of packages in pkgsrc/packages. Could
 > > 	I suggest we set ${CPU_DIR} or similar from ${CPUFLAGS} and
 > > 	have PACKAGES as above?
 >
 > We have to be careful not to go too far. My favorite, this
 > week is, "-O2 -march=k6-2 -ffast-math -finline-functions
 > -maccumulate-outgoing-args -momit-leaf-frame-pointer".[*] The
 > only part of that that actually matters, compatibility-wise, is the
 > "-march=k6-2". Also keep in mind, that the user doesn't have to have
 > cpuflags installed to set such options, and we really don't want to
 > take chances that incompatible packages get mixed together on
 > ftp.netbsd.org. Therefore, I feel we should calculate the tag
 > in bsd.prefs.mk. Maybe something like this...?
 >
 > CPU_TAG=	${CPUFLAGS:M-march=*:S/march=//}
 > CPU_TAG+=	${CPUFLAGS:M-m680*:S/-m//}
 > CPU_TAG+=	${CPUFLAGS:M-msoft-float=*:S/-m//}
 >
 > ...and then, of course, that gets inserted in all the places I've
 > already identified in the patch.

 	Hum... don't forget at least -mcpu and -mipsX. I'm actually
 	inclined to put all the non default flags in the tag, so you
 	have an accurate record of what was used to compile the
 	package.

 -- 
 		David/absolute          -- www.netbsd.org: No hype required --
>Unformatted:

NetBSD Home
NetBSD PR Database Search

(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.