"Error: Type mismatch" durante installazione

Salve nils,
non so se hai risolto ma la soluzione in realtà è molto semplice. Come ha fatto notare alciregi poc’anzi, l’attuale versione del compilatore fortran è la 10.1.1 e in effetti la release 10 di gcc/gfortran ha introdotto un controllo più stretto sul tipo di variabili passate come argomento. Puoi trovare una breve spiegazione nelle release notes di GCC 10 sul sito GNU:

Mismatches between actual and dummy argument lists in a single file are now rejected with an error. Use the new option -fallow-argument-mismatch to turn these errors into warnings.

La soluzione è proprio quella indicata: l’opzione del compilatore -fallow-argument-mismatch dovrebbe permetterti di compilare il delft3d.
Io ho avuto un problema analogo con la chiamata a una routine delle librerie MPICH che di fatto accetta come argomento un puntatore di tipo non specificato (cosa possibile con lo standard Fortran 2008). La routine in questo caso può essere chiamata più volte da uno stesso programma passando argomenti di tipo diverso, ma il nuovo GNU fortran adesso lo segnala come errore.

3 Mi Piace

Salve Colucix,
grazie mille per quest’indicazione: effettivamente mi ha permesso di procedere oltre!

Ho risolto alcuni errori nel mezzo, ma, sfortunatamente, l’ultimo trovato è, per me, più ostico da bypassare:

checking for gfortran option to support OpenMP... -fopenmp
checking for dummy main to link with Fortran libraries... unknown
configure: error: in '<path>':
configure: error: linking to Fortran libraries from C fails
See 'config.log' for more details

Andando a cercare nel config.log, ho trovato:

configure:13646: gfortran -o conftest -O2 -fopenmp   conftest.f  >&5
configure:13646: $? = 0
configure:13660: result: -fopenmp
configure:13677: checking for dummy main to link with Fortran libraries
configure:13711: <path>/compile gcc -o conftest -O2   conftest.c   -L/usr/lib/gcc/x86_64-redhat-linux/10 -L/usr/lib/gcc/x86_64-redhat-linux/10/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/10/../../.. -lgfortran -lm -lquadmath >&5
/usr/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.9.4/cc1: error while loading shared libraries: libmpfr.so.4: cannot open shared object file: No such file or directory

Ho cercato la libmpfr.so.4, ma è installata la libmpfr.so.6 con mpfr-4.0.2-3.fc32.x86_64.

Esiste qualche modo per aggirare quest’altro problema? :sweat:

Qui in effetti si tratta di compilare un codice che poggia su release meno recenti di programmi e librerie varie, rispetto a quelle che hai disponibili in Fedora 32. Forse a questo punto la soluzione più corretta è quella suggerita da frafra di utilizzare un container come toolbox dove ci si può sbizzarrire a installare tutto quello che occorre senza contaminare il sistema principale.

Tuttavia se questo fosse davvero l’ultimo ostacolo da superare, potresti provare a compilare la release precedente delle librerie mpfr installandole in una directory a parte, ad esempio in /usr/local o /opt/mpfr-3.1.6. La release che ti occorre è proprio la 3.1.6 che si può scaricare dal sito ufficiale (mi spiace ma sono un nuovo utente e non posso postare il link diretto) e che era anche la versione installata in Fedora 31.
Seguendo le varie indicazioni per l’installazione, comprese quelle degli sviluppatori di Fedora che puoi trovare sul sito del Fedora buildsystem (koji), gli step sono:

  1. applicare le ultime patch al codice sorgente
    wget (url indicato nel file INSTALL)
    patch -N -Z -p1 < allpatches
  2. configurare con
    ./configure --prefix=/directory/a/tua/scelta --disable-assert --disable-static
  3. compilazione, check, installazione con i canonici
    make
    make check
    make install

Poi con le dovute variabili d’ambiente o flag di configure, informi il delft3d dove trovare le librerie condivise appena installate, ovvero la libmpfr.so.4 richiesta.