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