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 <>
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/
 and py-numpy in x11/py-gtk2/ (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