Può essere tutto. Ma si tratta di compilare un programma in Fortran (giusto). Ci sta che Fedora non abbia le librerie necessarie, o che siano troppo nuove, o che vada installato qualcosa. Ma pur non essendo un programmatore, a occhio è un problema di codice, appunto perché, magari il compilatore su Fedora è troppo nuovo? Bo.
Quel che dicevo, IMHO, è che hai più speranze sul forum del software stesso, visto anche che mi pare un un software di nicchia (per lo meno, io è la prima volta che ne sento parlare).
Questo vorrà dire qualcosa?
Da https://oss.deltares.nl/web/delft3d/source-code#prerequisites
Required software:
…
GNU Fortran compiler 4.9.1
…
Do not use GNU Fortran compiler 8.x.x or newer
E su Fedora troviamo
dnf info gcc-gfortran
...
Available Packages
Name : gcc-gfortran
Version : 10.1.1
Da un punto di vista programmatorio andrebbero viste le differenze tra il GNU Fortran 4.9.1 e la versione 10.1.1. Io installerei il compilatore Fortran sulla tua distribuzione Linux cercando di risolvere i problemi che verrebbero segnalati durante la compilazione. In pratica hai un programma scritto usando un vecchio standard del linguaggio che deve essere aggiornato. Non vedo difficoltà insormontabili.
Riguardando meglio l’errore si vede che è generato dal fatto che una variabile intera è un intero che potremmo rendere in C come int, mentre l’altra è l’equivalente di una long, entrambe passate a l’equivalente di una funzione che si aspetta un parametro d’entrata che presumo sia un int. Lo dico da programmatore in C/C++, non in Fortran.
Grazie mille ad entrambi per le risposte. Se ho capito bene potrei provare ad installare la versione 4.9.1, ma dovrei rimuovere quella 10.1.1?
Nada. Puoi installare solo l’ultima versione del compilatore GCC con il front-end per il Fortran sotto Linux. Il problema nel tuo programma, come ho scritto nel mio precedente post, è dovuto al fatto che qualcuno, non te, si è dimenticato della differenza tra due variabili passate ad una funzione. Una variabile, savepos, è indicata nel programma come INTEGER(8), mentre lastpos è INTEGER(4). Se tu esaminassi il prototipo della funzione CUTIL_MF_READ, dovresti vedere l’ultimo parametro indicato, penso, come INTEGER(8). Se la mia diagnosi è corretta dovresti modificare lastpos come INTEGER(8). Potresti segnalare il problema anche ai creatori del programma. Non so se l’hanno corretto…
@d68qdq8dq giusto per parlare (la programmazione non è il mio forte), potrebbe anche essere che la versione 4 del compilatore era più lasca nella gestione delle variabili, mentre la versione 10 ha regole più stringenti?
Non lo so, io uso abitualmente GCC con C++, il front-end per il Fortran non lo mai usato, ne ho mai scritto programmi con quel linguaggio, ma qui il problema non è il compilatore, ma il codice sorgente. Rimane il fatto che hai due variabili, entrambi intere, ma con lunghezza differente, una lunga 4 l’altra 8, che vengono passate ad una funzione che si aspetta un parametro intero lunga 8, da quello che ho capito, dovrei vedere il codice. Per farti un esempio in C/C++ il numero 255, un char, in esadecimale è equivalente ad un $FF. Un intero a 16 bit? $FFFF. Quanto vale in decimale? 65535. Vabè, andrebbe considerato con o senza segno… E allora $FFFFFFFF? Siamo sui 4 miliardi. Questo è un errore che si può risolvere in un attimo con un editor: carichi il sorgente incriminato, cerchi la linea interessata, vedi come sono i parametri della funzione CUTIL_MF_READ e modifichi una delle variabili in modo corretto e compili. Tutto qui.
Grazie mille per l’aiuto, segnalo il problema e nel caso di risposta vi aggiornerò!
Fa venire voglia di mettere mano al codice sorgente… Tra le tante cose che farei ci sarebbe il passaggio da Automake a CMake, aggiornare i requisiti e tante altre cose. P.s: il titolo di questa discussione, a ben pensarci, andrebbe cambiato da " [“Error: Type mismatch” durante installazione]" a " [“Error: Type mismatch” durante la compilazione]" perchè tutto nasce dalla compilazione del codice sorgente, non dalla sua installazione.
Puoi usare un ambiente separato con toolbox e utilizzare i binari già pronti di gfortran:
wget https://gfortran.meteodat.ch/download/x86_64/releases/gcc-4.9.4.tar.xz
sudo dnf install toolbox
toolbox create -c delft3d
toolbox enter -c delft3d
sudo tar Jxf gcc-4.9.4.tar.xz -C /usr --strip-components=1
In questo ambiente puoi accedere ai file della tua home, ma tutte le modifiche fatte al resto del sistema (programmi installati ecc.) non hanno effetto sulla tua Fedora (si tratta di un container eseguito con podman nel quale viene montata la tua home). Vedrai quindi che i tuoi soliti programmi non sono presenti.
A questo punto dovresti poter compilare e installare il tuo programma retrò.
Il mio suggerimento è quello di scrivere uno script o delle note per tenere traccia dei passaggi che hai fatto per crearti questo ambiente separato. Una volta fatto ciò potresti addirittura scrivere un Dockerfile pronto all’uso contenente il solo delft3d. Potresti avere qualche problema se il programma è grafico, ma si può rimediare.
2 Mi Piace
Caro frafra, il programma delft3d, è un programma grafico, possiede una UI. Da quello che ho capito si basa su Matlab o fa uso di qualche suo componente. Una delle cose che non capisco è perchè consiglino di fare uso di software non aggiornato, è assurdo. Mi fa venire proprio voglia di metter mano al codice sorgente. Da quel che ho capito fanno ancora uso di Automake. Non sarebbe meglio CMake?
automake è un software supportato, non ci vedo nulla di male a utilizzarlo.
Il problema della compilazione sarebbe da risolvere applicando una bella patch. Non conosco Fortran, ma probabilmente un type casting o una definizione diversa di quella variabile risolverebbe il problema.
In generale, per programmi non pacchettizzati che richiedono una installazione a livello di sistema, preferisco creare un ambiente separato o assicurarmi che non vadano a sovrascrivere file in giro. Oppure si crea un bel pacchettino e se è possibile lo si mette su copr e in seguito lo si propone per essere incluso nei repository Fedora magari 
Ora che ci penso decomprimere così potrebbe sovrascriverti alcune librerie di base… L’alternativa se ci fossero problemi sarebbe scompattare i binari in un posto a parte, cambiare PATH e impostare LD_PRELOAD solo quando esegui il programma compilato col vecchio GCC. Forse anche qualche altra variabile di ambiente sarà da impostare per fare sì che il giusto compilatore venga usato.
Mi sa che finisco per scaricare il codice sorgente di questo programma dal suo sito, capire come farlo compilare sulla nostra Fedora Linux 31 o 32 e decidere poi cosa farne delle modifiche apportate. Non credo che nils abbia nulla da obiettare. Dopotutto quale pazzo si metterebbe a portare KDevelop 3.5.5 su Qt5 visto che l’attuale versione ha una UI che contravviene alle linee guida di KDE? Bè, aggiungiamoci anche Calligra Suite e DigiKam alla lista…
Noto che bisogna registrarsi per accedere al codice sorgente… Cosa mi vieta di ripubblicarlo dato che è rilasciato sotto GPL? C’è ancora gente che utilizza subversion? E’ un software abbandonato vero? 
Grazie mille, procedo immediatamente col provare questa soluzione!
Per quanto riguarda il software, assolutamente nulla da obbiettare ;). Non è abbandonato, ma è il pacchetto base, poi volendo ci sarebbe la suite, a pagamento.
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-mismatchto 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? 
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:
- applicare le ultime patch al codice sorgente
wget (url indicato nel file INSTALL)
patch -N -Z -p1 < allpatches - configurare con
./configure --prefix=/directory/a/tua/scelta --disable-assert --disable-static - 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.