Bug 246888
| Summary: | catch Mk/Uses/fortran.mk up to bsd.gcc.mk r301878 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Mark Linimon <linimon> | ||||||
| Component: | Ports Framework | Assignee: | Port Management Team <portmgr> | ||||||
| Status: | Closed DUPLICATE | ||||||||
| Severity: | Affects Only Me | CC: | fortran, gerald, ports-bugs, rene, rhurlin, thierry, tijl | ||||||
| Priority: | --- | ||||||||
| Version: | Latest | ||||||||
| Hardware: | Any | ||||||||
| OS: | Any | ||||||||
| Attachments: |
|
||||||||
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 *** |
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.