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.
This doesn't work yet. Back to the drawing board.
(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?
(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.
(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.
Created attachment 215117 [details] patch to Mk/Uses/fortran.mk Replacement for first patch
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".)
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.
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.
We shouldn't even have this as a selection. Bah.
reset PR
*** This bug has been marked as a duplicate of bug 246887 ***