Link-Problem mit Intel Fortran Compiler
Servus ! Ich versuche nun schon einige Tage erfolglos einige Programme (mopac-7.01, gamess -> beide rechenintensive Quantenchemieprogramme) mit dem Intel Fortran Compiler zusammenzubauen. Das Compilieren läuft eigentlich problemlos durch. Das Problem tritt dann beim Linken auf: Meldung "undefined reference to `fflush_'" . Ein nm /lib/libc.so.6 |grep fflush zeigt: 000667f0 T _IO_fflush 000667f0 W fflush 0006eec0 T fflush_unlocked Das dazulinken der libc libm bringt aber leider nichts. Falls es was nützt, meine Commandozeile sieht jetzt so aus: ifc -w -C90 -posixlib -i_dynamic -common_args -L/usr/lib \ -L/opt/intel/compiler50/ia32/lib -L/lib -O [objectfiles] -o MOPAC7 -lm -lc Mit gamess habe ich ein ähnliches Problem. Woher weiss ich, welche Bibliotheken er braucht ? Ich kann doch nicht alles mit nm durchgreppen ?
Mathias Weigt wrote:
Ich versuche nun schon einige Tage erfolglos einige Programme (mopac-7.01, gamess -> beide rechenintensive Quantenchemieprogramme) mit dem Intel Fortran Compiler zusammenzubauen. Das Compilieren läuft eigentlich problemlos durch. Das Problem tritt dann beim Linken auf: Meldung "undefined reference to `fflush_'" . Ein nm /lib/libc.so.6 |grep fflush zeigt: 000667f0 T _IO_fflush 000667f0 W fflush 0006eec0 T fflush_unlocked
Das dazulinken der libc libm bringt aber leider nichts. Falls es was nützt, meine Commandozeile sieht jetzt so aus: ifc -w -C90 -posixlib -i_dynamic -common_args -L/usr/lib \ -L/opt/intel/compiler50/ia32/lib -L/lib -O [objectfiles] -o MOPAC7 -lm -lc
Mehrere Kommentare zu diesem Thema: 1. Es gibt fertige RPMS u.a. fuer Mopac. Warum verwendest Du nicht diese, dann kannst Du das Compilieren sparen?! 2. Mopac enthaelt Fortran77 Code, dafuer brauchst Du nicht unbedingt den Intel ifc (Fortran95) Compiler, das sollte auch der g77 (oder evtl. f77) schaffen. 3. Um dennoch das Programm mit dem ifc zu compilieren, ersetze im Makefile die Zeile "$(F77) -O $(OBJS) -o $@" zum Linken des Pro- grammes durch "$(F77) -O $(OBJS) -o $@ -Vaxlib", dann geht es ohne Probleme. Die restlichen von Dir angegebenen Compileroptionen scheinen mir zumindest bei Mopac nicht noetig, vorausgesetzt, Du hast ifc korrekt installiert und die Umgebungsvariablen gesetzt. 4. WICHTIG: Der ifc hat einen Bug was "flush" angeht. "flush" kann zwar in Programmen verwendet werden, es zeigt aber keine Wirkung. Intel ist ueber den Bug bereits informiert und wird (hoffentlich) bald einen Bugfix zur Verfuegung stellen! Gruesse, Th. -- Thomas Hertweck, Geophysicist Geophysical Institute, University of Karlsruhe
Am Samstag 24 November 2001 18:27 schrieb Thomas Hertweck:
Mathias Weigt wrote:
Ich versuche nun schon einige Tage erfolglos einige Programme (mopac-7.01, gamess -> beide rechenintensive Quantenchemieprogramme) mit dem Intel Fortran Compiler zusammenzubauen. Das Compilieren läuft eigentlich problemlos durch. Das Problem tritt dann beim Linken auf: Meldung "undefined reference to `fflush_'" . Ein nm /lib/libc.so.6 |grep fflush zeigt: 000667f0 T _IO_fflush 000667f0 W fflush 0006eec0 T fflush_unlocked
Das dazulinken der libc libm bringt aber leider nichts. Falls es was nützt, meine Commandozeile sieht jetzt so aus: ifc -w -C90 -posixlib -i_dynamic -common_args -L/usr/lib \ -L/opt/intel/compiler50/ia32/lib -L/lib -O [objectfiles] -o MOPAC7 -lm -lc
Mehrere Kommentare zu diesem Thema:
1. Es gibt fertige RPMS u.a. fuer Mopac. Warum verwendest Du nicht diese, dann kannst Du das Compilieren sparen?!
Ja, die gibt es und die habe ich zunächst auch verwendet. Es gibt allerdings 2 Gründe Mopac neuzucompileren: 1. Es ist auf einem AMD/DURON 900 wesentlich langsamer als auf einer SGI/R10000 -> da hab ich mir halt vom Intel Compiler was versprochen. 2. wenn man mehr (Schwer)Atome als 60 hat (was allerdings schon recht viel ist), muss man ebenfalls neu compilieren.
2. Mopac enthaelt Fortran77 Code, dafuer brauchst Du nicht unbedingt den Intel ifc (Fortran95) Compiler, das sollte auch der g77 (oder evtl. f77) schaffen.
Der g77 schafft Mopac leider nicht (jedenfalls nicht ohne Codeänderungen, zu denen ich nicht fähig bin, da ich des Fortrans leider nicht mächtig bin -> maximal noch ein wenig C(++)/Pascal). Ich hab es geschafft Mopac mit f2c / fort77 zu übersetzen (aber eben mit genannten Geschwindigkeitsnachteilen)
3. Um dennoch das Programm mit dem ifc zu compilieren, ersetze im Makefile die Zeile "$(F77) -O $(OBJS) -o $@" zum Linken des Pro- grammes durch "$(F77) -O $(OBJS) -o $@ -Vaxlib", dann geht es ohne Probleme. Die restlichen von Dir angegebenen Compileroptionen scheinen mir zumindest bei Mopac nicht noetig, vorausgesetzt, Du hast ifc korrekt installiert und die Umgebungsvariablen gesetzt.
Mhmm... Werd ich heute noch ausprobieren... Ich dachte aber -Vaxlib hätte ich auch schon ohne Erfolg verwendet.
4. WICHTIG: Der ifc hat einen Bug was "flush" angeht. "flush" kann zwar in Programmen verwendet werden, es zeigt aber keine Wirkung. Intel ist ueber den Bug bereits informiert und wird (hoffentlich) bald einen Bugfix zur Verfuegung stellen!
Heisst dass jetzt, dass selbst wenn das Programm fertig ist, es nicht funktioniert, wenn flush verwendet wird ? Und noch was: wenn es jemand schafft gaussian98 (mit irgendeinem frei erhältlichen Compiler g77 / f2c / ifc) zu übersetzen, bin ich immer an einem HOWTO interessiert.
Gruesse, Th. Vielen Dank für die ausführliche Antwort.
Mathias Weigt wrote:
Am Samstag 24 November 2001 18:27 schrieb Thomas Hertweck:
[...] 1. Es gibt fertige RPMS u.a. fuer Mopac. Warum verwendest Du nicht diese, dann kannst Du das Compilieren sparen?!
Ja, die gibt es und die habe ich zunächst auch verwendet. Es gibt allerdings 2 Gründe Mopac neuzucompileren: 1. Es ist auf einem AMD/DURON 900 wesentlich langsamer als auf einer SGI/R10000 -> da hab ich mir halt vom Intel Compiler was versprochen.
Naja, der Intel Compiler optimiert vermutlich ziemlich gut fuer einen Pentium IV (o.ae.), ich wage zu bezweifeln, dass er auch richtig gut optimierten Code fuer AMD ausspuckt :-) Habe das selbst aber noch nicht getestet. Haengt auch schwer davon ab, welche "Features" das Programm einsetzt. Wenn Nu- merik mit ins Spiel kommst, wirst Du auf der SGI sicherlich gluecklicher werden, das Phaenomen kenne ich (hier mit Ori- gin 3200, R12000, 400MHz) - ein von uns selbst geschriebenes Programm, was sehr viel Numerik betreibt, rechnet auf der SGI auf einem Proz. etwa so schnell wie auf einem AMD 900MHz Ath- lon. Die ganze Architektur ist einfach anders, vom 8MB Proz.- Cache und der Speicheranbindung mal ganz zu schweigen :-)
3. Um dennoch das Programm mit dem ifc zu compilieren, ersetze im Makefile die Zeile "$(F77) -O $(OBJS) -o $@" zum Linken des Pro- grammes durch "$(F77) -O $(OBJS) -o $@ -Vaxlib", dann geht es ohne Probleme. Die restlichen von Dir angegebenen Compileroptionen scheinen mir zumindest bei Mopac nicht noetig, vorausgesetzt, Du hast ifc korrekt installiert und die Umgebungsvariablen gesetzt.
Mhmm... Werd ich heute noch ausprobieren... Ich dachte aber -Vaxlib hätte ich auch schon ohne Erfolg verwendet.
Ich habe es ausprobiert, hier laesst sich das so einwandfrei compilieren (SuSE 7.1).
4. WICHTIG: Der ifc hat einen Bug was "flush" angeht. "flush" kann zwar in Programmen verwendet werden, es zeigt aber keine Wirkung. Intel ist ueber den Bug bereits informiert und wird (hoffentlich) bald einen Bugfix zur Verfuegung stellen!
Heisst dass jetzt, dass selbst wenn das Programm fertig ist, es nicht funktioniert, wenn flush verwendet wird ?
Das Programm funktioniert, nur der Aufruf von flush zeigt keine Wirkung. Entdeckt hat das Michael Schulz, ebenfalls hier auf der Liste, ich habe das Problem an Intel uebermittelt, die das Problem auch bestaetigt haben. Ob das ernsthafte Probleme fuer Dein Programm bereitet, weiss ich jetzt nicht, da muesste man mal einen genaueren Blick drauf werfen. Gruesse, Thomson -- Thomas Hertweck, Geophysicist Geophysical Institute, University of Karlsruhe
Am Sonntag, 25. November 2001 13:07 schrieb Thomas Hertweck:
Mathias Weigt wrote:
Am Samstag 24 November 2001 18:27 schrieb Thomas Hertweck:
[...] 1. Es gibt fertige RPMS u.a. fuer Mopac. Warum verwendest Du nicht diese, dann kannst Du das Compilieren sparen?!
Ja, die gibt es und die habe ich zunächst auch verwendet. Es gibt allerdings 2 Gründe Mopac neuzucompileren: 1. Es ist auf einem AMD/DURON 900 wesentlich langsamer als auf einer SGI/R10000 -> da hab ich mir halt vom Intel Compiler was versprochen.
Naja, der Intel Compiler optimiert vermutlich ziemlich gut fuer einen Pentium IV (o.ae.), ich wage zu bezweifeln, dass er auch richtig gut optimierten Code fuer AMD ausspuckt :-)
Laut c`t soll er auch AMD beschleunigen.
Habe das selbst aber noch nicht getestet. Haengt auch schwer davon ab, welche "Features" das Programm einsetzt. Wenn Nu- merik mit ins Spiel kommst, wirst Du auf der SGI sicherlich gluecklicher werden, das Phaenomen kenne ich (hier mit Ori- gin 3200, R12000, 400MHz) - ein von uns selbst geschriebenes Programm, was sehr viel Numerik betreibt, rechnet auf der SGI auf einem Proz. etwa so schnell wie auf einem AMD 900MHz Ath- lon. Die ganze Architektur ist einfach anders, vom 8MB Proz.- Cache und der Speicheranbindung mal ganz zu schweigen :-)
Ja, leider hab ich in der UNI nur eine Octane2 (R12000) rumstehen (sollen bald 3 werden), die auch noch den ganzen Tag interaktiv benutzt wird. Zu Hause hab ich halt "nur" einen Athlon und Quantenchemie ist ziemlich rechenintensiv. GAMESS hat bei mir für eine UHF-Rechnung eines kleineren Radikals schon mal fast 2 Tage gebraucht.
Ich habe es ausprobiert, hier laesst sich das so einwandfrei compilieren (SuSE 7.1).
Hier hab ich jetzt auch ein Binary erhalten aber es funktioniert nicht richtig. In den Outputfiles erscheinen haufenweise "?" statt Zahlen :-(
Das Programm funktioniert, nur der Aufruf von flush zeigt keine Wirkung. Entdeckt hat das Michael Schulz, ebenfalls hier auf der Liste, ich habe das Problem an Intel uebermittelt, die das Problem auch bestaetigt haben. Ob das ernsthafte Probleme fuer Dein Programm bereitet, weiss ich jetzt nicht, da muesste man mal einen genaueren Blick drauf werfen.
Keine Ahnung, was flush macht, vielleicht hat es ja was damit zu tun. Trotzdem Danke, du hast mir wirklich geholfen.
Am Sonntag 25 November 2001 13:33 schrieb Mathias Weigt:
Am Sonntag, 25. November 2001 13:07 schrieb Thomas Hertweck:
Mathias Weigt wrote:
Am Samstag 24 November 2001 18:27 schrieb Thomas Hertweck:
[...] 1. Es gibt fertige RPMS u.a. fuer Mopac. Warum verwendest Du nicht diese, dann kannst Du das Compilieren sparen?!
Ja, die gibt es und die habe ich zunächst auch verwendet. Es gibt allerdings 2 Gründe Mopac neuzucompileren: 1. Es ist auf einem AMD/DURON 900 wesentlich langsamer als auf einer SGI/R10000 -> da hab ich mir halt vom Intel Compiler was versprochen.
Naja, der Intel Compiler optimiert vermutlich ziemlich gut fuer einen Pentium IV (o.ae.), ich wage zu bezweifeln, dass er auch richtig gut optimierten Code fuer AMD ausspuckt :-)
Laut c`t soll er auch AMD beschleunigen.
Und das tut er nun auch :-) Ich habe jetzt mopac mit fort77/icc übersetzt und ohne jegliche Optimierung braucht Mopac zur AM1 Geometrieoptimierung für Vinblastin (ein ziemlich grosses Molekül, Wirkstoff gegen Krebs) nur noch die Hälfte der Zeit (16 min statt 32 min mit fort77/gcc). Das erstaunliche dabei ist allerdings, dass das Ergebnis (Heat of formation) vom icc-Compilat anscheinend richtig ist, dass von gcc aber nicht. (Ich weiss noch nicht genau, was richtig ist - jedenfalls bekommt die icc-Variante genau das gleiche raus, wie das Mopac auf der SGI) Ich vergleiche das noch mal mit dem binary RPM.
Am Son, 2001-11-25 um 14.33 schrieb Mathias Weigt:
Am Sonntag, 25. November 2001 13:07 schrieb Thomas Hertweck:
Mathias Weigt wrote:
Am Samstag 24 November 2001 18:27 schrieb Thomas Hertweck:
[...]
Das Programm funktioniert, nur der Aufruf von flush zeigt keine Wirkung. Entdeckt hat das Michael Schulz, ebenfalls hier auf der Liste, ich habe das Problem an Intel uebermittelt, die das Problem auch bestaetigt haben. Ob das ernsthafte Probleme fuer Dein Programm bereitet, weiss ich jetzt nicht, da muesste man mal einen genaueren Blick drauf werfen.
Keine Ahnung, was flush macht, vielleicht hat es ja was damit zu tun. Keine Ahnung welches flush hier gemeint ist, wenn es sich aber um die Anbindung an die libc-Funktion fflush oder an dem dem fflush unterlagerte sys-call handelt, ist das ein wirklich ernstes Problem mit potentiell fatalen Seiteneffekten. Um nicht zu sagen, es führt in einer grossen Anzahl von Programmen zur völligen Funktionsunfähigkeit (Vgl. man 3 fflush) und ist nahe daran den Compiler als völlig funktionsunfähig zu disqualifizieren.
Ralf
Ralf Corsepius wrote:
[...] Keine Ahnung welches flush hier gemeint ist, wenn es sich aber um die Anbindung an die libc-Funktion fflush oder an dem dem fflush unterlagerte sys-call handelt, ist das ein wirklich ernstes Problem mit potentiell fatalen Seiteneffekten. Um nicht zu sagen, es führt in einer grossen Anzahl von Programmen zur völligen Funktionsunfähigkeit (Vgl. man 3 fflush) und ist nahe daran den Compiler als völlig funktionsunfähig zu disqualifizieren.
Es handelt sich um die intrinsische Funktion "flush(unit)". Beispiel- programm (von Michael Schulz) zum Testen: ==================================== program flushtest character s open(UNIT=42,FILE='flushoutput.txt') write (*,*) 'file opened' read *,s write (42,*) 'test' write (*,*) 'characters written' read *,s call flush(42) write (*,*) 'output flushed' read *,s close(42) write (*,*) 'file closed' read *,s end ==================================== Nachdem "flush" aufgerufen wurde, sollte in der Datei flushoutput.txt das Wort "test" stehen, tut es aber beim Compilieren des Programmes mit ifc nicht. Erst wenn "close(42)" aufgerufen wird, wird auch in die Datei geschrieben. Ich habe das auf einer SGI und auf einer HP mit den dor- tigen Compilern probiert, und dort steht wie erwartet nach dem Aufruf von "flush" auch der Text in der Datei. Intel hat wie gesagt den Fehler bestaetigt und arbeitet daran. CU, Th. -- Thomas Hertweck, Geophysicist Geophysical Institute, University of Karlsruhe
Am Son, 2001-11-25 um 15.00 schrieb Thomas Hertweck:
Ralf Corsepius wrote:
[...] Keine Ahnung welches flush hier gemeint ist, wenn es sich aber um die Anbindung an die libc-Funktion fflush oder an dem dem fflush unterlagerte sys-call handelt, ist das ein wirklich ernstes Problem mit potentiell fatalen Seiteneffekten. Um nicht zu sagen, es führt in einer grossen Anzahl von Programmen zur völligen Funktionsunfähigkeit (Vgl. man 3 fflush) und ist nahe daran den Compiler als völlig funktionsunfähig zu disqualifizieren.
Es handelt sich um die intrinsische Funktion "flush(unit)". Beispiel- programm (von Michael Schulz) zum Testen: [..] Nachdem "flush" aufgerufen wurde, sollte in der Datei flushoutput.txt das Wort "test" stehen, tut es aber beim Compilieren des Programmes mit ifc nicht. Erst wenn "close(42)" aufgerufen wird, wird auch in die Datei geschrieben. Ich habe das auf einer SGI und auf einer HP mit den dor- tigen Compilern probiert, und dort steht wie erwartet nach dem Aufruf von "flush" auch der Text in der Datei. Intel hat wie gesagt den Fehler bestaetigt und arbeitet daran. OK, wenn mich meine FORTRAN-Kenntisse nicht im Stich lassen (Mein letztes FORTRAN-Progi liegt > 10 Jahre zurück), handelt es sich bei FLUSH um das FORTRAN-Gegenstück zum C-fflush (3).
Das bedeutet aber auch, dass praktisch kein Programm richtig funktionieren kann, das Ausgabe-Funktionen benutzt. Da die meisten klassischen FORTRAN-Programme ohnehin nur für den BATCH-Betrieb ausgelegt sind und interaktiver IO meist nur eine untergeordnete Rolle spielt (flush somit nur selten verwendetet wird), sind die Folgen auf die Funktionfähigkeit von Fortran-Programmen nicht ganz so gravierend wie in anderen Sprachen. Aber immerhin - Wäre es der C-Compiler und wäre Intel's Compiler OpenSource, wäre _das_ Grund genug _sofort_ ein BugFix-Release zu herauszubringen. Ralf
Mathias Weigt wrote:
[...] Und noch was: wenn es jemand schafft gaussian98 (mit irgendeinem frei erhältlichen Compiler g77 / f2c / ifc) zu übersetzen, bin ich immer an einem HOWTO interessiert.
Gaussian98 ist kommerziell, da kann man schlecht rumprobieren. Allerdings sollte folgender Link Dir helfen: http://quanta.synchem.kyoto-u.ac.jp/~maho/Computer/quantum_chemistry/Gaussia... Th.
Am Sonntag, 25. November 2001 13:14 schrieb Thomas Hertweck:
Mathias Weigt wrote:
[...] Und noch was: wenn es jemand schafft gaussian98 (mit irgendeinem frei erhältlichen Compiler g77 / f2c / ifc) zu übersetzen, bin ich immer an einem HOWTO interessiert.
Gaussian98 ist kommerziell, da kann man schlecht rumprobieren. Allerdings sollte folgender Link Dir helfen:
http://quanta.synchem.kyoto-u.ac.jp/~maho/Computer/quantum_chemistry/Gaussi an98_linux_ifc_e.html
Das ist ja sehr interessant :-), Danke !
Mathias Weigt schrieb am 24.11.2001 um 19:36:09 +0100: Hallo Mathias,
Ich versuche nun schon einige Tage erfolglos einige Programme (mopac-7.01, gamess -> beide rechenintensive Quantenchemieprogramme) mit dem Intel Fortran Compiler zusammenzubauen. Das Compilieren läuft eigentlich problemlos durch. Das Problem tritt dann beim Linken auf: Meldung "undefined reference to `fflush_'" . Ein nm /lib/libc.so.6 |grep fflush zeigt: 000667f0 T _IO_fflush 000667f0 W fflush 0006eec0 T fflush_unlocked
Das dazulinken der libc libm bringt aber leider nichts. Falls es was nützt, meine Commandozeile sieht jetzt so aus: ifc -w -C90 -posixlib -i_dynamic -common_args -L/usr/lib \ -L/opt/intel/compiler50/ia32/lib -L/lib -O [objectfiles] -o MOPAC7 -lm -lc
Mit gamess habe ich ein ähnliches Problem. Woher weiss ich, welche Bibliotheken er braucht ? Ich kann doch nicht alles mit nm durchgreppen ?
für flush brauchst Du -Vaxlib und nicht -posixlib. Nur der Intelcompiler hat was flush angeht ne Bug. Er schreibt nichts weg, obwohl Du flush aufrufst. Bis denne, Michael -- ---------------------------------------------------------- Michael Schulz, Institut f. Geophysik, Universität Münster Corrensstr. 24, 48149 Münster Tel.: 0251-8333938, e-mail: michael@earth.uni-muenster.de
Am Montag, 26. November 2001 08:47 schrieb Michael Schulz:
für flush brauchst Du -Vaxlib und nicht -posixlib. Nur der Intelcompiler hat was flush angeht ne Bug. Er schreibt nichts weg, obwohl Du flush aufrufst. Bis denne,
Ja deshalb stehen im Outputfile wahrscheinlich auch Fragezeichen, wo Zahlen stehen sollten... Mit f2c/icc geht es aber :-)
participants (4)
-
Mathias Weigt
-
Michael Schulz
-
Ralf Corsepius
-
Thomas Hertweck