NetBSD Problem Report #46191

From www@NetBSD.org  Wed Mar 14 07:42:18 2012
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id 8968C63E357
	for <gnats-bugs@gnats.NetBSD.org>; Wed, 14 Mar 2012 07:42:18 +0000 (UTC)
Message-Id: <20120314074217.D253963B946@www.NetBSD.org>
Date: Wed, 14 Mar 2012 07:42:17 +0000 (UTC)
From: joern.clausen@uni-bielefeld.de
Reply-To: joernc@gmail.com
To: gnats-bugs@NetBSD.org
Subject: math/py-numpy (and others) can't find Fortran compiler on Solaris
X-Send-Pr-Version: www-1.0

>Number:         46191
>Category:       pkg
>Synopsis:       math/py-numpy (and others) can't find Fortran compiler on Solaris
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 14 07:45:00 +0000 2012
>Closed-Date:    Sat Dec 31 05:56:40 +0000 2022
>Last-Modified:  Sat Dec 31 05:56:40 +0000 2022
>Originator:     Jörn Clausen
>Release:        
>Organization:
University of Bielefeld
>Environment:
>Description:
math/py-numpy currently does not build for me on Solaris 10 using lang/gcc34:

building library "npymath" sources
customize GnuFCompiler
Could not locate executable f77
Could not locate executable g77
Traceback (most recent call last):
  File "setup.py", line 187, in <module>
    setup_package()

This used to work a few weeks ago, probably after the last change to math/py-numpy itself. I still use Python 2.6 and haven't switched to 2.7 yet, if that's of interest.

I have checked PRs 44130, 40663 and 44626, but they didn't give me any ideas how to fix this problem. f2c is installed, btw.
>How-To-Repeat:

>Fix:

>Release-Note:

>Audit-Trail:
From: =?ISO-8859-1?Q?J=F6rn_Clausen?= <joern.clausen@uni-bielefeld.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46191: math/py-numpy can't find Fortran compiler on Solaris
Date: Thu, 15 Mar 2012 08:32:56 +0100

 math/fftw now fails with

 configure: error: cannot compile a simple Fortran program

 after again not finding any suitable compiler. f2c is still present and 
 is not detected.

 This seems to be a more general problem. Either someone should rename 
 this PR, or I can open another one.

 -- 
   Jörn Clausen                             joern.clausen@uni-bielefeld.de
   Hochschulrechenzentrum                 http://www.uni-bielefeld.de/hrz/
   Universität Bielefeld

From: David Holland <dholland-pbugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46191: math/py-numpy (and others) can't find Fortran
 compiler on Solaris
Date: Sat, 17 Mar 2012 12:21:20 +0000

 On Thu, Mar 15, 2012 at 07:35:02AM +0000, J?rn Clausen wrote:
  >  math/fftw now fails with
  >  
  >  configure: error: cannot compile a simple Fortran program
  >  
  >  after again not finding any suitable compiler. f2c is still present and 
  >  is not detected.
  >  
  >  This seems to be a more general problem. Either someone should rename 
  >  this PR, or I can open another one.

 I don't see another one so far, so I updated the Synopsis:.

 Anyhow: have you tried recompiling libtool-base? It can cause this
 kind of trouble.

 -- 
 David A. Holland
 dholland@netbsd.org

From: =?ISO-8859-1?Q?J=F6rn_Clausen?= <joern.clausen@uni-bielefeld.de>
To: gnats-bugs@NetBSD.org
Cc: David Holland <dholland-pbugs@NetBSD.org>, pkg-manager@NetBSD.org,
 gnats-admin@NetBSD.org, pkgsrc-bugs@NetBSD.org
Subject: Re: pkg/46191: math/py-numpy (and others) can't find Fortran compiler
 on Solaris
Date: Mon, 19 Mar 2012 09:53:04 +0100

 On 17.03.12 13:25, David Holland wrote:
 >   I don't see another one so far, so I updated the Synopsis:.
 >
 >   Anyhow: have you tried recompiling libtool-base? It can cause this
 >   kind of trouble.

 The "problem" is that I am still using lang/gcc34, which does not come 
 with a Fortran compiler. I guess lang/gcc46 provides g77, so all those 
 who have switched to gcc46 don't see this problem.

 After reverting the change made in revision 1.113 of mk/compiler/gcc.mk, 
 math/py-numpy compiles again - but still claims, that no Fortran 
 compiler can be found. But this is consistent with my build on NetBSD 
 5.1, where GCC 4.1.3 does not provide g77 either, but f2c is also not 
 used. math/py-numpy decides just to cope with the fact that no Fortran 
 compiler is available. math/fftw uses f2c again and builds successfully.

 If I understand revsion 1.113 of mk/compiler/gcc.mk correctly, the 
 assumption is, that if you use pkgsrc's GCC, you don't need another 
 Fortran compiler, because GCC provides one. This is not true, unless 
 support for all but the very recent GCCs is dropped. Please revert that 
 change.

 -- 
   Jörn Clausen                             joern.clausen@uni-bielefeld.de
   Hochschulrechenzentrum                 http://www.uni-bielefeld.de/hrz/
   Universität Bielefeld

From: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: pkg/46191
Date: Tue, 20 Mar 2012 16:16:01 +0100

 It looks like lang/gcc34 accidentally lost the support for fortran back
 in 2005 with lang/gcc34/Makefile r1.21. I believe that the changes of
 BUILD_F77 and BUILD_JAVA were unintentional, and so mk/compiler/gcc.mk
 still believes that gcc34 supports fortran, just as all other gccs in
 pkgsrc do.

 Could you please try building with BUILD_F77=YES in lang/gcc34/Makefile?


 At the time when we decide whether another fortran compiler is needed, we
 should actually also check LANGUAGES.gcc. And ideally we would also
 change this to check the PKG_OPTIONS used for the selected gcc.

 Other than that, lang/gcc34 etc. could use some serious cleanup.



 -- 
 %SYSTEM-F-ANARCHISM, The operating system has been overthrown

From: =?ISO-8859-1?Q?J=F6rn_Clausen?= <joern.clausen@uni-bielefeld.de>
To: gnats-bugs@NetBSD.org
Cc: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>, pkg-manager@NetBSD.org,
 gnats-admin@NetBSD.org, pkgsrc-bugs@NetBSD.org
Subject: Re: pkg/46191
Date: Wed, 21 Mar 2012 11:33:27 +0100

 >   Could you please try building with BUILD_F77=YES in lang/gcc34/Makefile?

 I will try that. It could take some days, though, before I have results.

 >   Other than that, lang/gcc34 etc. could use some serious cleanup.

 Please announce any larger (and longer) changes. So far I have not 
 managed to update lang/gcc34 in place. I have to completely bootstrap 
 and rebuild my collection from scratch, when the compiler is updated.

 -- 
   Jörn Clausen                             joern.clausen@uni-bielefeld.de
   Hochschulrechenzentrum                 http://www.uni-bielefeld.de/hrz/
   Universität Bielefeld

From: =?ISO-8859-1?Q?J=F6rn_Clausen?= <joern.clausen@uni-bielefeld.de>
To: gnats-bugs@NetBSD.org
Cc: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>, pkg-manager@NetBSD.org,
 gnats-admin@NetBSD.org, pkgsrc-bugs@NetBSD.org
Subject: Re: pkg/46191
Date: Wed, 21 Mar 2012 15:25:26 +0100

 As I was just reminded of the upcoming freeze: Fixing all the old GCCs 
 won't be an easy task, reverting gcc.mk is. To have a consistent setup I 
 again propose to revert change 1.113 and bring it back once all relevant 
 GCCs provide a Fortran compiler.

 -- 
   Jörn Clausen                             joern.clausen@uni-bielefeld.de
   Hochschulrechenzentrum                 http://www.uni-bielefeld.de/hrz/
   Universität Bielefeld

From: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46191
Date: Wed, 21 Mar 2012 15:40:39 +0100

 Only lang/gcc34 is affected, and fixing it should be a simple matter of
 changing BUILD_F77=NO to BUILD_F77=YES in its Makefile. Lang/gcc,
 lang/gcc3-f77 and the lang/gcc4X packages already build a fortran
 compiler.

 I think we could still revert mk/compiler/gcc.mk in the freeze with
 approval from whoever is responsible if your test shows that it is
 really necessary.


 -- 
 %SYSTEM-F-ANARCHISM, The operating system has been overthrown

From: =?ISO-8859-1?Q?J=F6rn_Clausen?= <joern.clausen@uni-bielefeld.de>
To: gnats-bugs@NetBSD.org
Cc: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>, pkg-manager@NetBSD.org,
 gnats-admin@NetBSD.org, pkgsrc-bugs@NetBSD.org
Subject: Re: pkg/46191
Date: Wed, 21 Mar 2012 16:47:11 +0100

 >   Could you please try building with BUILD_F77=YES in lang/gcc34/Makefile?

 Building lang/gcc with BUILD_F77=YES succeeds, and I end up with a g77 
 that seems to do something:

 $ g77 --version
 GNU Fortran (GCC) 3.4.6

 and I can compile a simple "hello world" program.

 Building math/fftw... First problem:

 ...
 checking for i386-sun-solaris2.10-g77... f77
 checking whether we are using the GNU Fortran 77 compiler... no
 checking whether f77 accepts -g... no
 ...

 In fact, there is no "f77". I think in the f2c case, a wrapper was 
 created in work/.compiler/bin, but not this time. For the time being, I 
 added a symlink f77->g77 and tried again.

 Now compilation fails at

 libtool: link: cc -shared -Wl,-z -Wl,text -Wl,-h -Wl,libfftw3.so.3 -o 
 .libs/libfftw3.so.3.3.1  -Wl,-z -Wl,allextract kernel/.libs/libkernel.a 
 dft/.libs/libdft.a dft/scalar/.libs/libdft_scalar.a 
 dft/scalar/codelets/.libs/libdft_scalar_codelets.a rdft/.libs/librdft.a 
 rdft/sc
 alar/.libs/librdft_scalar.a rdft/scalar/r2cf/.libs/librdft_scalar_r2cf.a 
 rdft/scalar/r2cb/.libs/librdft_scalar_r2cb.a 
 rdft/scalar/r2r/.libs/librdft_scalar_r2r.a reodft/.libs/libreodft.a 
 api/.libs/libapi.a simd-support/.libs/libsimd_support.a 
 simd-support/.libs/libsimd_sse2
 _nonportable.a -Wl,-z -Wl,defaultextract 
 -L/pkgsrc/source/pkgsrc/math/fftw/work.pkgsrc-i86/.buildlink/lib -lm 
 -Wl,-R/pkgsrc/gcc34f77/lib
 Text relocation remains                         referenced
      against symbol                  offset      in file
 <unknown>                           0x26 
 kernel/.libs/libkernel.a(alloc.o)
 <unknown>                           0x30 
 kernel/.libs/libkernel.a(alloc.o)
 <unknown>                           0x1d 
 kernel/.libs/libkernel.a(assert.o)
 dotile                              0x3cd 
 kernel/.libs/libkernel.a(cpy2d.o)
 dotile_buf                          0x44e 
 kernel/.libs/libkernel.a(cpy2d.o)

 As far as I can tell, no Fortran sources were used up to this point, so 
 this is probably an unrelated problem.

 BTW: The change of 1.113 in mk/compiler/gcc.mk is probably unnecessary 
 anyway, as line 535ff checks for the existence of g77 anyway. So even by 
 reverting 1.113, I was not able to force the use of f2c and check if the 
 package would build.

 -- 
   Jörn Clausen                             joern.clausen@uni-bielefeld.de
   Hochschulrechenzentrum                 http://www.uni-bielefeld.de/hrz/
   Universität Bielefeld

From: =?ISO-8859-1?Q?J=F6rn_Clausen?= <joern.clausen@uni-bielefeld.de>
To: gnats-bugs@NetBSD.org
Cc: pkg-manager@NetBSD.org, gnats-admin@NetBSD.org, pkgsrc-bugs@NetBSD.org
Subject: Re: pkg/46191
Date: Wed, 21 Mar 2012 17:12:47 +0100

 >   libtool: link: cc -shared

 Dammit! I forgot to remove the remains of the Sun Studio bootstrap 
 compiler from mk.conf. After fixing that and rebuilding libtool, 
 math/fftw compiled successfully.

 I will also check math/py-numpy, but that will take some more time, as 
 it has far more dependencies.

 BTW: I didn't notice lang/gcc3-f77 before. Should I have used that 
 package from the start? Or has it been obsolete long since?

 -- 
   Jörn Clausen                             joern.clausen@uni-bielefeld.de
   Hochschulrechenzentrum                 http://www.uni-bielefeld.de/hrz/
   Universität Bielefeld

From: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: pkg/46191
Date: Wed, 21 Mar 2012 17:33:35 +0100

 On Wed, Mar 21, 2012 at 04:47:11PM +0100, Jörn Clausen wrote:
 > Building lang/gcc with BUILD_F77=YES succeeds, and I end up with a g77 
 > that seems to do something:
 > 
 > $ g77 --version
 > GNU Fortran (GCC) 3.4.6
 > 
 > and I can compile a simple "hello world" program.
 > 
 > Building math/fftw... First problem:
 > 
 > ...
 > checking for i386-sun-solaris2.10-g77... f77
 > checking whether we are using the GNU Fortran 77 compiler... no
 > checking whether f77 accepts -g... no
 > ...
 > 
 > In fact, there is no "f77". I think in the f2c case, a wrapper was 
 > created in work/.compiler/bin, but not this time. For the time being, I 
 > added a symlink f77->g77 and tried again.

 There is no f77 binary in the gcc34 package, but mk/compiler/gcc.mk
 sets creates it in .gcc/bin, and a wrapper is also created.

 > Now compilation fails at
 > 
 > libtool: link: cc -shared -Wl,-z -Wl,text -Wl,-h -Wl,libfftw3.so.3 -o 
 > .libs/libfftw3.so.3.3.1  -Wl,-z -Wl,allextract kernel/.libs/libkernel.a 
 > dft/.libs/libdft.a dft/scalar/.libs/libdft_scalar.a 
 > dft/scalar/codelets/.libs/libdft_scalar_codelets.a rdft/.libs/librdft.a 
 > rdft/sc
 > alar/.libs/librdft_scalar.a rdft/scalar/r2cf/.libs/librdft_scalar_r2cf.a 
 > rdft/scalar/r2cb/.libs/librdft_scalar_r2cb.a 
 > rdft/scalar/r2r/.libs/librdft_scalar_r2r.a reodft/.libs/libreodft.a 
 > api/.libs/libapi.a simd-support/.libs/libsimd_support.a 
 > simd-support/.libs/libsimd_sse2
 > _nonportable.a -Wl,-z -Wl,defaultextract 
 > -L/pkgsrc/source/pkgsrc/math/fftw/work.pkgsrc-i86/.buildlink/lib -lm 
 > -Wl,-R/pkgsrc/gcc34f77/lib
 > Text relocation remains                         referenced
 >     against symbol                  offset      in file
 > <unknown>                           0x26 
 > kernel/.libs/libkernel.a(alloc.o)
 > <unknown>                           0x30 
 > kernel/.libs/libkernel.a(alloc.o)
 > <unknown>                           0x1d 
 > kernel/.libs/libkernel.a(assert.o)
 > dotile                              0x3cd 
 > kernel/.libs/libkernel.a(cpy2d.o)
 > dotile_buf                          0x44e 
 > kernel/.libs/libkernel.a(cpy2d.o)
 > 
 > As far as I can tell, no Fortran sources were used up to this point, so 
 > this is probably an unrelated problem.

 I just compiled math/fftw with lang/gcc34 without any problems, but I
 manually rebuilt devel/libtool-base before that and removed lang/gcc46
 and all packages depending on it.

 > BTW: The change of 1.113 in mk/compiler/gcc.mk is probably unnecessary 
 > anyway, as line 535ff checks for the existence of g77 anyway. So even by 
 > reverting 1.113, I was not able to force the use of f2c and check if the 
 > package would build.

 It is not unnecessary. It makes sure that you don't have to have
 lang/gcc34 (or any other gcc package) installed to use it for fortran.
 Without that change, everything is ok as long as the selected gcc is
 already installed. But if it isn't installed, another dependency on a
 different fortran compiler (f2c or g95) is added, which isn't necessary
 and can cause problems of its own. I found this when doing bulk builds,
 which checks all the dependencies before anything is built.


 -- 
 %SYSTEM-F-ANARCHISM, The operating system has been overthrown

From: =?ISO-8859-1?Q?J=F6rn_Clausen?= <joern.clausen@uni-bielefeld.de>
To: gnats-bugs@NetBSD.org
Cc: Hans Rosenfeld <rosenfeld@grumpf.hope-2000.org>, pkg-manager@NetBSD.org,
 gnats-admin@NetBSD.org, pkgsrc-bugs@NetBSD.org
Subject: Re: pkg/46191
Date: Thu, 22 Mar 2012 08:46:12 +0100

 >   There is no f77 binary in the gcc34 package, but mk/compiler/gcc.mk
 >   sets creates it in .gcc/bin, and a wrapper is also created.

 No, it isn't. There was one created when f2c was used, but when using 
 GCC's g77, no wrapper "f77" is generated.

 And build of math/py-numpy fails with

 gcc: numpy/linalg/lapack_litemodule.c
 /pkgsrc/source/pkgsrc/math/py-numpy/work.pkgsrc-i86/.wrapper/bin/f77 -g 
 -Wall -L/pkgsrc/gcc34f77/gcc34/lib/gcc/i386-pc-solaris2.10/3.4.6 
 -Wl,-R/pkgsrc/gcc34f77/gcc34/lib/gcc/i386-pc-solaris2.10/3.4.6 
 -L/pkgsrc/gcc34f77/gcc34/lib -Wl,-R/pkgsrc/gcc34f77/gcc34/lib 
 -L/pkgsrc/gcc34f77/gcc34/lib/gcc/i386-pc-solaris2.10/3.4.6/ 
 -Wl,-R/pkgsrc/gcc34f77/gcc34/lib/gcc/i386-pc-solaris2.10/3.4.6/ 
 -L/usr/lib -Wl,-R/usr/lib -L/pkgsrc/gcc34f77/lib 
 -Wl,-R/pkgsrc/gcc34f77/lib 
 build/temp.solaris-2.10-i86pc-2.6/numpy/linalg/lapack_litemodule.o 
 build/temp.solaris-2.10-i86pc-2.6/numpy/linalg/python_xerbla.o 
 -L/pkgsrc/gcc34f77/lib 
 -L/pkgsrc/gcc34f77/gcc34/lib/gcc/i386-pc-solaris2.10/3.4.6 
 -L/pkgsrc/gcc34f77/lib -Lbuild/temp.solaris-2.10-i86pc-2.6 -llapack 
 -lblas -lpython2.6 -lg2c -o 
 build/lib.solaris-2.10-i86pc-2.6/numpy/linalg/lapack_lite.so
 Undefined                       first referenced
   symbol                             in file
 main 
 /pkgsrc/gcc34f77/gcc34/lib/gcc/i386-pc-solaris2.10/3.4.6/crt1.o
 ld: fatal: Symbol referencing errors. No output written to 
 build/lib.solaris-2.10-i86pc-2.6/numpy/linalg/lapack_lite.so
 collect2: ld returned 1 exit status

 -- 
   Jörn Clausen                             joern.clausen@uni-bielefeld.de
   Hochschulrechenzentrum                 http://www.uni-bielefeld.de/hrz/
   Universität Bielefeld

State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 25 Nov 2018 22:54:06 +0000
State-Changed-Why:
Is this still an issue with today's fortran widgetry?


State-Changed-From-To: feedback->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sat, 31 Dec 2022 05:56:40 +0000
State-Changed-Why:
Assume that changes to fortran handling have either fixed this or
broken it differently. If it's still failing please file a new PR,
or if it seems appropriate we can reopen this one.


>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: gnats-precook-prs,v 1.4 2018/12/21 14:20:20 maya Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2017 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.