Newsgroup: it.comp.macintosh
Titolo: Compilare in C

Salve,
devo compilare un prg scritto in C. L'ho copiato in un file e ho scritto
gcc3 nome_file
Ottengo il msg seguente
ld: preliminaires bad magic number (not a Mach-O file).
Qualcuno puo' dirmi cosa significa?
Grazie, Nicola

 
Dimenticavo di aggiungere che "preliminaires" e' il nome del file.
Nicola

 gcc3 nome_file
gcc -o filedioutput filediinput.c
-- 
Jollino - per rispondere togli il freno a mano
http://www.chieti.ch
 - la community di Chieti e dei teatini

 wrote:

E' strano in pratica ti dice che non e' un file compilato per osx :-( Se
ti e' possibile prova a postarlo che provo anche io. Ad ogni modo la tua
procedura mi sembra corretta solo ricordati di usare il flag -o e
specificare il nome del tuo file di output. Se non specifichi il nome
gcc chiama il tuo eseguibilie a.out (un ricordo dei tempi andati) nulla
di grave ma fastidioso.
Ma il tuo gcc e' quello standard fornito da Apple ?
-- 
Ciao
Fabio

 
Ciao,
e' quello standard. Adesso ottengo
gcc3 -o preliminaires.o preliminaires.c
ld: Undefined symbols:
_main
_nrerror
Il prg l'ho trovato in un libro:
#include <math.h>
#define RAD (3.14159265/180.0)
void flmoon(int n, int nph, long *jd, float *frac)
/*Our programs begin with an introductory comment summarizing their 
purpose and\
  explaining
their calling sequence. This routine calculates the phases of the moon. 
Given a\
n integer n and
a code nph for the phase desired (nph = 0 for new moon, 1 for first 
quarter, 2 \
for full, 3 for last
quarter), the routine returns the Julian Day Number jd, and the 
fractional part\
  of a day frac
to be added to it, of the nth such phase since January, 1900. Greenwich 
Mean Ti\
me is assumed.*/
{
void nrerror(char error_text[]);
int i;
float am,as,c,t,t2,xtra;
c=n+nph/4.0;
t=c/1236.85;
t2=t*t;
as=359.2242+29.105356*c;
am=306.0253+385.816918*c+0.010730*t2;
*jd=2415020+28L*n+7L*nph;
xtra=0.75933+1.53058868*c+((1.178e-4)-(1.55e-7)*t)*t2;
if (nph == 0 || nph == 2)
xtra += (0.1734-3.93e-4*t)*sin(RAD*as)-0.4068*sin(RAD*am);
else if (nph == 1 || nph == 3)
xtra += (0.1721-4.0e-4*t)*sin(RAD*as)-0.6280*sin(RAD*am);
else nrerror("nph is unknown in flmoon");
i=(int)(xtra >= 0.0 ? floor(xtra) : ceil(xtra-1.0));
*jd += i;
*frac=xtra-i;
}

 Il prg l'ho trovato in un libro:
Manca il main!!!!!!!!
-- 
Andrea =o

> Il prg l'ho trovato in un libro:
Al di là della mancanza di main(), cosa servono i puntatori *jd e *frac? E
sopprattutto, dove sono dichiarati????
Posso chiederti una cosa, senza offesa? Ma tu sai programmare in C? No,
vero :-)???
-- 
Andrea =o

 
No. Infatti ho detto chiaramente di aver copiato il prg da un libro. 
Comunque senza questo main mi sembra di capire che questo prg (come 
tutti gli altri del libro) sia inutilizzabile. Dico bene?
Ciao, Nicola

Nicola Sottocornola wrote:

Ciao,
quello che hai copiato dal libro nn e' un programma, ma una funzione. La 
prendi e la inserisci in un tuo programma. Immagino che se l'hai copiata 
da un libro che parla di C, quel libro ti spieghera le cose dall'inizio 
("Hello World" per intenderci...). Forse e' meglio se cominci da pagina 
1 :) (senza offesa)
ciaociao
-- 
Davide

 Cosi' com'e' il codice che hai postato e' inutlizzabile
Grazie; questo volevo sapere...
Ciao, Nicola

 
La pagina era quella giusta; non il libro. Conosci qualcosa di 
introduttivo che sia disponibile gratuitamente in rete?
Meglio se c'e' un po' di matematica...
Quello che avevo trovato io e' qui
http://lib-www.lanl.gov/numerical/bookcpdf.html
Mi sembra molto interessante ma, come dicevamo, inutilizzabile.
Ciao, Nicola

 Meglio se c'e' un po' di matematica...
C'e' sempre google: secondo me se cerchi qualcosa tipo "Learning C" o "C 
tutorial" etc... trovi una mare di pagine :)
bye
-- 
Davide

 introduttivo che sia disponibile gratuitamente in rete?
Investi in un buon libro, credimi sono soldi spesi bene. Anche perchè la
sintassi del C è ricalcata da moltissimi altri linguaggi (Java, Php...)
Se vuoi te ne posso segnalare uno che ho trovato molto bello.
--
Andrea


qui trovi un buon tutorial sul C++ (con il consiglio implicito di
impararti, gia` che ci sei, il C++, piuttosto del C ;) )
-- 
#!/usr/bin/rik0
for whom the bell trolls?

 Ma il tuo gcc e' quello standard fornito da Apple ?
la cosa buffa e` quello di Apple non e` poi cosi` standard :)
ha pesanti modifiche... e purtroppo e` dannatamente vecchio :) 


 ha pesanti modifiche... e purtroppo e` dannatamente vecchio :) 
Che sia modificato me ne ero accorto, con man gcc ti compaiono meta'
delle opzioni che sono APPLE ONLY. E poi ho letto qua e la che ci hanno
lavorato parecchio per migliorare il supporto ad altivec e g5 (nel 3.3).
Pero' perche' dici che e' vecchio ? come base per le modifiche non hanno
preso la versione 3.3 (come il nome sembra suggerire) ? Se cosi' fosse
non direi che e' vecchio, l'ultima release stabile del gcc "normale" e'
la 3.3.3.
-- 
Ciao
Fabio

 la 3.3.3.
la versione 3.3 e` uscita nell'maggio 2003. 
la versione da cui e` basata quella apple e` dell 03 04 2003.
io dico che e` vecchia... e che pure e` piena di bachi.
per esempio mi e` capitato che non riesca a compilare alcuni sw in std
c++... bachi che poi paiono essere risolti...
dico proprio che e` vecchia ;)
-- 
#!/bin/rik0               | Seasons don't fear the reaper
for whom the bell trolls? | Nor do the wind, the sun or the rain
                          | (BOC)

 dico proprio che e` vecchia ;)
Bhe' dai vecchia occorre solo qualche bug fix. Solo che adesso che hanno
un compilatore per il G5 non so quanto si impegnino in un nuovo
compilatore. Tanto piu' che IBM ne ha rilasciato uno che sembra un
mostro a vedere i bench.
-- 
Ciao
Fabio

 mostro a vedere i bench.
link?


 c++
è il c++ che è sbagliato come linguaggio :P


 mostro a vedere i bench.
È naturale, me lo spiegava un amico qualche mese fa. I compilatori 
nativi sono sempre fantastici (o più che altro è gcc che a parte il 
fatto di essere portabile e gratuito/libero/blabla non è tutta sta gran 
meraviglia?), e non solo su PPC: se compili la stessa cosa per windows 
con gcc, col compilatore micro$oft e col compilatore intel.. indovina 
quale va meglio?
L'unico neo è che spesso sono compilatori commerciali.


 quale va meglio?
scherzi a parte il nuovo compilatore MS non e` affatto male. solo in
pochi campi e` piu` lento dell'intel, ma complessivamente e` piu`
standard (C++ -- o meglio, e` il piu` standard -- ). Davvero un bel
pezzo di sw


 è il c++ che è sbagliato come linguaggio :P
scusa puoi meglio precisare?
premetto che fare quello che c'e` da fare in python sarebbe impensabile.
per la stessa ragione per cui il piu` diffuso interprete python e` esso
stesso scritto in C++.
Ci sono campi dove la facilita` di utilizzo per il programmatore e` un
vantaggio. Ci sono campi dove invece nn si puo` prescindere dalla
velocita` di calcolo.


 scusa puoi meglio precisare?
miiii rico, era una battuta!


 miiii rico, era una battuta!
e' che sono suschiettibile su ste cose ;) 


 link?
http://www-306.ibm.com/software/awdtools/vacpp/features/xlcpp-mac.html
-- 
Ciao
Fabio

 
http://www-306.ibm.com/software/awdtools/vacpp/features/xlcpp-mac.html
leggo un 500 euro che mi fa cadere una nota parte anatomica
sottoterra...
e io che pensavo che magari apple ce lo avrebbe incluso in qualche
futura versione... ma direi proprio di no ;)


 velocita` di calcolo.
Si`, ma in quest'ultimi e` tutt'ora difficile battere il Fortran (per i
calcoli numerici), il C (per l'elaborazione in generale), il linguaggio
macchina (quanno ce vo', ce vo'...:-).  Non impossibile (Blitz++ docet,
e infatti viene imitato -- la miglior forma di apprezzamento -- da
alcuni moduli di SciPy), ma in pratica molto difficile.  Il C++ soffre
tutt'ora di una importante "abstraction penalty", che non _dovrebbe_
esistere, ma in pratica puo` esistere se non lo usi piu` o meno come C,
al che non e` piu` molto chiaro perche` usare un linguaggio tanto
complicato vincolandosi ad usarlo come uno tanto piu` semplice...
In molti campi, usare Python come principale linguaggio di
programmazione, facendogli pilotare nuclei computazionali fatti ciascuno
nel linguaggio piu` adatti (Fortran, C, linguaggio macchina, anche C++
se del caso, tutto fa brodo...) puo` risultare la scelta vincente.  Non
a caso fra gli utenti piu` affezionati di Python si trovano vari posti
che eseguono e sviluppano continuamente programmi ad altissima
intensita` computazionale, dall'LLNL all'Industrial Light and Magic; la
facilita` di sperimentare svariate architetture ed approcci nel tempo in
cui, in Fortran o C++, si faticherebbe a completarne anche uno, puo`
consentire macro-ottimizzazioni che ripagano ampiamente delle piccole
inefficienze "secondarie" in codice comunque fuori dai bottleneck
computazionali (magari con l'aiuto di un buon compilatore JIT, come
psyco).  Ci sono sicuramente casi in cui tutto questo non si applica,
come ad esempio i dispositivi che dispongono di quantita` estremamente
scarse di memoria -- ad esempio, l'uso di Python sui cellulari e` nuovo
e tutt'altro che pacifico (Nokia ha annunciato solo di recente il
progetto di rendere disponibile Python agli sviluppatori terze parti,
sinora lo usavano solo loro "in house", e comunque e` escluso che lo
supportino eccetto che nei cellulari "di alta fascia", cioe` appunto
quelli con piu` potenza computazionale e in particolare memoria).
Naturalmente una cosa e` la situazione attuale, diverse possono essere
le prospettive.  I compilatori C++ continuano ad evolversi per ridurre,
e un giorno senza dubbio annulleranno, la "abstraction penalty".  Nel
frattempo Python non sta fermo (pare che abbiamo ricevuto un "invito a
negoziare" dall'EU per il progetto di ricerca per il quale le abbiamo
richiesto fondi -- se va in porto, gli sviluppi dovrebbero essere molto
interessanti; google per pypy x ulteriori dettagli).  E naturalmente non
mancano coloro che si sforzano, con grandi risultati, per facilitare al
massimo l'interoperabilita` Python/C++, primo fra tutti David Abrahams,
che e` sia nel comitato di standardizzazione C++ sia l'architetto
principale di Boost Python (
www.boost.org
), ma non scordiamoci anche di
Andrew Koenig, che e` sicuramente fra i "grandi storici" del C++ e piu`
di recente si e` appassionato anche a Python.
Insomma, al netto di eventuali vincoli hardware (almeno sinche` pypy non
matura...;-), riesco a fatica a pensare a un progetto software in cui
Python non possa fruttuosamente svolgere un ruolo (quasi inevitabilmente
fianco a fianco di librerie, nuclei computazionali, ecc, sviluppati in
altri linguaggi)...
Alex

 Python non possa fruttuosamente svolgere un ruolo.
nn saprei... io so che il Python lo conoscono (nn so a che livello). e
non esiste nemmeno un frontend in Python per la libreria (al momento C
C++ OCaml Mercury e Java).


 futura versione... ma direi proprio di no ;)
Non penso non sono neanche sicuro che lo usi lei stessa per il prossimo
osx dato che ormai ha investito un po' dentro gcc, anche se a leggere
quel sito sembra totalmente compatibile con il codice prodotto dal gcc.
-- 
Ciao
Fabio

 scusa puoi meglio precisare?
E' che dovrebbe chiamarsi ++C
Hanno proprio sbagliato nome ;-)
Marco

 quel sito sembra totalmente compatibile con il codice prodotto dal gcc.
diciamo che di certo non manca la documentazione riguardo al gcc e che
IBM non manca certo di risorse... al che direi che posso fidarmi :)


 C++ OCaml Mercury e Java).
Con Swig (se la libreria e` in C), o Boost Python e l'incredibile Pyste,
per non dire di giocattolini come SIP (usato per il dialetto C++
arricchito in cui sono programmate le Qt), pyfort (per il Fortran), ecc,
ecc, si puo` praticamente automatizzare la costruzione di estensioni per
Python per qualsivoglia libreria.  Molti grosse estensioni di Python si
basano appunto su strumenti del genere (wxPython e Win32All usano SWIG,
PyQt usa SIP, ecc ecc).  Credo (non l'ho ancora studiato...) che lo
stesso valga per PyObjC se la libreria e` scritta in Objective C
(dettaglio che in pratica al giorno d'oggi conta solo su Mac, ma almeno
questo ci riporta QUASI in-topic...:-).
Alex

 interessante sul perche`, ma sarebbe molto OT qui:-)
Su icm sě, perň a me interessa. Č troppo chiederti di accennarne in mail 
o, meglio, su aff? :)
Grazie (anche se la risposta č "ma non ci penso nemmeno")


 Source (vedi sopra).
beh... gran parte dei progetti di vecchia data sono stati iniziati in C.
e gran parte dei "vecchi" si sono fatti le ossa con questo linguaggio...
poi ci sono anche le direttive di rms riguardo ai "linguaggi da usare"
(in realta` piu` che direttive era un accenno nel programma). non che in
effetti questo abbia avuto molto peso. 
anzi mi chiedo perche` il Lisp non abbia avuto la diffusione che merita.
Riguardo al Java... beh, e` molto di moda, spesso insegnato nelle
universita`... c'e` chi ne tesse le lodi. io personalmente non lo godo,
ma riconosco che ha i suoi lati positivi.


 o, meglio, su aff? :)
meglio su aff, perche` effettivamente interesserebbe pure a me :)


 meglio su aff, perche` effettivamente interesserebbe pure a me :)
mi accodo anche io :-)
-- 
Ciao
Fabio

 Grazie (anche se la risposta č "ma non ci penso nemmeno")
Ho sentito nominare + volte aff ma non so quale sia il nome completo del
gruppo.  Se qualcuno me lo dice, ci do un occhio...
Alex

 
 alt.fan.fratellibros
-- 
Speriamo che il moderatore non mi cancelli questo messaggio :-)

  alt.fan.fratellibros
Grazie, preso.  Spostero` dunque la discussione ivi, grazie,
Alex