Created attachment 171234 [details] 2.1 Attached patch updates gsl to 2.1.
math/gsl has many consumers. Did you check the update doesn't break them? According to devel/abi-compliance-checker some symbols were removed in 2.0 and SONAME was bumped in 2.1. cf. http://abi-laboratory.pro/tracker/timeline/gsl/
TBH, no. At this point I've only tested it with bogofilter.
Maintainer reset.
Created attachment 173099 [details] patch to update math/gsl, rev. 2 I tried your patch with some minor modifications on 12-CURRENT amd64 and it builds and installs fine. 'portlint -AC' also is fine. (The changes in the newer patch, rev. 2, against the older one are an obsolete patch under files, a style problem with COMMENT and a bit better sorting in pkg-plist.) Next, I tried 44 known dependencies with GSL 2.1 on Poudriere and only 8 stopped with errors [EE]. A append a list with all ports. They are marked [OK], if they build, ohterwise [EE], if errors occurred. The reasons for not building are from Poudriere log files: [OK] audio/snd [OK] benchmarks/flowgrind [OK] benchmarks/sipp [OK] biology/bcftools [OK] comms/gnuradio [OK] editors/calligra [EE]!!! graphics/amide tb_profile.c:671:33: error: no member named 'J' in 'gsl_multifit_fdfsolver' gsl_multifit_covar (solver->J, 0.0, covar); [OK] graphics/enblend [OK] graphics/inkscape [EE]!!! science/kst2 no newer version, no deps src/plugins/fits/lorentzian_unweighted/../non_linear.h:180:40: error: no member named 'J' in 'gsl_multifit_fdfsolver' gsl_multifit_covar( pSolver->J, 0.0, pMatrixCovariance ); [OK] graphics/luminance [OK] graphics/luminance-qt5 [OK] graphics/nip2 [OK] graphics/ocropus [OK] graphics/pfstmo [OK] graphics/qgis [OK] graphics/xaos [OK] lang/algol68g [OK] lang/newlisp [OK] lang/newlisp-devel [OK] mail/bogofilter [OK] math/asymptote [OK] math/dieharder [OK] math/fflas-ffpack [OK] math/giacxcas [OK] math/labplot [OK] math/libflame [OK] math/libproj4 [EE]!!! math/ocamlgsl NEW RELEASE 1.19.1 [OK] math/octave-forge-gsl [EE]!!! math/orpie deps on math/ocamgsl [EE]!!! math/p5-Math-GSL xs/BSpline_wrap.1.16.c:3277:62: error: too many arguments to function call, expected 4, have 5 result = (int)gsl_bspline_deriv_eval(arg1,arg2,arg3,arg4,arg5); [OK] math/PDL [OK] math/pspp [EE]!!! math/py-gsl NEW RELEASE 2.2.0 [EE]!!! math/qtiplot no newer version, no deps src/analysis/Fit.cpp:131:29: error: no member named 'J' in 'gsl_multifit_fdfsolver' gsl_multifit_covar (s->J, 0.0, covar); [EE]!!! math/rubygem-rb-gsl no newer version, no deps histogram.c:1245:25: error: no member named 'J' in 'gsl_multifit_fdfsolver' gsl_multifit_covar(s->J, 0.0, covar); [OK] net/ns3 [OK] science/afni [OK] science/fisicalab [OK] science/getdp [OK] science/gnudatalanguage [OK] science/py-mlpy [OK] science/step So it seems, that math/ocamlgsl and math/py-gsl should be updated. For five of the other failing ports we need patches, only math/orpie should build, after the update of math/ocamgsl.
I just added a new PR (bug #211444), which updates math/ocamlgsl to 1.19.1. This updates builds with math/gsl 2.1. Other than mentiond in comment #4, math/orpie does not build with updated math/ocamlgsl. Instead, it gives two errors: mlgsl_sf.c:261:51: error: too many arguments to function call, expected 3, have 4 SF4(ellint_D, Double_val, Double_val, Double_val, GSL_MODE_val) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~ mlgsl_sf.c:56:22: note: expanded from macro 'GSL_MODE_val' #define GSL_MODE_val Int_val ^ mlgsl_sf.c:95:43: note: expanded from macro 'SF4' ML4(gsl_sf_##name, conv1, conv2, conv3, conv4, copy_double) \ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~ ./wrappers.h:74:66: note: expanded from macro 'ML4' CAMLreturn(convr(name(conv1(arg1), conv2(arg2), conv3(arg3), conv4(arg4)))) ; } ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~ mlgsl_sf.c:261:1: error: too many arguments to function call, expected 4, have 5 SF4(ellint_D, Double_val, Double_val, Double_val, GSL_MODE_val) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mlgsl_sf.c:96:3: note: expanded from macro 'SF4' ML4_res(gsl_sf_##name##_e, conv1, conv2, conv3, conv4) ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mlgsl_sf.c:77:62: note: expanded from macro 'ML4_res' name(conv1(arg1), conv2(arg2), conv3(arg3), conv4(arg4), &res); \ ~~~~ ^~~~ /usr/local/include/gsl/gsl_sf_ellint.h:84:1: note: 'gsl_sf_ellint_D_e' declared here int gsl_sf_ellint_D_e(double phi, double k, gsl_mode_t mode, gsl_sf_result * result); ^ So, at least six ports will fail after update of math/gsl and math/ocamlgsl.
I suggest we repocopy gsl --> gsl2 first, any objects ? wen
No, I don't think a repocopy is warranted yet. Given that all nearly all our ports build against gsl2, there's no reason for a repocopy at this time.
We have 3 options with the remaining ports: 1) Fix them to build against gsl2 2) Deprecate them and then remove them from the tree 3) Repocopy gsl -> gsl1 so that those 6 ports can build against an old gsl. I'm opposed to adding a gsl2 port.
In the meantime, there's gsl-2.2.1 Changes: http://git.savannah.gnu.org/cgit/gsl.git/tree/NEWS
There's Math::GSL 0.39, which says it builds against 2.2.1
Created attachment 176025 [details] patch-to-2.2.1 Testbuilds@work
math/qtiplot has upstream @ 0.9.9.7
testbuilds for 2.2.1 are fine.
After the discuss with adamw@, now I suggest: 1 repocopy math/gsl --> math/gsl1 2 update math/gsl to 2.2.1 3 if it break some ports, change these ports' depend to math/gsl1 Any suggestions ? wen
Reporter is committer, assign accordingly. I see 46 dependents, is an exp-run worthwhile so that potential fallout can be seen (at least at build time), prior to updating the main port to 2.x? + 1 on a gsl1 port (if gsl is to move across the major version barrier), OR a new gsl2 port for 2.x versions. I would add that in addition to this, a sweeping change pointing all dependents to the 1.x port is better than switching them implicitly/automatically to 2.x. This allows those port maintainers to switch to the 2.x port at their leisure (and having QA'd it them individually). I did this with the www/py-requests 1.x -> 2.x transition which worked well.
Kurt do you want to take this PR?
wen: I agree with "no gsl2 or gsl1 port", which means: one or two of the dependent ports will break. adamw: I'm not too eager to work on this PR, it's a time sink if we try to do it perfectly. koobs: Yes, that would be the perfect way, but I'm not too invested in this port to work this in. Any other volunteers ?
For the exp-run, could you create a patch with: - math/gsl updated to 2.2.1 - math/p5-Math-GSL updated to 0.39 - math/rubygem-rb-gsl renamed to math/rubygem-gsl and updated to 2.1.0.1 - math/py-gsl updated to 2.2.0
A few patches that may be useful too: https://sources.debian.net/patches/qtiplot/0.9.8.9-15/10_adopt_to_gsl2.diff/ https://sources.debian.net/patches/orpie/1.5.2-1/gsl-fix/ https://sources.debian.net/patches/amide/1.0.5-7/gsl_2x.patch/ https://github.com/Kst-plot/kst/commit/a9d24f91057441bbd2e3ed9e7536b071121526cb I believe that with those few patches + the update of p5-Math-GSL / rubygem-gsl / py-gsl there is no need for a new port.
gsl is now at 2.3, so this patch needs an update.
Sorry, I didn't see this bug soon enough -- as gsl is now already at 2.3, and will be updated soon to 2.4, I'll close this.