ports/143529: [PATCH] math/py-numpy: does not build

[Gerald Pfeifer]

The following reply was made to PR ports/143529; it has been noted by GNATS.

From: Gerald Pfeifer <gerald at pfeifer.com>
To: bf1783 at gmail.com
Cc: "Li-Lun Wang (Leland Wang)" <llwang at infor.org>, bug-followup at freebsd.org, 
    amdmi3 at amdmi3.ru
Subject: Re: ports/143529: [PATCH] math/py-numpy: does not build
Date: Mon, 15 Feb 2010 21:41:17 +0100 (CET)

 On Mon, 15 Feb 2010, b. f. wrote:
 > This problem is occurring with lang/gcc44 from Ports, when
 > devel/binutils is installed, because then the latest gcc44 snapshots
 > are automatically preferring devel/binutils to the base system
 > binutils.
 
 No-no.  lang/gcc44 does not "automatically" prefer things.  I just 
 verified that.
 
 What you describe only happens when an admin _willfully_ selects
 the tools from devel/binutils over the system ones.  I assume in
 this case this happened by setting PATH accordingly, though there
 are other ways.  And of course, when someone arbitrarily replaces
 system tools by others, or even just newer versions, all sorts of
 unforeseen things can happen.
 
 
 The proposed patch to check for the version of devel/binutils is
 not correct, since it is not granted that lang/gcc44 would use that
 version of binutils.  For example, as b.f. notices, we could force
 it to use the system tools even when devel/binutils is installed.
 You may want to use '$CC -print-prog-name=as' to identify the
 version of as that GCC is using and go from there.
 
 
 That said, given the increasing problems that are arising due to
 the rotten binutils that are in the base system, I had planned to
 also have lang/gcc44 use devel/binutils for a while, after seeing
 how this pans out with lang/gcc45.  I am testing a patch to that
 end right now and plan to commit it within the next 24 hours, when
 I will also update to the latest snapshot of GCC 4.4.
 
 Still, as far as math/py-numpy goes, please do check for the
 version of binutils that is used by GCC instead of hardcoding
 things.  For example, if we later make this an OPTION, things
 could break again otherwise.
 
 Gerald