[C] ricompilare C da HP-UX a Linux

[MyBloodyV.]

devo ricompilare del codice C su una macchina con le seguenti caratteristiche:
Macchina
Red Hat Enterprise Linux Server release 6.7 (Santiago)
kernel-2.6.32-504.el6.x86_64
kernel-2.6.32-573.3.1.el6.x86_64

Compilatore
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16)


prima ero su HP-UX


nel makefile trovo comandi tipo


CFLAGS = -g +DD64 +z -c -D_HPUX_SOURCE

LDFLAGS = +DD64


che non funzionano


li ho sostituiti e la compilazione avviene ma poi l'eseguibile da un core


qualcuno ha idee a riguardo?
un tutorial che spieghi bene come passare da uno script (intendo nel makefile) all'altro?


Grazie

[MItaly]

Le opzioni specificate nel Makefile originali sono

• -g compila con i simboli di debug; è identica su gcc;
• +DD64 compila a 64 bit su IA64; se la macchina su cui stai compilando ora è a 64 bit non dovrebbe essere necessario fare nulla di particolare (anche se x86_64 è molto diverso da IA64);
• +z indica di generare codice indipendente dalla posizione; su gcc è -fPIC;
• -D_HPUX_SOURCE è una macro che indica a diversi header standard che si intendono usare estensioni specifiche HP-UX (un po' come _GNU_SOURCE con glibc); di questa ovviamente non esiste un rimpiazzo.

Il fatto che dia un core dump non è una buona notizia, e dubito sia questione di Makefile - o il codice originale funzionava "per caso" (dangling pointers, variabili non inizializzate e similari), e il rimestare le acque (passando addirittura ad un'architettura diversa) ha esposto dei bug latenti, oppure sfruttava appositamente degli "HP-UXismi" non garantiti da POSIX e che non valgono su Linux. per questo purtroppo temo che l'unica sia fare girare il codice sotto gdb, andare a rintracciare dove si rompe e aggiustare man mano.

[MyBloodyV.]

Grazie, ora non posso dare un occhio bene per il confronto, se ho delle ulteriori domande specifiche le faccio lunedì o martedì, grazie ancora

[MyBloodyV.]

dunque: grazie ancora

guardando in giro sui forum, avevo trasformato "-g +DD64 +z -c -D_HPUX_SOURCE" in "-g -fPIC"

+DD64 +z mi dava proprio errore, quando lo utilizzavo

e poi​

LDFLAGS = +DD64 -L$(MQ_HOME)/lib64 -lmqic_r $(SQL_LD_DIR2)libsql11.a $(SQL_LD_DIR2)libclntsh.so $(SQL_LD_DIR2)libclntsh.so.11.1 -lpthread

in

LDFLAGS = -fPIC -shared $(SQL_LD_DIR2)libsql11.a $(SQL_LD_DIR2)libclntsh.so $(SQL_LD_DIR2)libclntsh.so.11.1 -lpthread

rileggendo non capisco perché ho tolto -L$(MQ_HOME)/lib64 -lmqic_r , boh

vabbeh scrivo i 2 file che faccio prima, alla fine in 2 messaggi nuovi

ho provato a analizzare il core con GDB ma mi pare venga fuori poco o nulla, il backtrace non dice niente, per me non parte proprio l'eseguibile generato

grazie

[MyBloodyV.]

li ho allegati (questa sera ho qualche problemino con il forum :-))

[MyBloodyV.]

il core che ottengo, se provo a fare il backtrace, mi dice poco


Program received signal SIGSEGV, Segmentation fault.
0x0000000000000001 in ?? ()
(gdb) bt
#0 0x0000000000000001 in ?? ()
#1 0x00007fffffffe38d in ?? ()
#2 0x0000000000000000 in ?? ()


ricordo che di solito dava una serie di frame analizzabili


se anche metto un breakpoint sul main, parte e mi da l'errore

[MItaly]

Ad occhio ti direi che c'è lo stack completamente sfasciato, difficile che quello stack trace dica alcunché di utile.

Riguardo al breakpoint, ma nel senso che non arriva nemmeno alla prima istruzione del main senza crashare?

[MyBloodyV.]

esatto, mi pare non arrivi alla prima istruzione, immagino sia compilato male l'eseguibile (che cmq viene creato)

ho lasciato un po' questi giorni, per altro, domani magari riprendo

grazie

[MyBloodyV.]

LDFLAGS = -shared -L$(MQ_HOME)/lib64 -lmqic_r $(SQL_LD_DIR2)libsql11.a $(SQL_LD_DIR2)libclntsh.so $(SQL_LD_DIR2)libclntsh.so.11.1 -lpthread


l'opzione "-shared" di preciso cosa fa?
se la metto, compila e poi genera il core illeggibile


se non la metto trovo una serie di
...undefined reference to `ltoa'
... undefined reference to `fqdh_load_table'


e poi


collect2: ld returned 1 exit status
make: *** ... Error 1


grazie