Na so schwer ist das ja nun nicht zu interpretieren ...
Code:
my_thr_init.c:342:19: error: expected expression before 'long'
STACK_DIRECTION (long)my_thread_stack_size;
^
my_thr_init.c:342:18: error: called object is not a function or function pointer
STACK_DIRECTION (long)my_thread_stack_size;
^
my_thr_init.c:342:24: error: expected ';' before 'my_thread_stack_size'
STACK_DIRECTION (long)my_thread_stack_size;
Da stimmt offenbar etwas in Zeile 342 der Datei my_thr_init.c nicht, die enthält bei Dir den Text
Code:
STACK_DIRECTION (long)my_thread_stack_size;
Das eigentlich Witzige an der Sache ist aber, daß da in den Zeilen 341 und 342 eigentlich folgendes stehen müßte (so findet es sich jedenfalls an mehreren anderen Stellen im Internet, es gibt ja keine "offizielle" Quelle mehr):
Code:
tmp->stack_ends_here= (char*)&tmp +
STACK_DIRECTION * (long)my_thread_stack_size;
Da würde ich mir jetzt an Deiner Stelle so meine Gedanken machen, z.B. woher ich diese Quelltext-Version habe, ob die Quelle dieses Downloads tatsächlich vertrauenswürdig war und ob bzw. was da event. noch geändert worden sein könnte.
Wenn Du das alles getrost als "Aluhut"-Bedenken abhaken kannst, dann solltest Du aber offenbar trotzdem mal in die betreffende Datei schauen, denn der "gcc" teilt ja einige meiner Bedenken, zumindest was die korrekte Syntax angeht und offensichtlich sieht er es auch weniger als Fortsetzung der Pointer-Arithmetik aus Zeile 341 als vielmehr als mißlungene Variablendeklaration oder einen Funktionsaufruf o.ä. - das mag er verständlicherweise so nicht.
Bleibt also die Frage, wo kommt diese Änderung denn her ...
Wenn man dann einen Schritt weiter geht und sich die Patches aus dem tar-File in #8 etwas genauer ansieht, dann findet sich zumindest eine Antwort, aber es stellen sich mir allerdings noch ganz andere Fragen.
Ich programmiere zwar auch in C, aber nicht ausschließlich - und kenne bestimmt nicht jede mögliche Feinheit und jeden Kniff, den man aus einem C-Compiler noch herauskitzeln könnte. Das sieht für mich aber doch zumindest teilweise etwas merkwürdig aus (das ist das File 100_mysql_6_0_11_alpha.patch, keine Ahnung, wer der Urheber ist):
Code:
Index: mysys/lf_alloc-pin.c
==================================================================================================================
--- mysys/lf_alloc-pin.c.orig 2009-12-12 21:51:40.000000000 +0100
+++ mysys/lf_alloc-pin.c 2009-12-12 21:40:04.000000000 +0100
@@ -314,7 +314,7 @@
return 0;
}
-#if STACK_DIRECTION < 0
[COLOR="#FF0000"]+#ifdef STACK_DIRECTION < 0[/COLOR]
#define available_stack_size(CUR,END) (long) ((char*)(CUR) - (char*)(END))
#else
#define available_stack_size(CUR,END) (long) ((char*)(END) - (char*)(CUR))
Index: mysys/my_thr_init.c
==================================================================================================================
--- mysys/my_thr_init.c.orig 2009-12-12 21:52:28.000000000 +0100
+++ mysys/my_thr_init.c 2009-12-12 21:39:55.000000000 +0100
@@ -338,8 +338,8 @@
0);
pthread_cond_init(&tmp->suspend, NULL);
[COLOR="#0000FF"]- tmp->stack_ends_here= (char*)&tmp +
- STACK_DIRECTION * (long)my_thread_stack_size;
+ tmp->stack_ends_here= (char*)&tmp +
+ STACK_DIRECTION (long)my_thread_stack_size;[/COLOR]
pthread_mutex_lock(&THR_LOCK_threads);
tmp->id= ++thread_id;
Index: storage/innobase/os/os0proc.c
==================================================================================================================
--- storage/innobase/os/os0proc.c.orig 2009-12-12 21:53:19.000000000 +0100
+++ storage/innobase/os/os0proc.c 2009-12-12 21:39:42.000000000 +0100
@@ -561,9 +561,9 @@
/*===============*/
/* out: allocated memory */
ulint n, /* in: number of bytes */
- ibool set_to_zero, /* in: TRUE if allocated memory
- should be set to zero if
- UNIV_SET_MEM_TO_ZERO is defined */
+ ibool set_to_zero, /* in: TRUE if allocated memory */
+ /* should be set to zero if */
+ /* UNIV_SET_MEM_TO_ZERO is defined */
ibool assert_on_error)/* in: if TRUE, we crash mysqld if
the memory cannot be allocated */
{
@@ -571,7 +571,7 @@
ulint size;
int shmid;
void *ptr = NULL;
- struct shmid_ds buf;
+ struct shmid_ds *buf;
if (!os_use_large_pages || !os_large_page_size) {
goto skip;
Index: sql/sql_class.cc
==================================================================================================================
--- sql/sql_class.cc.orig 2009-12-12 21:54:04.000000000 +0100
+++ sql/sql_class.cc 2009-12-12 21:39:33.000000000 +0100
@@ -1254,7 +1254,7 @@
mysys_var->id= thread_id;
real_id= pthread_self(); // For debugging
mysys_var->stack_ends_here= thread_stack + // for consistency, see libevent_thread_proc
- STACK_DIRECTION * (long)my_thread_stack_size;
+ STACK_DIRECTION (long)my_thread_stack_size;
/*
We have to call thr_lock_info_init() again here as THD may have been
Index: sql/sql_parse.cc
==================================================================================================================
--- sql/sql_parse.cc.orig 2009-12-12 21:54:56.000000000 +0100
+++ sql/sql_parse.cc 2009-12-12 21:39:19.000000000 +0100
@@ -5527,7 +5527,7 @@
#ifndef EMBEDDED_LIBRARY
-#if STACK_DIRECTION < 0
+#ifdef STACK_DIRECTION < 0
#define used_stack(A,B) (long) (A - B)
#else
#define used_stack(A,B) (long) (B - A)
Index: client/strings.h
==================================================================================================================
--- client/strings.h.orig 1970-01-01 01:00:00.000000000 +0100
+++ client/strings.h 2009-12-12 21:44:23.000000000 +0100
@@ -0,0 +1 @@
+#undef CONFIG_STRINGS
Index: sql/strings.h
==================================================================================================================
--- sql/strings.h.orig 1970-01-01 01:00:00.000000000 +0100
+++ sql/strings.h 2009-12-12 21:44:23.000000000 +0100
@@ -0,0 +1 @@
+#undef CONFIG_STRINGS
Da wird als in der ersten farblich markierten Zeile aus einer if-Direktive für den Präprozessor (das ist ein Vergleich von irgendwas mit irgendwem, hier von "STACK_DIRECTION" und "0") mal kurzerhand ein Test, ob "STACK_DIRECTION < 0" als Makro definiert ist? Das halte ich für ausgemachten Unsinn (ich lasse mich gerne korrigieren), bei dem mit hoher Wahrscheinlichkeit (wenn nicht irgendwo ein "#define STACK_DIRECTION < 0" existiert) immer der else-Zweig verwendet wird. Da hätte ich persönlich jetzt aus Gründen der Klarheit einfach irgendwo ein festes "#define STACK_DIRECTION {1|-1}" für die Zielplattform reingepatched und auf den ganzen Rest dann verzichtet.
Denn betrachtet man dann den Patch für my_thr_init.c genauer, ist das Original eigentlich in Ordnung: Auf die Adresse von "tmp" (auf char-Pointer gecasted) wird der Wert von "my_thread_stack_size" (in my_init.c als "ulong my_thread_stack_size= 65536;" deklariert) addiert. Das ganze Zeug mit STACK_DIRECTION soll vermutlich dafür sorgen, daß die Größe in Abhängigkeit von der Richtung des Stack-Pointers addiert oder subtrahiert wird. Welche der beiden Formen am Ende richtig ist, hängt nun zu 100% davon ab, ob und wie STACK_DIRECTION überhaupt definiert ist. Normalerweise sollte da so etwas wie "1" oder "-1" drin stehen (der originale Vergleich mit '0' legt das jedenfalls nahe), dann klappt auch die Multiplikation aus der ursprünglichen Fassung und die 64K werden positiv oder negativ. Wenn da aber die Multiplikation schon mit enthalten ist (also "1 *" bzw. "-1 *"), weiß ich gar nicht, ob das überhaupt geht. Also tippe ich mal wild, daß da STACK_DIRECTION am Ende undefiniert ist (mithin durch "gar nichts" ersetzt wird) und dann ist natürlich der zusätzliche Stern für die Multiplikation falsch. Stellt sich mir nur die Frage, warum dann der Patch nicht das ganze STACK_DIRECTION einfach entfernt in Zeile 342, die Alternative einer festen "STACK_DIRECTION" hatten wir ja schon.
Aber auch das ist noch nicht der eigentliche Knackpunkt, das sollte nur mal demonstrieren, wo man bei der Suche nach so einem Problem überall landen kann und warum die Fehlerbeschreibung immer noch ungenügend ist, denn es ist nicht einmal klar, wo die gepatchten Quellen für MySQL 6.0.11-alpha eigentlich her sind und ob da nicht schon irgendwelche Patches enthalten sind. Wenn dann solche Patches (die für mich eindeutig "falsch" sind und nur "mit Glück" das Ziel erreichen) am Ende tatsächlich wegen anderer Randbedingungen noch zu einem funktionsfähigen Programm führen, kommt man manchmal aus dem Staunen auch nicht mehr heraus.
Wenn der o.a. Patch auf die my_thr_init.c tatsächlich angewendet wurde, dann dürfte das Statement eigentlich nicht falsch sein, denn es müßte als Fortsetzung von Zeile 341 erkannt werden. Damit bleibt am Ende nur noch die Vermutung, daß dieser Patch gar nicht angewandt wurde ... das sieht man in dem Auszug aus dem make-Log aber nicht, da fehlt der Download und das Patchen komplett.
Da mußt Du also noch Informationen nachlegen oder einfach mal selbst in die Quelltexte schauen, am besten noch vor dem Patchen, ob da tatsächlich der erwartete Ausgangszustand vorliegt. Wenn das so ist, verstehe ich auch nicht, was der "gcc" an der Zeile 342 auszusetzen hat, denn dann steht da nach dem Patchen als letztes ein "+"-Zeichen in 341 und das ist in C ein deutliches Zeichen, daß die Anweisung weiter geht (und zwar bis zum abschließenden Semikolon, deshalb steht das in C eben am Ende jeder Anweisung).
Es ist für mich immer wieder überraschend (und für manche wahrscheinlich auch nicht nachvollziehbar), wie sich aus so einem kleinen Problem eine Suche an zig verschiedenen Stellen ergeben kann.
PS: Daß ich aber auch auf dem Standpunkt stehe, daß eigentlich jeder selbst in der Lage sein sollte, wenigstens die Stelle eines solchen Problems zu lokalisieren (das muß ja noch nicht die Ursache sein) und daß dann
selbstverständlich wenigstens ein Auszug der fraglichen Quelltext-Datei um die Fehlerstelle herum auch zu einer kompletten Fehlerbeschreibung gehört, damit ein Hilfewilliger sich nicht erst selbst die Quellen suchen und auspacken muß, brauche ich hoffentlich nicht extra zu betonen und es sollte zumindest als Hinweis bei weiteren Fragen zu dieser Problematik ausreichend sein, um von vorneherein eine umfassende und detaillierte Beschreibung des Problems zu erhalten.
