pkgsrc-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/48023: pkgsrc/math/lapack build failure 2013Q2 + NetBSD/i3866.1
The following reply was made to PR pkg/48023; it has been noted by GNATS.
From: Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: mark%ecs.vuw.ac.nz@localhost, pkg-manager%netbsd.org@localhost,
gnats-admin%netbsd.org@localhost,
pkgsrc-bugs%netbsd.org@localhost, tsutsui%ceres.dti.ne.jp@localhost
Subject: Re: pkg/48023: pkgsrc/math/lapack build failure 2013Q2 + NetBSD/i3866.1
Date: Tue, 9 Jul 2013 21:30:42 +0900
markd@ wrote:
> On Sunday 07 July 2013 21:40:22 Izumi Tsutsui wrote:
> > Nonaka says his patch just "restores" the stack pointer on
> > returning from main and the ABI doesn't matter with the issue.
>
> While I can't comment on the ABI issues, I will note that the segfaults
> are in running lapack's test programs. If you skip running them you can
> successfully install the package and there doesn't seem to be issues with
> its actual use - at least in the dependent packages that I build.
If the problem is in the test programs, skipping it may be fine.
But the suggested patch in PR/47906 fixes a source in lang/g95
so all binaries compiled by g95 won't work correctly and
I don't think it's a good idea to leave g95 package broken
and default even in the stable branch.
It looks there are following choice for g95 issue:
(1) fix g95 properly
(2) apply a workaround patch in PR/47906
(3) disable g95 and switch to f2c
but it also seems:
(1) no one is working on it
(2) blocked by "this is wrong" comment without alternative suggestion
(3) some developers say "there was a wrong dicision but any effort to
change that is blocked"
On the other hand, most users just want working binaries of
SDL (which has dependency of pulseaudio -> libsamplerate -> fftw)
and ibus (which has py-gtk2 -> py-numpy) etc., and few packages
users want fortran support.
There are only ~70 packages that have USE_LANGUAGES=fortran lines
and actually ignoring failures of g95 test programs doesn't cause
any visible issue to use other major binaries.
So I'd simply suggest to disable fftw-fortran in math/fftw/options.mk
and py-numpy in x11/py-gtk2/options.mk (and make all other possible
fortran dependency optional) by default so that most users can
happily ignore annoying "this is wrong/correct" dispute and
actual motivated fortran users who explicitly enable those options
will handle the issue.
---
Izumi Tsutsui
Home |
Main Index |
Thread Index |
Old Index