Archiv verlassen und diese Seite im Standarddesign anzeigen : GCC 2.95.2 (define-Anweisung wird als Funktion interpretiert)
Ich habe ein kleines Problem mit obiger GCC Version.
Eine Funktion soll über verschiedene #define Anweisungen mit unterschiedlichen "Funktions" - Namen aufgerufen werden. Die eigentliche Funktione ist immer die Gleiche.
Doch nun scheint es so, als würde GCC die #define Anweisung als Funktions-Namen interpretieren.
Kleines Beispiel:
#define Funktion1(i) MeineFunktion(i,0,1)
#define Funktion2(i) MeineFunktion(i,1,0)
void MeineFunktion( int i1, int i2, int i3)
{
...
}
Beim Linken wird nun jedes mal bemängelt, das die Funktion "Funktion1" und "Funktion2" nicht definiert ist. Kann ja auch nicht, da es sich ja eigentlich um "MeineFunktion" handelt.
Weiß jemand woran dies liegen könnte, oder ob dies ein Bug in GCC 2.95.2 ist?!
Robert
Bernhard Koschnick
13.02.00, 01:11
Hallo Robert
Interessant, was bei Linux möglich ist (oder sogar auch in der Dunkelzone?). Ich hätte da Verständnis-Probleme. Der Linker sucht nach einer Define-Anweisung und findet sie in einem Modul des gleichen Quelltextes, daß er ja eigentlich erst im Anschluss an die # defines auswertet. Enorm.
- Solche Beiträge sind einfach lecker. Da flutscht das Lernen doch viel, viel schneller. Aber es kommt ja allmählich in die Gänge. Es braucht halt auch eine gewisse Anzahl User, die sich damit befassen.
Gruss
Bernhard
P.S. Du suchst nach Hilfe, und die User wissen nichts besseres zu tun, als von Dir zu lernen. Grässliche verkehrte Welt. http://www.linuxforen.de/ubb/wink.gif http://www.linuxforen.de/ubb/biggrin.gif http://www.linuxforen.de/ubb/biggrin.gif http://www.linuxforen.de/ubb/biggrin.gif
Hagen von Tronje
13.02.00, 10:08
Hi,
> Interessant, was bei Linux möglich ist
Noe Du Bernhard,
das ist plain C, und hat (vorerst) mit Linux gar nichts zu tun.
> Der Linker sucht nach einer Define-Anweisung
???
Noe, noe, noe.
> findet sie in einem Modul des gleichen Quelltextes.
Ein Modul in einem Quelltext???
Mir scheint, hier liegt einiges im argen!
>daß er ja eigentlich erst im Anschluss an die # defines auswertet.
Linker wertet keine '#define's aus,
ein Linker linkt Objektmodule.
Also Bernhard http://www.linuxforen.de/ubb/smile.gif
Es gibt immer 4 Stufen (die NACHEINANDER abgearbeitet und nicht vermischt werden)
des Compiliervorganges:
a) Praeprozessor
(hier wird alles mit # ausgewertet)
b) Compilieren
c) Assemblieren
d) Linken
Diese Vorgaenge laufen auch bei
MS Studio oder Borland Builder oder ... so ab.
Makroexpansion (a) ist unser Fall,
d. h. hier Namensersetzung:
Der Praeprozessor soll ueberall im Quelltext, wo
Funktion1(irgendwas)
[ bzw. Funktion2(irgendwas) ]
vorkommt, durch
MeineFunktion(irgendwas, 0 , 1)
[ bzw. MeineFunktion(irgendwas, 1 , 0) ]
ersetzen.
Etwas, das er hier anscheinend nicht tut.
Jetzt schauen wir uns einen Code an:
#include <stdio.h>
#define Funktion1(i) MeineFunktion(i,0,1)
#define Funktion2(i) MeineFunktion(i,1,0)
void MeineFunktion( int i1, int i2, int i3)
{
printf("%d %d %d\n", i1, i2, i3);
}
int main(void)
{
int b;
for ( b = 0; b < 4 ; ++b) {
Funktion1(b);
Funktion2(b+1);
printf("\n");
}
return 0;
}
> gcc --version
2.95.2
> gcc -ansi -pedantic-errors -Wall -Werror a.c
> a.out
0 0 1
1 1 0
1 0 1
2 1 0
2 0 1
3 1 0
3 0 1
4 1 0
Tja, wer weiss, was der Robbi da wieder angestellt hat http://www.linuxforen.de/ubb/smile.gif
Hagen
PS
If you find a bug, please report it following our [3]bug reporting guidlines.
3. http://gcc.gnu.org/faq.html#bugreport
PPS
Bernhard, schau Dir doch nochmal das ganze
im Kernighan&Ritchie an,
Kapitel 4.11: Der C-Preprozessor
[Diese Nachricht wurde von Hagen von Tronje am 13. Februar 2000 editiert.]
Hallo Hagen!
Die Erklärung oben für Bernhard war schon richtig, aber deine Annahmen sind falsch! http://www.linuxforen.de/ubb/wink.gif
Wie heißt es so schön, man sollte keine Annahmen machen, wenn man es nicht besser weiß... oder so... http://www.linuxforen.de/ubb/smile.gif
Also, die Funktion "MeineFunktion" liegt, wie schon richtig angenommen, nicht bei Main!
ABER!!! Sie wird auch nicht durch Main aufgerufen, wie du es als Beispiel gegeben hast, sondern mit zig anderen Teilen zusammengelinkt.
Dazu wird diese im Entsprechenden Header-File auch explizit exportiert.
Im Header-File liegt die Define-Anweisung und die Export-Anweisung.
Es ist ein GCC Problem, aber ich weiß nicht ob es ein Bug ist!
Als Lösung habe ich jetzt erst mal Dummy-Funktionen statt der Define-Anweisungen erstellt, welche die eigentliche Funktion halt mit entsprechendne Parametern aufrufen.
Diesen Overhead wollte ich mir eben durch die Define-Anweisung sparen.
Gruß
Robert
P.S.
Übrigens, Hagen! Dies wird im Kernel 2.3.43 eben genau so gemacht und bringt den gleichen Fehler zu Tage!
Es ist keine unsaubere Lösung, sondern eine reine Optimierung.
[Diese Nachricht wurde von robert am 13. Februar 2000 editiert.]
Hagen von Tronje
13.02.00, 14:56
????????
Sieh Dir mal meine 2. Alternative
nochmals genau an,
und nimm statt main.c
#include <stdio.h>
void blob(void);
int main(void)
{
blob();
return 0;
}
und fuer blob.c
#include <stdio.h>
#include "meine.h"
void blob(void)
{
int b;
for ( b = 0; b < 4 ; ++b) {
Funktion1(b);
Funktion2(b+1);
printf("\n");
}
}
meine.c und meine.h wie oben.
Es wird von gcc-2.95.2 compiliert:
> gcc -ansi -pedantic-errors -Wall meine.c main.c blob.c
> a.out
0 0 1
1 1 0
1 0 1
2 1 0
2 0 1
3 1 0
3 0 1
4 1 0
Mit "unsauber" ist das warning gemeint:
blob.c: In function `blob':
blob.c:9: warning: implicit declaration of function `MeineFunktion'
Hagen
[Diese Nachricht wurde von Hagen von Tronje am 13. Februar 2000 editiert.]
Ja, und genau da liegt ja das Problem, was mich irritiert!
Wie du in deinem letztem Beispiel so schön aufgezeigt hast (ob in Main, oder wo anders, egal...) wird die Funktion in "meine.h" definiert.
/* meine.h */
#ifndef __meine_h
#define __meine_h
export MeineFunktion( int i1, int i2, int i3);
#define Funktion1(i) MeineFunktion(i, 0, 1)
#define Funktion2(i) MeineFunktion(i, 1, 0)
#endif
Und genau damit (weiteres wie in deinem Beispiel) kommt obige Fehlermeldung beim Linken (undefined reference Funktion1, undefined reference Funktion2), was eigentlich nicht sein sollte!
Also, woran liegt es???
Robert
Hagen von Tronje
13.02.00, 23:10
Hi again,
> Tja, wer weiss, was der Robbi da wieder angestellt hat http://www.linuxforen.de/ubb/smile.gif
Ok, ich kann es mir jetzt denken:
Er hat (wahrscheinlich) folgendes "konstruiert":
main.c
#include <stdio.h>
int main(void)
{
int b;
for ( b = 0; b < 4 ; ++b) {
Funktion1(b);
Funktion2(b+1);
printf("\n");
}
return 0;
}
und dann meine.c
#include <stdio.h>
#define Funktion1(i) MeineFunktion(i,0,1)
#define Funktion2(i) MeineFunktion(i,1,0)
void MeineFunktion( int i1, int i2, int i3)
{
printf("%d %d %d\n", i1, i2, i3);
}
> gcc -ansi -pedantic-errors -Wall main.c meine.c
main.c: In function `main':
main.c:11: warning: implicit declaration of function `Funktion1'
main.c:12: warning: implicit declaration of function `Funktion2'
/tmp/cchx18Vd.o: In function `main':
/tmp/cchx18Vd.o(.text+0x20): undefined reference to `Funktion1'
/tmp/cchx18Vd.o(.text+0x30): undefined reference to `Funktion2'
collect2: ld returned 1 exit status
*g*
Das musste ja schiefgehen, da fuer
BEIDE quellcodes der
Praeprozessor GETRENNT laeuft,
und wenn am Schluss der linker nach Funktion1[2] fuer main sucht,
sind diese ja gar nicht vorhanden.
Das hat aber nichts mit
gcc 2.95.2 zu tun, dass machen
andere auch http://www.linuxforen.de/ubb/smile.gif
(Unsaubere) Abhilfe:
#define Funktion1(i) MeineFunktion(i,0,1)
#define Funktion2(i) MeineFunktion(i,1,0)
ins main.c verlagern.
Alternativ:
main.c
#include <stdio.h>
#include <meine.h>
int main(void)
{
int b;
for ( b = 0; b < 4 ; ++b) {
Funktion1(b);
Funktion2(b+1);
printf("\n");
}
return 0;
}
und dann meine.c
#include <stdio.h>
void MeineFunktion( int i1, int i2, int i3)
{
printf("%d %d %d\n", i1, i2, i3);
}
Schliesslich meine.h
#define Funktion1(i) MeineFunktion(i,0,1)
#define Funktion2(i) MeineFunktion(i,1,0)
Hagen
PS
Bernhard rehabilitiert http://www.linuxforen.de/ubb/smile.gif
[Diese Nachricht wurde von Hagen von Tronje am 13. Februar 2000 editiert.]
Hagen von Tronje
14.02.00, 00:14
/* meine.h */
#ifndef __meine_h
#define __meine_h
extern void MeineFunktion( int i1, int i2, int i3);
#define Funktion1(i) MeineFunktion(i, 0, 1)
#define Funktion2(i) MeineFunktion(i, 1, 0)
#endif
Hagen von Tronje
14.02.00, 02:04
Hi Bernhard,
alles klar Schiff?
Robbi Robert hat ein C++-keyword benuetzt: export.
Das kann ja mit einen C-Compiler nicht funktionieren http://www.linuxforen.de/ubb/wink.gif
Ausserdem ist 'export' noch ganz neu und
wird von fast keinem Compiler unterstuetzt,
auch von 2.95.2 nicht.
Mich wundert sowieso, wie er damit bis zum
Linker durchgekommen ist, es muesste
normalerweise errors/warnings hageln http://www.linuxforen.de/ubb/smile.gif
2. Es (das 'export') haette auch nichts genuetzt, da er
gewissenhaft das 'int' nicht dabei hatte
=> naechster Fehler vorprogrammiert.
Also ich sehe (im Moment) keine Probleme:
> gcc -c -ansi -pedantic-errors -Wall -Werror main.c
> gcc -c -ansi -pedantic-errors -Wall -Werror meine.c
> gcc -c -ansi -pedantic-errors -Wall -Werror blob.c
> gcc -ansi -pedantic-errors -Wall -Werror blob.c main.c meine.c
> a.out
....
>
Hagen
Bernhard Koschnick
14.02.00, 05:02
Hallo Hagen
Nö. Bernhard ist noch lange nicht rehabilitiert. Das muss der sich erst noch hart verdienen. Er weiß ja, daß der Linker die Module zusammenlinkt und hat es trotzdem verkürzt und falsch gesagt.
Ich glaub aber nicht, daß er die Zusammenhänge so kannte. Und Deine Beispiele, die zur Brgründung dienen... Dein genanntes Kapitel aus dem Kernighan&Ritchie wird allein nicht reichen. Dank Dir für den Buchtip.
Hi Robert
Nach Deinem zweiten Beitrag kann ich wieder in geübtem Denkbereich mitdenken. Ich hab 'ne ganze Weile geknobelt, welchen Zweck dieser scheinbar unnötige Konstruct wohl verfolgen könnte. - Eine undeklarierte Funktion, die erst definiert und dann im gleichen Source geschrieben wird, hätte alles "über den Haufen" geworfen. - Dabei hätte ich mir denken müssen, daß Du Dein Anliegen nur sehr verkürzt darstellst. http://www.linuxforen.de/ubb/biggrin.gif
Gruss
Bernhard
P.S. Und was heisst: alles klar Schiff?, Hagen? Stumm bin ich nicht. Aber lass mich doch erst mal lesen. - Dieses -ansi-pedanti macht die Irritation doch erst vollkommen. Aber es errinnert mich an Postings, die hier vor langer Zeit mal gelaufen sind http://www.linuxforen.de/ubb/biggrin.gif . Oh hätt ich doch die Klappe gehalten und geschaut, wie "Dinos" das Thema handeln http://www.linuxforen.de/ubb/biggrin.gif http://www.linuxforen.de/ubb/biggrin.gif
Hagen,
natürlich hast du mit deiner genauen Art mal wieder Recht! http://www.linuxforen.de/ubb/smile.gif
Es sollte natürlich "extern" und nicht "export" heißen.
(Vielleicht sollte ich nicht noch 1.000 andere Sachen machen, wenn ich hier schreiben... http://www.linuxforen.de/ubb/smile.gif)
Also, mit EXTERN tritt der obige Fehler auf!
Aber langsam zweifle ich wirklich daran, ob es ein normaler Fehler ist.
Hagen, wenn du mal etwas Zeit nebenbei hast, tu mir doch mal den Gefallen und hol dir den Kernel 2.3.43 (unbedingt diesen!). Übersetz ihn mal mit GCC 2.95.2 und sag mir ob du obigen Fehler (undefined reference invalidate_buffers, bzw. destroy_buffers) erhälst. Diese beiden sind nämlich (ab 2.3.43) genauso mit #defines erstellt worden (wie ich es bei mir auch gemacht habe) und die eigentliche Funktion heißt __invalidate_buffers (alles in include/linux/fs.h).
Ich kann mir nicht vorstellen das die Jungs den Kernel freigegeben hätten, wenn dieses Problem vorhanden wäre.
Da es aber bei mir sowohl in meinen Sourcen, als auch (jetzt) bei diesem Kernel auftritt, vermute ich in meiner Installation eine Inkompatibilität!
Bernhard,
ja leider vergesse ich all zu leicht beim Schreiben es in allgemein verständlicher Form, bzw. etwas ausführlicher zu beschreiben.
Aber gerade aus solch netten Sachen wie dies hier kann Mensch noch so manches lernen. Z.B. warum wie und was wo abläuft und warum man manche Sachen besser nicht machen sollte. http://www.linuxforen.de/ubb/smile.gif
Gruß
Robert
Hagen von Tronje
14.02.00, 22:04
Hi,
hab' 2.3.43 mit 2.95.2 compiliert und
(oh Wunder http://www.linuxforen.de/ubb/wink.gif ) kein Fehler aufgetreten.
Haett' mich auch gewundert http://www.linuxforen.de/ubb/smile.gif
Das 'extern' im headerfile ist absolut Standard,
dass weder Robbi noch Linus erfunden haben und
schon im K&R zu lesen ist.
Wuerde das nicht funzen, wahrscheinlich
tausende von proggies wuerden sich nicht
(mehr) compilieren lassen.
Und den 2.95.2 gibt es nun auch schon seit Okt.
letzten Jahres.
(Was aber nicht heisst, dass tatsaechlich irgend-
wo dieser Bug (bei einer ganz bestimmten
Konfiguration) versteckt ist im gcc 2.95.2 !!!)
Was kann mensch tun?
Nun, Du kannst ja mal meine Testsuite nehmen und
gcc -v -E -ansi -pedantic-errors -Wall -Werror blob.c > blob.i
probieren:
Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/specs
gcc version 2.95.2 19991024 (release)
/usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/cpp -lang-c -std=c89 -v -D__GNUC__=2 -D__GNUC_MINOR__=95 -trigraphs -D__STRICT_ANSI__ -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix) -Wall -Werror -pedantic-errors -Acpu(i386) -Amachine(i386) -D__i386 -D__i386__ -D__i686 -D__i686__ -D__pentiumpro -D__pentiumpro__ blob.c
GNU CPP version 2.95.2 19991024 (release) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/../../../../i686-pc-linux-gnu/include
/usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/include
/usr/include
End of search list.
The following default directories have been omitted from the search path:
/usr/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/../../../../include/g++-3
/usr/local/include
End of omitted list.
und schauen ob der Praeprozessor am Schluss von 'blob.i'
# 1 "blob.c" 2
# 1 "meine.h" 1
extern void MeineFunktion( int i1, int i2, int i3);
# 2 "blob.c" 2
void blob(void)
{
int b;
for ( b = 0; b < 4 ; ++b) {
MeineFunktion( b , 0, 1) ;
MeineFunktion( b+1 , 1, 0) ;
printf("\n");
}
}
rausbekommen hat http://www.linuxforen.de/ubb/smile.gif
Hagen
Hagen von Tronje
15.02.00, 04:02
Hi Robbi,
moeglicherweise kannst Du tracen, falls Du die childs erwischt http://www.linuxforen.de/ubb/smile.gif
strace -vd -o trace_output gcc -v -E -ansi -pedantic-errors -Wall -Werror blob.c > blob.i
Hi Bernhard,
das mit den -ansi-pedanti (sic!) ist gar nicht so schwer:
Hintergrund:
Die ErbauerInnen des gcc (die GNU FritzInnen http://www.linuxforen.de/ubb/wink.gif ) sind dem ANSI-
Standard ziemlich abgeneigt,
deshalb reicht es nicht, nur
-ansi
anzugeben, sondern mensch muss auch noch
-pedantic-errors
(und
-Werror [Warnungen sollen als Fehler gemeldet werden]
-Wall)
angeben,
damit mensch konforme (naja fast http://www.linuxforen.de/ubb/wink.gif ANSI-Programme erhaelt http://www.linuxforen.de/ubb/smile.gif
-c heisst: nicht linken (keine 4. Stufe)
und
-E nur den Praeprozessor einschalten (nur 1. Stufe)
-v verbose (ausfuehrlich) (wie so oft)
Hagen
PS
Weitere Beispiele fuer den Praeprozessor und darum
erhaelst Du mittel
info cpp
bzw. im Verzeichnis /usr/info/
Hallo Hagen!
Also liegt es wohl doch an einem lokalem Problem bei mir.
Ich muß dazu sagen, das ich den GCC 2.95.2 selber übersetzt habe und dabei (neben einigen anderen Optionen) die Optimierung auf die CPU (k6 Architektur) gesetzt habe.
Vielleicht liegt es daran.
Ich werde den GCC nochmal mit Standard-Optionen übersetzen und installiern und dann mal schauen ob das Problem noch auftaucht.
Gruß
Robert
Bernhard Koschnick
15.02.00, 18:58
Hi Hagen
Da sag noch mal einer, einfach mal Interesse Bekunden oder auch mal 'ne falsche Antwort geben (kann ja gar nicht ausbleiben) bringt nichts. Hab schon oft gesehen, daß eine Frage erst lange nicht, dann aber nicht ganz richtig oder unvollständig beantwortet wurde. Scheinbar regt genau das oftmals erst zum Nachdenken übers Problem an. Die richtige Antwort kommt dann auch meist bald. Ich kann also Robert nur zustimmen. http://www.linuxforen.de/ubb/wink.gif
So wie Deine Erklärung ist, wünscht sich Pingu oft eine kurze verständliche Einfügrung über Zweck und Charakter eines Progs. Das sollte in den manpages und infos selbstverständliches Minimum sein. Die Verständnisschwelle ist für den Einsteiger doch beachtlich. Aber mit Grundinfos liest sich eine Syntax ganz anders.
Hatte diesen Effekt jetzt mit "Linux Die User-Referenz, mitp". Nach der prima Grundorientierung, die ich dank der Helpers in "Scripteinstieg" erhalten habe, ist das Buch ganz anders zugänglich. Auch den gut verständlichen Abschnitt zur bash weiss ich jetzt zu würdigen. Der ist ja schon in der Einführung sehr informativ.
Ich dank Dir für die Infos. - Unwissender stolpert immer wieder über die Unverzichtbarkeit von ANSI. Eine Zufallsentscheidung in der Startphase wird es nicht gewesen sein. Linux legte von Anfang an Wert auf Stabilität und Zuverlässigkeit. Kann das der Grund gewesen sein?...
Gruss
Bernhard
Hagen von Tronje
16.02.00, 02:39
Hi,
Sollte es auch in der default-configuration nicht klappen,
hast Du ja noch die Moeglichkeit:
gcc -include meine.h -ansi -pedantic-errors -Wall -Werror blob.c main.c meine.c
Immerhin etwas http://www.linuxforen.de/ubb/smile.gif
> Unwissender stolpert immer wieder über die Unverzichtbarkeit von ANSI.
> Eine Zufallsentscheidung in der Startphase wird es nicht gewesen sein.
Was fuer eine Entscheidung?
> Linux legte von Anfang an Wert auf Stabilität und Zuverlässigkeit.
> Kann das der Grund gewesen sein?...
Der Grund fuer was?
Mmmh, Deinen Gedankengang kann ich nicht folgen.
Ein Standard gibt erstmal Sicherheit.
Nehmen wir zum Beispiel FORTRAN 77.
Ist standardisiert. Den kommerziellen Compilerhersteller
(und nicht nur diesen) genuegte das aber nicht und jeder
hat seine eigenen Erweiterungen der Sprache in seine Compiletools
eingebracht.
Viele FORTRAN-HackerInnen haben jene Zusatzfeatures genutzt,
mit dem Resultat, dass mensch ein Programm, dass er/sie
heute compilieren moechte, nicht mehr funzt, da es
non-standard-Erweiterungen beinhaltet und der Compilerhersteller
auch schon laengst konkurs gegangenist bzw. die damalige
Computerplattform nicht mehr im Einsatz
ist.
Schoen, jetzt kannst Du Dich wochenlang hinsetzen und
die alten Ergaenzungen herausfischen, damit Du das proggie
auf Deinen PC wieder zum Leben erweckst.
Sicher, Standards werden auch weiterentwickelt und manche
Standards sind arg verbesserungswuerdig, aber diese
muehselige Arbeit bleibt den zukuenftigen Anwendern doch
erspart.
Hagen
[Diese Nachricht wurde von Hagen von Tronje am 16. Februar 2000 editiert.]
Bernhard Koschnick
17.02.00, 00:44
Hallo Hagen
Tut mir leid, daß ich das unverständlich gesagt habe. Die Alternative wäre ASCII. Ich nahm an, da Du Dich ja auch auf der $Win-Plattform satt auszukennen scheinst, würdest Du sowieso das ASCII assoziieren. Pech gehabt. Ich hab mir jedenfalls am Anfang mal ordentlich Minuspunkte eingefangen, als ich in passendem Zusammenhang ASCII nannte. (Da Linux-Editoren problemlos $Win-ASCII-Text öffnen können, nahm ich irrtümlich an, das sei auch hier Standard). Na ja, seitdem besteht eben bei mir die Frage, was wohl der Grund sein könnte, für Linux den ANSI-Standard zu wählen. Hab die Frage bisher noch nicht ausgesprochen.
Gruss
Bernhard
So, ich scheine auch auf des Pudells Kern gekommen zu sein.
Am GCC lag es nicht, denn eine Neu-Übesetzung brachte keine Hilfe.
Statt dessen habe ich alles mal etwas eingeschränkt und siehe da, es lag wohl irgend wo in einer tiefen Verschachtelung...
Pech, kann passieren... http://www.linuxforen.de/ubb/wink.gif
Robert
P.S.
Warum dies allerdings auch beim Kernel 2.3.43 aufgetreten ist, ist mir nicht klar. Denn mit dem 2.3.44 und 2.3.45 läuft es ohne Problem.
[Diese Nachricht wurde von robert am 17. Februar 2000 editiert.]
vBulletin® v3.8.6, Copyright ©2000-2012, Jelsoft Enterprises Ltd.