pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: gcc and libtool-fortran



Chuck Cranor <chuck%ece.cmu.edu@localhost> writes:

> [tale of woe with gcc12 and gcc13]

> but building lang/gcc14 works (at least the fortran compiler it
> generates can build a simple fortran 'hello world').
>
> I had thought that building and installing lang/gcc14 would cause
> the libtool-fortran build to pick up the newer gcc14, but it is
> still trying to build gcc12 instead.
>
> I think the connection to gcc12 in is mk/compiler/gfortran.mk
> where it has:
>
> # Choose gcc12 for Darwin/aarch64.  \todo Explain why.
> # gcc7 does not build on Darwin 12.6.x, so match aarch64.
> .if ${MACHINE_PLATFORM:MDarwin-*-*}
> POSSIBLE_GFORTRAN_VERSION=      12
> .endif
>
> and later it does:
>
> # If the POSSIBLE version exists in pkgsrc, use it.
> # Otherwise, pick gcc 10 as a mainstream default.
> .if exists(${PKGSRCDIR}/lang/gcc${POSSIBLE_GFORTRAN_VERSION}/buildlink3.mk)
> GFORTRAN_VERSION?=              ${POSSIBLE_GFORTRAN_VERSION}
> .else
> GFORTRAN_VERSION?=              10
> .endif
>
> which isn't really the semantics you want?   I was hoping it
> would see that i've installed lang/gcc14 which is newer than
> the lang/gcc12 set by POSSIBLE_GFORTRAN_VERSION and try to use 
> the newer gcc14.

We have multiple styles in pkgsrc

  A) configure which version is wanted, and use it

  B) among acceptable, look for what's installed, and act like it has been configured.

I have come to prefer, at least mildly, style A, as being more predictable.

So what is there is the semantics I want, and while I've been editing
gfortran.mk, style A there is not new.

> setting GFORTRAN_VERSION=14 in etc/mk.conf does get libtool-fortran
> to build using gcc14, but it seems like a fairly tricky thing
> to figure out?

Yes, but there are really multiple things going on here, and if they
were ok, you wouldn't have noticed:

  gcc12 doesn't build on your system, despite having been the preferred
  version on earlier macs.  Really it would be nice to fix this.

  (The mac fortran version comments were massaged from things I didn't
  100% understand.)

  The selection logic intends to match gfortran version to the gcc
  version, because that seems obviously the right thing  to do, but you
  are using clang normally, I think, so that doesn't apply.  Not a bug,
  but perhaps why this hasn't appeared more broadly.

  Perhaps clang systems should use flang, and that should be supported,
  so that you'd have used flang matching the clang version instead.

  Given that gcc12 is troubled on some macOS versions, maybe we should
  just be switching macOS fortran to 14.  I suspect that fortran is
  straightforward and that gcc12 and gcc14 behave pretty much the same
  if they build (but tell me if that's wrong).  But I don't know if
  gcc14 is going to fail where 12 succeeds, on older macOS versions, or
  x86-64, etc.


Home | Main Index | Thread Index | Old Index