Problem beim Kompilieren
Roman Kalinowski
ich versuche gerade das Programm viewkel aus dem
Programmpaket YAeHMOP zu übersetzen.
Das Makefile habe ich nach den Angaben des READMEs
versucht anzupassen.
Unerfahren in dieser Materie habe ich dabei sicherlich
einen Fehler gemacht, denn make bricht den Vorgang
mit einer Fehlermeldung ab:
...
main.c:48: warning: return type of `main' is not `int'
make: *** [main.o] Fehler 1
(ausfühlicher weiter unten).
Google und groups.google haben ausnahmsweise nicht bei
der Lösung weitergeholfen (Fehlermeldung eingegeben).
Vielleicht ist das Fehlerbild allgemein genug, so daß
ich nicht den Autor anschreiben muß oder die wenig
frequentierte Mailingliste beanspruchen muß.
Ich würde mich freuen, wenn mich jemand auf den richtigen
Weg bringen könnte, da ich noch nicht einmal weiß, wo ich
ansetzen muß (LDFLAGS, CFLAGS,...?).
Roman
* die komplette Ausgabe von make:
test@achat:/usr/local/yaehmop/viewkel> make
cc -O -DHIGHPREC -DPARM_FILE=\"/usr/local/yaehmop/viewkel/atomic_parms.dat\"
-DX_GRAPHICS -DINTERACTIVE_USE -DINCLUDE_ADF_PLOTS -DCULL_POLYGONS
-DSUPPORT_COLOR_X -DINCLUDE_BOND_VALENCE -DSUPPORT_FATBANDS
-DCHATTY_SYMMETRY -DSUPPORT_FATBANDS -D_POSIX_SOURCE -DUSE_READLINE -c
main.c
main.c: In function `main':
main.c:77: `doing_tek' undeclared (first use in this function)
main.c:77: (Each undeclared identifier is reported only once
main.c:77: for each function it appears in.)
main.c:48: warning: return type of `main' is not `int'
make: *** [main.o] Fehler 1
test@achat:/usr/local/yaehmop/viewkel>
*die letzten Zeilen von make -d:
...
Versuche Muster-Regel mit Ersetzung »main«.
Unmögliche implizite Voraussetzung »main.w« abgelehnt.
Keine implizite Regel für »main.c« gefunden.
Fertig mit den Voraussetzungen für die Ziel-Datei »main.c«.
Es ist nicht notwendig, das Target »main.c« neu zu erzeugen..
Fertig mit den Voraussetzungen für die Ziel-Datei »main.o«.
Das Target »main.o« muß neu erzeugt werden.
cc -O -DHIGHPREC -DPARM_FILE=\"/usr/local/yaehmop/viewkel/atomic_parms.dat\"
-DX_GRAPHICS -DINTERACTIVE_USE -DINCLUDE_ADF_PLOTS -DCULL_POLYGONS
-DSUPPORT_COLOR_X -DINCLUDE_BOND_VALENCE -DSUPPORT_FATBANDS
-DCHATTY_SYMMETRY -DSUPPORT_FATBANDS -D_POSIX_SOURCE -DUSE_READLINE -c
main.c
Child Zugriff: Nutzer 504 (tatsächlich 504), Gruppe 100 (tatsächlich 100)
Nehme Kindprozess 0x08081748 (main.o) PID 2640 in die Kette auf.
Aktiver Kindprozess 0x08081748 (main.o) PID 2640
main.c: In function `main':
main.c:77: `doing_tek' undeclared (first use in this function)
main.c:77: (Each undeclared identifier is reported only once
main.c:77: for each function it appears in.)
main.c:48: warning: return type of `main' is not `int'
Erhielt Signal »SIGCHLD«; 1 unbeendete Kindprozesse.
Sammle erfolglosen Kindprozess 0x08081748 PID 2640
make: *** [main.o] Fehler 1
Entferne Kindprozeß 0x08081748 PID 2640 aus der Kette.
test@achat:/usr/local/yaehmop/viewkel>
Bernd Petrovitsch
> Hallo,
>
> ich versuche gerade das Programm viewkel aus dem Programmpaket YAeHMOP
> zu übersetzen. Das Makefile habe ich nach den Angaben des READMEs
> versucht anzupassen.
> Unerfahren in dieser Materie habe ich dabei sicherlich einen Fehler
> gemacht, denn make bricht den Vorgang mit einer Fehlermeldung ab: ...
> main.c:48: warning: return type of `main' is not `int' make: ***
> [main.o] Fehler 1
Lt. C-Standard muß die main() Funktion den Returnwert "int" haben.
Viele C-Compiler tolerieren aber "void" dort, aber der gcc ist da GsD
pingelig.
Siehe auch http://www.eskimo.com/~scs/C-faq/q11.12.html
> Ich würde mich freuen, wenn mich jemand auf den richtigen Weg bringen
> könnte, da ich noch nicht einmal weiß, wo ich ansetzen muß (LDFLAGS,
> CFLAGS,...?).
>
> Roman
>
> * die komplette Ausgabe von make:
>
> test@achat:/usr/local/yaehmop/viewkel> make cc -O -DHIGHPREC
> -DPARM_FILE=\"/usr/local/yaehmop/viewkel/atomic_parms.dat\"
> -DX_GRAPHICS -DINTERACTIVE_USE -DINCLUDE_ADF_PLOTS -DCULL_POLYGONS
> -DSUPPORT_COLOR_X -DINCLUDE_BOND_VALENCE -DSUPPORT_FATBANDS
> -DCHATTY_SYMMETRY -DSUPPORT_FATBANDS -D_POSIX_SOURCE -DUSE_READLINE -c
> main.c
> main.c: In function `main':
> main.c:77: `doing_tek' undeclared (first use in this function)
Jede verwendete Funktion sollte einen Function Prototype haben. Und
das ist mit "doing_tek" nicht passiert.
Bernd
Florian Sukup
> main.c:77: `doing_tek' undeclared (first use in this function)
Das ist der eigentliche Fehler. Nach dem musst Du suchen.
Ich koennte mir vorstellen, dass da irgendein include
File nicht richtig ist.
Ich wuerde in main.c nachsehen, ob bei der #include
directive (falls da ueberhaupt eine ist) nachsehen,
vielleicht zeigt die auf ein File, das nicht in dem
Paket enthalten ist und so wird eines genommen, das in
Deiner Umgebung anders ist, als in der, in der das
Paket entwickelt worden ist.
Ich hoffe, Dir hilft das weiter.
LG
Florian.
Thomas Ogrisegg
>> main.c: In function `main':
>> main.c:77: `doing_tek' undeclared (first use in this function)
>
> Jede verwendete Funktion sollte einen Function Prototype haben. Und
> das ist mit "doing_tek" nicht passiert.
Nein, es muss sich um eine Variable/Konstante handeln. Undeklarierte
Funktionen werden von gcc implizit (als 'int $FUNKTION(...)') behandelt.
Thomas Ogrisegg
> main.c:77: `doing_tek' undeclared (first use in this function)
> main.c:77: (Each undeclared identifier is reported only once
> main.c:77: for each function it appears in.)
> main.c:48: warning: return type of `main' is not `int'
Grundsaetzlich ist es keine gute Idee Kompilierungsprobleme ueber
das Usenet loesen. grep(1) mal nach 'doing_tek' in *.c und *.h
> Versuche Muster-Regel mit Ersetzung ?main?.
> Unm?gliche implizite Voraussetzung ?main.w? abgelehnt.
> Keine implizite Regel f?r ?main.c? gefunden.
> Fertig mit den Voraussetzungen f?r die Ziel-Datei ?main.c?.
Gott, oh Gott. 'export LANG=C'. Schnell.
Roman Kalinowski
> Ich wuerde in main.c nachsehen, ob bei der #include
> directive (falls da ueberhaupt eine ist) nachsehen,
> vielleicht zeigt die auf ein File, das nicht in dem
> Paket enthalten ist und so wird eines genommen, das in
> Deiner Umgebung anders ist, als in der, in der das
> Paket entwickelt worden ist.
Ich habe mir die Datei main.c mal angesehen.
Erstens mußte ich festellen, daß ich wirklich nichts
davon verstehe.
Zweitens, daß es schon include-Einträge gibt (#include "viewkel.h",
#include <SIOUX.h>), wobei zumindest viewkel.h mit im
Verzeichnis ist.
Und drittens, daß ziemlich häufig TEK_GRAPHICS vorkam.
Die Probleme kamen scheinbar daher, daß ich in den CFLAGS
-DTEK_GRAPHICS herausgenommen habe.
Das habe ich allerdings nicht aus Jux und Dollerei getan,
sondern, weil im Readme steht:
If you wish to get rid of Tektronix support, get rid of the
-DTEK_GRAPHICS.
Da es sich dabei,glaube ich, um ein recht altes Graphikformat handelt
habe ich mir halt gedacht, daß ich dafür keinen Support benötige.
Also eindeutig mein Fehler.
Sicherlich hätte man außer dem Entfernen dieses Flags noch die main.c
ändern müssen?
Nun scheint die Kompilierung aber geklappt zu haben.
>
> Ich hoffe, Dir hilft das weiter.
Klar, danke!
>
> LG
> Florian.
Ciao
Roman
Roman Kalinowski
> Lt. C-Standard muß die main() Funktion den Returnwert "int" haben.
> Viele C-Compiler tolerieren aber "void" dort, aber der gcc ist da GsD
> pingelig.
> Siehe auch http://www.eskimo.com/~scs/C-faq/q11.12.html
>
Es würde mir natürlich im Traum nicht einfallen,
main als void zu deklarieren :-)
(ich scheitere schon an einfachen Shellscripten, von C-Programmierung
habe ich keinen Schimmer).
Dennoch gut, daß man - bei entsprechendem Wissen - aus Fehlermeldungen
eindeutig auf das verursachende Problem schließen kann.
> Jede verwendete Funktion sollte einen Function Prototype haben. Und
> das ist mit "doing_tek" nicht passiert.
Ich war mir nicht bewußt, daß "main.c:77: `doing_tek' undeclared (first use
in this function)" mit "main.c:48: warning: return type of `main' is not
`int'" unmittelbar zusammenhängt.
Hätte mir das aber denken können und muß mich somit
entschuldigen.
Da im Readme zum Thema Anpassung der CFLAGS stand:
If you wish to get rid of Tektronix support, get rid of the -DTEK_GRAPHICS.
habe ich -DTEK_GRAPHICS aus den Flags entfernt und somit
den Fehler verursacht.
Nachdem ich -DTEK_GRAPHICS wieder hinzufügte kam der make-Prozess weiter.
Zwar kam nochmal die Warnung "main.c:48: warning: return type ..." aber
die Übersetzung ging weiter.
Es war noch ein Bibliotheksproblem zu lösen, beim anschließenden make
kam die Warnung nicht mehr.
Also ist wohl alles glatt gegangen.
> Bernd
Vielen Dank für die Hilfe.
Roman
Roman Kalinowski
> Lt. C-Standard muß die main() Funktion den Returnwert "int" haben.
> Viele C-Compiler tolerieren aber "void" dort, aber der gcc ist da GsD
> pingelig.
> Siehe auch http://www.eskimo.com/~scs/C-faq/q11.12.html
Leider habe ich mich zu früh gefreut.
Zwar hat die Übersetzung des Programmes viewkel funktioniert
(siehe andere Antwort) aber nun habe ich das gleiche (?) Problem
mit der Übersetzung der Programme in einem Unterverzeichnis
eines anderen Programmes dieses Paketes.
achat:/usr/local/yaehmop/tightbind/utils # make
cc -O -I/usr/local/include/ -c fit_walsh.c
In file included from fit_walsh.h:8,
from fit_walsh.c:11:
/usr/include/string.h:242: parse error before `('
/usr/include/string.h:242: parse error before `,'
/usr/include/string.h:245: parse error before `('
/usr/include/string.h:245: parse error before `,'
fit_walsh.c: In function `main':
fit_walsh.c:366: warning: return type of `main' is not `int'
make: *** [fit_walsh.o] Fehler 1
achat:/usr/local/yaehmop/tightbind/utils #
Da ich dort das Makefile nicht angerührt habe und es auch kein
spezielles Readme in diesem Verzeichnis gibt muß es
an der Datei fit_walsh.c liegen.
Ich habe mir den angegebenen Link angesehen und nur verstanden,
daß man bitte nicht mit Deklarierungen pfuschen soll.
Wie wende ich das auf mein neues Problem an?
Falls Du nochmal so freundlich wärst mir dabei zu helfen,
würde ich mich sehr freuen.
Roman
Hoffe, daß ich nicht auf die Schnelle C lernen muß :-)
Roman Kalinowski
> Grundsaetzlich ist es keine gute Idee Kompilierungsprobleme ueber
> das Usenet loesen. grep(1) mal nach 'doing_tek' in *.c und *.
Insbesondere, wenn man auch noch eindeutig selbst schuld ist.
(siehe andere Antworten)
>
> Gott, oh Gott. 'export LANG=C'. Schnell.
Es geht darum, daß deutsche Übersetzungen solcher Fehlermeldungen
sinnentstellend sind?
Reicht es LC_MESSAGES auf C zu stellen?
Danke für die Hinweise, obwohl mich "Gott, oh Gott" erstmal
in leichte Panik versetzt hat.
Roman
Lukas Schratz
> Thomas Ogrisegg wrote:
>
>> Gott, oh Gott. 'export LANG=C'. Schnell.
>
> Es geht darum, daß deutsche Übersetzungen solcher Fehlermeldungen
> sinnentstellend sind?
> Reicht es LC_MESSAGES auf C zu stellen?
>
> Danke für die Hinweise, obwohl mich "Gott, oh Gott" erstmal
> in leichte Panik versetzt hat.
>
Ach, nimm das nicht so ernst, TO ist nur eifersüchtig, weil du sogar in
den Fehlermeldungen korrekte Umlaute hast, er nicht einmal im
newsreader.
> Roman
SCNR
luke
--
May you do Good Magic with Perl.
-- Larry Wall's blessing
Thomas Ogrisegg
Das tut es auch nicht. Die Warnung hast Du beim zweiten Kompilieren
wahrscheinlich uebersehen.
Thomas Ogrisegg
> Ach, nimm das nicht so ernst, TO ist nur eifers?chtig, weil du sogar in
> newsreader.
Das ist mein stiller Protest gegen Localization. Irgendwer muss ja
damit anfangen.
Thomas Ogrisegg
> cc -O -I/usr/local/include/ -c fit_walsh.c
> In file included from fit_walsh.h:8,
> from fit_walsh.c:11:
> /usr/include/string.h:242: parse error before `('
Sieht nach einem Prototypeproblem aus. Was genau steht in Zeile
242 von string.h?
Michael Oswald
> Dennoch gut, daß man - bei entsprechendem Wissen - aus Fehlermeldungen
> eindeutig auf das verursachende Problem schließen kann.
Na ja, das setzt schon ein bissl Erfahrung voraus.
> Ich war mir nicht bewußt, daß "main.c:77: `doing_tek' undeclared
> (first use in this function)" mit "main.c:48: warning: return type of
> `main' is not `int'" unmittelbar zusammenhängt.
Nein, das haengt ueberhaupt nicht zusammen. Dass main kein int
returniert, ist eine warning und der gcc gibt warnings zwar aus, damit
man weiss dass da etwas nicht passt, aber defaultmaessig macht er
weiter.
Eine nicht deklarierte Funktion/Variable (doing_tek) ist ein hingegen
ein Abbruchkriterium (woher soll der Compiler wissen, was er machen
soll, wenn er nicht weiss wie doing_tek aussieht?).
> Hätte mir das aber denken können und muß mich somit
> entschuldigen.
Na na, des passt scho.
> habe ich -DTEK_GRAPHICS aus den Flags entfernt und somit
> den Fehler verursacht.
> Nachdem ich -DTEK_GRAPHICS wieder hinzufügte kam der make-Prozess
> weiter.
Da hat halt der Autor vom Source vergessen die Verwendung von diesem
doing_tek von TEK_GRAPHICS abhaengig zu machen. Kann vorkommen.
> Zwar kam nochmal die Warnung "main.c:48: warning: return type ..."
> aber die Übersetzung ging weiter.
So ists auch richtig.
> Es war noch ein Bibliotheksproblem zu lösen, beim anschließenden make
> kam die Warnung nicht mehr.
Weil er das File, das die warning verursacht hat eben schon kompiliert
hat und es nur noch ums Linken gegangen ist.
> Roman
Ossi
Roman Kalinowski
Nach dem Hinzufügen von -DTEK_GRAPHICS kam es beim anschließenden
Kompilieren ja nochmal zu "main.c:48: warning: return..." und außerdem
verlangte er noch nach der libreadline.
Es wurde also trotz der Warnung fortgefahren bis halt die neue
Fehlermeldung kam.
Als ich das gelöst hatte und ein letztes Mal kompilierte,
bin ich mir ziemlich sicher, daß "main.c:48: warning: return..." nicht
mehr vorkam.
Könnte es sein, das make immer nur dann Meldungen zeigt, wenn es
an eben dieser Stelle absolut nicht weiterkommt?
Ich habe ja auch *kein* make -d gemacht.
Aber dieses Programmpaket ist ja zum Glück fertig kompiliert.
Roman
Roman Kalinowski
> Sieht nach einem Prototypeproblem aus. Was genau steht in Zeile
> 242 von string.h?
In den betreffenden Zeilen von /usr/include/string.h steht:
239
240 #if defined __USE_BSD
241 /* Copy N bytes of SRC to DEST (like memmove, but args reversed). */
242 extern void bcopy (__const void *__src, void *__dest, size_t __n) __THROW;
243
244 /* Set N bytes of S to 0. */
245 extern void bzero (void *__s, size_t __n) __THROW;
246
Nachdem nun endlich in mein Hirn gesickert ist, daß es sich bei
den Zahlen um Zeilennummern in den verschiedenen Dateien handelt,
vielleicht gleich noch Zeile 366 von /usr/local/yaehmop/tightbind/utils/
fit_walsh.c:
364
365 void main(argc,argv)
366 int argc;
367 char **argv;
368 {
Ich habe mal die Fehlermeldung in google eingegeben und mußte feststellen,
daß ein "parse error before..." zwar häufiger vorkommt, ich aber keine
hinreichend vorgekaute Lösung erkennen konnte.
Da string.h noch zwei weitere Header verlangt, hoffe ich, daß die Fehler
dort nicht weitergehen werden nachdem der aktuelle Fehler dank Deiner
Hilfe gelöst sein wird - hoffentlich :-)
Falls Dir das gelingt, wäre das wirklich sehr schön.
Danke bis hierher
Roman
Roman Kalinowski
> Na ja, das setzt schon ein bissl Erfahrung voraus.
>
Deswegen habe ich mir eine Linux-User-Group aufgetan.
Von den vielen hilfsbereiten Menschen programmiert (mindestens)
einer auch noch gerne.
Somit habe ich bei meinem nächsten Problem einen weiteren
Ansprechpartner.
>> Ich war mir nicht bewußt, daß "main.c:77: `doing_tek' undeclared
>> (first use in this function)" mit "main.c:48: warning: return type of
>> `main' is not `int'" unmittelbar zusammenhängt.
>
> Nein, das haengt ueberhaupt nicht zusammen. Dass main kein int
> returniert, ist eine warning und der gcc gibt warnings zwar aus, damit
> man weiss dass da etwas nicht passt, aber defaultmaessig macht er
> weiter.
> Eine nicht deklarierte Funktion/Variable (doing_tek) ist ein hingegen
> ein Abbruchkriterium (woher soll der Compiler wissen, was er machen
> soll, wenn er nicht weiss wie doing_tek aussieht?).
Ich habe nur auf das "warning" geschielt und das "undeclared"
sträflicherweise für unwichtig erachtet.
Muß mir wohl mal die make-Dokumentation anschauen, wenn ich noch
viel kompilieren muß.
>> Zwar kam nochmal die Warnung "main.c:48: warning: return type ..."
>> aber die Übersetzung ging weiter.
>
> So ists auch richtig.
Also ist "main.c:48: warning: return type ..." eine Pingeligkeit des
Compilers und hat immer nur geringere Priorität (um nicht egal zu sagen)
bei der Fehlersuche?
>> Es war noch ein Bibliotheksproblem zu lösen, beim anschließenden make
>> kam die Warnung nicht mehr.
>
> Weil er das File, das die warning verursacht hat eben schon kompiliert
> hat und es nur noch ums Linken gegangen ist.
War zum Glück einfach :-)
> Ossi
Roman
Peter J. Holzer
> Thomas Ogrisegg wrote:
>
>> Die Warnung hast Du beim zweiten Kompilieren wahrscheinlich
>> uebersehen.
>
> Nach dem Hinzufügen von -DTEK_GRAPHICS kam es beim anschließenden
> Kompilieren ja nochmal zu "main.c:48: warning: return..." und außerdem
> verlangte er noch nach der libreadline.
> Es wurde also trotz der Warnung fortgefahren bis halt die neue
> Fehlermeldung kam.
> Als ich das gelöst hatte und ein letztes Mal kompilierte,
> bin ich mir ziemlich sicher, daß "main.c:48: warning: return..." nicht
> mehr vorkam.
>
> Könnte es sein, das make immer nur dann Meldungen zeigt, wenn es
> an eben dieser Stelle absolut nicht weiterkommt?
Nein, diese Meldungen kommen nicht vom make, sondern vom Compiler.
Darauf hat make überhaupt keinen Einfluss (es sei denn, der Autor des
Makefiles hat sehr blöde Spielchen mit I/O-Redirection und
verschachtelten make-Aufrufen gespielt, aber das bezweifle ich eher).
Für wahrscheinlicher halte ich es, dass Du zwischendurch nicht "make
clean"[0] aufgerufen hast, und daher das File mit der Funktion main schon
compiliert war (es produzierte ja nur eine Warnung, keinen Fehler) und
daher nicht neu compiliert werden musste - wenn es nicht compiliert
wird, gibt es aber auch keine Compilerwarnungen.
hp
[0] Es ist Konvention, in jedes Makefile ein Target "clean" einzubauen,
das alles, was durch make erzeugt wird (Object-Files, Executables, ...)
wieder löscht. Nicht alle halten sich daran.
--
_ | Peter J. Holzer | To a database person,
|_|_) | Sysadmin WSR | every nail looks like a thumb.
| | | h...@hjp.at |
__/ | http://www.hjp.at/ | -- Jamie Zawinski
Roman Kalinowski
> Für wahrscheinlicher halte ich es, dass Du zwischendurch nicht "make
> clean"[0] aufgerufen hast, und daher das File mit der Funktion main schon
> compiliert war (es produzierte ja nur eine Warnung, keinen Fehler) und
> daher nicht neu compiliert werden musste - wenn es nicht compiliert
> wird, gibt es aber auch keine Compilerwarnungen.
>
> hp
>
> [0] Es ist Konvention, in jedes Makefile ein Target "clean" einzubauen,
> das alles, was durch make erzeugt wird (Object-Files, Executables, ...)
> wieder löscht. Nicht alle halten sich daran.
>
Du hast recht.
Ich habe kein make clean zwischendurch aufgerufen.
Damit klärt sich schon mal dieser Punkt.
Danke
Roman
Thomas Ogrisegg
>> Sieht nach einem Prototypeproblem aus. Was genau steht in Zeile
>> 242 von string.h?
>
> In den betreffenden Zeilen von /usr/include/string.h steht:
>
> 239
> 240 #if defined __USE_BSD
> 241 /* Copy N bytes of SRC to DEST (like memmove, but args reversed). */
> 242 extern void bcopy (__const void *__src, void *__dest, size_t __n) __THROW;
Dann ist das Problem entweder bei "__const", oder bei "__THROW". Sieht
so als ob die internen Headerabhaengigkeiten in der glibc nicht richtig
aufgeloest werden. Du musst wohl noch irgendeine andere Headerdatei vor-
her inkludieren. Oder es ist ein "-D" Switch zu viel oder zuwenig da.
> 365 void main(argc,argv)
s/void/int/
Roman Kalinowski
YAeHMOP benötigen, meine Probleme beim kompilieren
und ihre Lösung:
*Fehler bei Übersetzung der Software unter
yaehmop/tightbind/ in der Art ".../usr/lib/
libf2c.so:undefined reference to 'MAIN__'":
Es darf wohl nicht gegen die libf2c.so gelinkt
werden, sondern es muß die libf2c.a benutzt werden
-->z.B. LOCALLIBS = -L/usr/lib -llapack -lblas /usr/lib/libf2c.a
funktioniert
*ihr meintet, wie ich (schäm!), aus den CFLAGS des makefiles
unter yaehmop/viewkel/ "-DTEK_GRAPHICS" entfernen zu müssen,
weil das README so zu verstehen war und man erhält Fehler
wie "main.c:77: `doing_tek' undeclared (first use in this function)":
"-DTEK_GRAPHICS" wieder einfügen
*man erhält bei Kompilierung in yaehmop/tightbind/utils
Fehler wie "/usr/include/string.h:242: parse error before `('":
Im Hinzufügen von "-DUSE_BZERO" an das Ende der CFLAGS
liegt die Lösung.
Ich hoffe, daß diese kleine Zusammenfassung irgend jemandem hilft.
Roman Kalinowski
Hallo Thomas,
Danke für Deine nochmaligen Bemühungen.
Die Lösungen, die Du vorschlägst sind
-so denke ich- absolut richtig.
Das Problem wurde dank Deiner und des Autors Hilfe
gelöst. Ich habe die Fehlermeldung gestern an die
Yaehmop-help mailing list gesendet und Greg Landrum,
der Autor von YAeHMOP, antwortete heute:
>Wow. I've never seen this type of error before.
>
>The problem appears to be arising because I've done a bit of trickery in my
>header file that is conflicting with some piece of trickery in your header
>files.
>
>You may be able to fix this by adding:
>-DUSE_BZERO
>to the end of the CFLAGS line of the makefile in the utils directory.
>
>If this does not help let me know and I'll try and figure something else
>out.
>
>-greg
>
>----
>greg Landrum (gregl...@earthlink.net)
>Software Carpenter/Computational Chemist
(Sah dann so aus:CFLAGS = -O -I/usr/local/include/ -DUSE_BZERO)
Danach ging bis auf einige Warnungen alles glatt.
Ich hoffe, daß dieses spezielle Crossposting mir nicht
allzu übel genommen wird.
Falls doch, entschuldige ich mich ausdrücklich.
Erst die Hilfen aus dieser Newsgroup und die von Greg
haben zum Erfolg geführt und dafür möchte ich mich nochmals
sehr bedanken, besonders bei Thomas, da Du Dich mit dem
besonders kryptischen letzten Fehler herumgeschlagen hast.
Ciao
Roman
Stephan Weinberger
> Muß mir wohl mal die make-Dokumentation anschauen, wenn ich noch
> viel kompilieren muß.
Die beschriebenen Meldungen kommen aber nicht von make sondern vom
C-Compiler :-)
> Also ist "main.c:48: warning: return type ..." eine Pingeligkeit des
> Compilers und hat immer nur geringere Priorität (um nicht egal zu sagen)
> bei der Fehlersuche?
Ja, es ist ja nur ein "warning" (sprich: 'irgendwas ist nicht ganz so wie
es sein sollte wenn es ganz schoen waere, aber ich komm' drueber hinweg')
und kein "error" (sprich: 'damit kann ich jetzt aber wirklich nix mehr
anfangen');
--
cu mail: s.wein...@xover.mud.at
Stephan www: http://xover.mud.at/invisible
The choices we make, not the chances we take, determine our destiny.