NetBSD Problem Report #48961

From dholland@macaran.localdomain  Wed Jul  2 20:33:14 2014
Return-Path: <dholland@macaran.localdomain>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id CB8C1A5D59
	for <gnats-bugs@gnats.NetBSD.org>; Wed,  2 Jul 2014 20:33:13 +0000 (UTC)
Message-Id: <20140702203613.25FBA6E25B@macaran.localdomain>
Date: Wed,  2 Jul 2014 16:36:13 -0400 (EDT)
From: dholland@eecs.harvard.edu
Reply-To: dholland@eecs.harvard.edu
To: gnats-bugs@NetBSD.org
Subject: make update from lang/g95 breaks blas, lapack, numpy, etc.
X-Send-Pr-Version: 3.95

>Number:         48961
>Category:       pkg
>Synopsis:       make update from lang/g95 breaks blas, lapack, numpy, etc.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jul 02 20:35:00 +0000 2014
>Closed-Date:    Sat Jul 09 17:28:18 +0000 2016
>Last-Modified:  Sat Jul 09 17:28:18 +0000 2016
>Originator:     David A. Holland
>Release:        NetBSD 6.99.23 (pkgsrc 20140701)
>Organization:
>Environment:
System: NetBSD macaran 6.99.23 NetBSD 6.99.23 (MACARAN) #19: Wed Sep 11 20:37:54 EDT 2013 dholland@macaran:/usr/src/sys/arch/amd64/compile/MACARAN amd64
Architecture: x86_64
Machine: amd64
>Description:

If you do 'make update' from lang/g95, blas fails to build; it tries
to use g77 instead of g95 and that doesn't exist. However, if you go
and build it by hand with 'make clean; make' in math/blas, it builds
and installs fine.

Then if you resume the update the same thing happens for lapack, and
then again for numpy, except in the case of numpy it only fails after
compiling for a long time, which is aggravating.

>How-To-Repeat:

as above

>Fix:

dunno
(Why is a build triggered by 'make update' different anyway?)

>Release-Note:

>Audit-Trail:
From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/48961: make update from lang/g95 breaks blas, lapack, numpy,
 etc.
Date: Sun, 27 Jul 2014 05:33:45 +0000

 On Wed, Jul 02, 2014 at 08:35:00PM +0000, dholland@eecs.harvard.edu wrote:
  > If you do 'make update' from lang/g95, blas fails to build; it tries
  > to use g77 instead of g95 and that doesn't exist. However, if you go
  > and build it by hand with 'make clean; make' in math/blas, it builds
  > and installs fine.
  > 
  > Then if you resume the update the same thing happens for lapack, and
  > then again for numpy, except in the case of numpy it only fails after
  > compiling for a long time, which is aggravating.

 48983 may be related.

 -- 
 David A. Holland
 dholland@netbsd.org

State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Mon, 13 Oct 2014 05:03:24 +0000
State-Changed-Why:
Since 48983 is fixed, I need to test this again.


State-Changed-From-To: feedback->open
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Wed, 21 Jan 2015 17:51:11 +0000
State-Changed-Why:
It is not fixed. Furthermore, testing it revealed PR 49594, which is a
regression, quite likely caused by the same libtool update. sigh :(


From: David Holland <dholland@eecs.harvard.edu>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/48961 (make update from lang/g95 breaks blas, lapack, numpy, etc.)
Date: Thu, 22 Jan 2015 16:28:34 -0500

 On Wed, Jan 21, 2015 at 05:51:11PM +0000, dholland@NetBSD.org wrote:
  > Synopsis: make update from lang/g95 breaks blas, lapack, numpy, etc.
  > 
  > State-Changed-From-To: feedback->open
  > State-Changed-By: dholland@NetBSD.org
  > State-Changed-When: Wed, 21 Jan 2015 17:51:11 +0000
  > State-Changed-Why:
  > It is not fixed. Furthermore, testing it revealed PR 49594, which is a
  > regression, quite likely caused by the same libtool update. sigh :(

 PR 49594 is no longer relevant. However, this problem still occurs.

 It seems to be that when building via make update, g95 isn't found.
 Diffing work directories that did and did not configure properly
 reveals the following bits of interest. (The various *makevars files
 all have the same diff.)

 I'm sure this is because the make update is *from* lang/g95; but so
 far I don't have any idea why.

 --- work.failed/.depends	2015-01-22 16:20:13.000000000 -0500
 +++ work/.depends	2015-01-22 16:20:23.000000000 -0500
 @@ -1,3 +1,4 @@
  bootstrap	digest>=20010302	../../pkgtools/digest
  tool	libtool-base>=2.2.6bnb3	../../devel/libtool-base
  build	libtool-fortran>=2.2.6bnb3	../../devel/libtool-fortran
 +full	g95>=0.91	../../lang/g95
 Exit 1
 --- work.failed/.extract_makevars.mk	2015-01-22 16:20:14.000000000 -0500
 +++ work/.extract_makevars.mk	2015-01-22 16:20:23.000000000 -0500
 @@ -1,14 +1,17 @@
  .if !defined(_MAKEVARS_MK)
  _MAKEVARS_MK=	defined

 +BUILDLINK_PREFIX.g95=	/usr/pkg
  TOOLS_DEPENDS.ghostscript=	ghostscript>=6.01:../../print/ghostscript
  TOOLS_PREFIX.digest=	/usr/pkg
  _BLNK_PHYSICAL_PATH.LOCALBASE=	/usr/pkg
  _BLNK_PHYSICAL_PATH.WRKDIR=	/usr/pkgsrc/math/blas/work
 +_BLNK_PKG_DBDIR.g95=	/var/db/pkg/g95-0.93nb6
 +_G95BASE=	/usr/pkg
  _IGNORE_INFO_PATH=	
  _MANCOMPRESSED=	no
  _MANZ=	no
  _USE_TOOLS=	[ awk basename cat chgrp chmod chown cmp cp cut date diff digest dirname echo egrep env expr false file find ftp grep gzcat head hostname id install ln ls mkdir mv patch printf pwd readelf rm rmdir sed sh sort tail tar test touch tr true uname wc xargs
 -_WRAP_PATH=	/usr/pkgsrc/math/blas/work/.buildlink/bin:/usr/pkgsrc/math/blas/work/.gcc/bin:/usr/pkgsrc/math/blas/work/.tools/bin:/usr/pkg/bin:/usr/local/sbin:/usr/local/bin:/usr/pkg/sbin:/usr/pkg/bin:/usr/X11R7/bin:/usr/sbin:/usr/bin:/sbin:/bin
 +_WRAP_PATH=	/usr/pkgsrc/math/blas/work/.buildlink/bin:/usr/pkgsrc/math/blas/work/.g95/bin:/usr/pkgsrc/math/blas/work/.gcc/bin:/usr/pkgsrc/math/blas/work/.tools/bin:/usr/pkg/bin:/usr/local/sbin:/usr/local/bin:/usr/pkg/sbin:/usr/pkg/bin:/usr/X11R7/bin:/usr/sbin:/usr/bin:/sbin:/bin

  .endif # _MAKEVARS_MK



 -- 
    - David A. Holland / dholland@eecs.harvard.edu

From: David Holland <dholland@eecs.harvard.edu>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/48961 (make update from lang/g95 breaks blas, lapack, numpy, etc.)
Date: Thu, 22 Jan 2015 19:02:09 -0500

 On Thu, Jan 22, 2015 at 10:30:01PM +0000, David Holland wrote:
  >  It seems to be that when building via make update, g95 isn't found.
  >  Diffing work directories that did and did not configure properly
  >  reveals the following bits of interest. (The various *makevars files
  >  all have the same diff.)
  >  
  >  I'm sure this is because the make update is *from* lang/g95; but so
  >  far I don't have any idea why.

 Now I do. The problem is this clause at the beginning of g95.mk:

 .if !empty(PKGPATH:Mlang/g95) || !empty(PKGPATH:Mdevel/patch) || \
     !empty(PKGPATH:Mdevel/libtool-base)
 IGNORE_G95=	yes
 MAKEFLAGS+=	IGNORE_G95=yes
 .endif

 make update passes MAKEFLAGS when building depending packages, so
 IGNORE_G95 gets passed along and messes up their builds.

 I suppose it needs to be in MAKEFLAGS when building depends to avoid
 potential cycles; but does anything G95 depends on use FORTRAN? My
 guess would be no and that it's therefore not needed...

 -- 
    - David A. Holland / dholland@eecs.harvard.edu

From: Joerg Sonnenberger <joerg@britannica.bec.de>
To: gnats-bugs@NetBSD.org
Cc: pkg-manager@netbsd.org, gnats-admin@netbsd.org, pkgsrc-bugs@netbsd.org,
	dholland@eecs.harvard.edu
Subject: Re: pkg/48961 (make update from lang/g95 breaks blas, lapack, numpy,
 etc.)
Date: Fri, 23 Jan 2015 12:47:09 +0100

 On Fri, Jan 23, 2015 at 12:05:00AM +0000, David Holland wrote:
 >  Now I do. The problem is this clause at the beginning of g95.mk:
 >  
 >  .if !empty(PKGPATH:Mlang/g95) || !empty(PKGPATH:Mdevel/patch) || \
 >      !empty(PKGPATH:Mdevel/libtool-base)
 >  IGNORE_G95=	yes
 >  MAKEFLAGS+=	IGNORE_G95=yes
 >  .endif
 >  
 >  make update passes MAKEFLAGS when building depending packages, so
 >  IGNORE_G95 gets passed along and messes up their builds.
 >  
 >  I suppose it needs to be in MAKEFLAGS when building depends to avoid
 >  potential cycles; but does anything G95 depends on use FORTRAN? My
 >  guess would be no and that it's therefore not needed...

 Does this logic have any point? The libtool-base part should be
 obsolete, devel/patch is normally not used and doesn't have a dependency
 cycle either. So the question just remains if lang/g95 needs the special
 handling -- it certainly doesn't need need to be recursive though.

 Joerg

From: "David A. Holland" <dholland@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/48961 CVS commit: pkgsrc/mk/compiler
Date: Sat, 9 Jul 2016 17:12:22 +0000

 Module Name:	pkgsrc
 Committed By:	dholland
 Date:		Sat Jul  9 17:12:22 UTC 2016

 Modified Files:
 	pkgsrc/mk/compiler: g95.mk

 Log Message:
 Remove obsolete anti-cycle logic; fixes PR 48961.


 To generate a diff of this commit:
 cvs rdiff -u -r1.5 -r1.6 pkgsrc/mk/compiler/g95.mk

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: open->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 09 Jul 2016 17:28:18 +0000
State-Changed-Why:
fixed


>Unformatted:

Home	PR Database Search