|Summary:||catch Mk/Uses/fortran.mk up to bsd.gcc.mk r301878|
|Product:||Ports & Packages||Reporter:||Mark Linimon <linimon>|
|Component:||Ports Framework||Assignee:||Mark Linimon <linimon>|
|Severity:||Affects Only Me||CC:||fortran, gerald, ports-bugs, rhurlin, thierry, tijl|
Description Mark Linimon 2020-05-31 04:36:40 UTC
Created attachment 215088 [details] patch to Mk/Uses/fortran.mk In order to test 246700, fortran.mk needs to catch up to changes long-ago made to bsd.gcc.mk. The general problem is that bsd.gcc.mk cannot handle the idea of "gccX-devel", as bsd.gcc.mk was taught to. This is the second part of a multipart patch. They need to be carefully examined. However, this part should be merely a refactoring.
Comment 1 Mark Linimon 2020-05-31 21:29:03 UTC
This doesn't work yet. Back to the drawing board.
Comment 2 Gerald Pfeifer 2020-05-31 21:46:12 UTC
(In reply to Mark Linimon from comment #0) > In order to test 246700, fortran.mk needs to catch up to changes > long-ago made to bsd.gcc.mk. > > The general problem is that bsd.gcc.mk cannot handle the idea of "gccX-devel", > as bsd.gcc.mk was taught to. First, thanks for catching this, Mark! Second, I was going to use this for an -exp run for the update to GCC 10 before GCC 10.1 was released and hence lang/gcc10 created. In the meantime GCC 10.1 is out and I suggest that I focus on getting the lang/gcc10 port in place quickly (= tomorrow) and we can then use that for the -exp run. If I am right, this means this present issue goes away and we can close this report - and save you time and us code duplication in Uses/fortran.mk? Makes sense? Agreed?
Comment 3 Mark Linimon 2020-05-31 21:58:05 UTC
(In reply to Gerald Pfeifer from comment #2) > If I am right, this means this present issue goes away Well, the present _blocker_ goes away. OTOH the fact that the code in fortran.mk lags so badly behind the code in bsd.gcc.mk will remain a latent bug. IMHO it's worth me spending a bit more time on it. But that shouldn't block _your_ further work.
Comment 4 Gerald Pfeifer 2020-05-31 22:23:09 UTC
(In reply to Mark Linimon from comment #3) > OTOH the fact that the code in fortran.mk lags so badly behind the code > in bsd.gcc.mk will remain a latent bug. IMHO it's worth me spending a bit > more time on it. But that shouldn't block _your_ further work. Thank you for doing that, Mark! The one aspect you can ignore is support for gcc10-devel -- that aspect in bsd.gcc.mk was only meant for testing. That's why it's not documented and not meant for general use.
Comment 5 Mark Linimon 2020-06-01 01:33:32 UTC
Created attachment 215117 [details] patch to Mk/Uses/fortran.mk Replacement for first patch
Comment 6 Mark Linimon 2020-06-01 02:58:44 UTC
Good news and bad news: - I can confirm that with my refreshed patches, it is now possible to attempt to build net/openmpi - net/openmpi actually fails deep in the build. It is *possible* that this is due to a regression in gfortran10. The only way to find out is to feed a larger number of ports into it. (I had been using net/openmpi as my smoke-test "just because".)
Comment 7 Tijl Coosemans 2020-06-01 15:10:34 UTC
I think it would be better to make it possible to set GCC_DEFAULT to "9-devel". Then the patch doesn't have to treat 10 as a special case.
Comment 8 Mark Linimon 2020-06-03 10:24:28 UTC
This patch needs more work. It works for almost all ports but fails for a few, specifically, net/openmpi with: openblas-0.3.9_2,1 depends on executable: gfortran - not found Note the missing prefix. I am reassigning it to myself in the meantime. It should not be allowed to hold up the gcc10 regression testing.
Comment 9 Mark Linimon 2020-06-03 10:25:06 UTC
We shouldn't even have this as a selection. Bah.