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
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.