"Error: Type mismatch" durante installazione

Fedora Linux Programmi
#1

Buongiorno a tutti,

Spero che questa sia la sezione corretta dove chiedere.
Sto cercando d’installare delft3d, ma sono arrivata a un punto in cui ottengo quest’errore e non capisco come venirne a capo… Qualcuno ha qualche suggerimento?
Grazie mille!

/bin/sh ../../../../../libtool  --tag=FC   --mode=compile gfortran   -DWITH_DELFTONLINE -O2 -ffree-line-length-none -cpp -c -o multi_file_io.lo  multi_file_io.f90
libtool: compile:  gfortran -DWITH_DELFTONLINE -O2 -ffree-line-length-none -cpp -c multi_file_io.f90  -fPIC -o .libs/multi_file_io.o
multi_file_io.f90:93:43:

   91 |            res = CUTIL_MF_READ(fptr,strout,savepos)        ! pass the starting position of read back to the caller
      |                                           2
   92 |         else
   93 |            res = CUTIL_MF_READ(fptr,strout,lastpos)        ! disregard starting position of read
      |                                           1
Error: Type mismatch between actual argument at (1) and actual argument at (2) (INTEGER(4)/INTEGER(8)).
#2

Ma a chiedere sul forum di Delft3D hai provato?

#3

Essendo arrivata a quest’errore nel make ds-install dopo diversi altri che erano legati a percorsi non impostati o comunque risolti trovando risposta nei forum, avevo pensato che anche questo fosse riconducibile a qualche mia mancanza su fedora. Proverò lì

#4

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

#5

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
#6

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.

#7

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.

#8

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?

#9

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…

#10

@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?

#11

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.

#12

Grazie mille per l’aiuto, segnalo il problema e nel caso di risposta vi aggiornerò!

#13

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.

#14

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
Problema con gnome-control-center ed inkscape
#15

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?

#16

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 :slight_smile:

#17

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.

#18

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…

#19

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? :smiley:

#20

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.