Dakuan
Anmeldungsdatum: 2. November 2004
Beiträge: 6339
Wohnort: Hamburg
|
Eigentlich geht das debuggen mit gdb/ddd ja ganz gut, aber ich stolpere immer wieder mal über obige Fehlermeldung ohne das ich einen Grund dafür erkennen kann. Jetzt habe ich ein komplettes Programmstück, in dem fast keine Symbole gefunden werden. Ich muss mir da die Variablen mittels printf() auf der Konsole ausgeben lassen. Einzelschrittbetrieb geht aber. Kann es sein, das der Compiler trotz der "-g" Option nicht alle Variablen in die Symboltabelle übernimmt? Zum "context": es handelt sich dabei um den Construktor für ein C++ Objekt, aber das sollte doch eigentlich auch kein Problem sein.
|
Dee
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20087
Wohnort: Schwabenländle
|
Eigener Konstruktor oder einer vom Compiler (falls Du Dich durch den ASM-Code wühlst)? Und Optimierungen hast Du alle aus? Gruß Dee
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6339
Wohnort: Hamburg
|
Du hast mich wieder mal auf dem linken Fuß erwischt. Also durch ASM Code wühle ich mich nicht mehr, aber der Konstruktor ist schon von mir. Da ich in Sachen C++ aber noch Einsteiger bin, kann ich nicht sagen, ob ich was wichtiges vergessen habe. Bisher bin ich auch davon ausgegangen, das durch "-g" Optimierungen, soweit sie dafür relevant sind, unterdrückt werden. Zumindest war das damals unter Windows bei meinem Borland Compiler so. Eine Wegoptimierung der kompletten Variablen kann ja auch nicht geschehen, solange sie noch gebraucht werden. Ich poste jetzt aber doch mal den Quelltext des Objekts, auch auf die Gefahr hin, das es für jemanden der sich mit FLTK nicht auskennt wenig verständlich ist. Ich habe aber einige diesbezügliche Kommentare eingefügt. Das Ganze ist ein Popup Window, das den Inhalt einer Auswahlliste darstellt.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71 | class
List_Box {
Fl_Button * lbbt;
Fl_Window * lbwin;
Fl_Hold_Browser * lbbr; // Browser zum Anzeigen einer Liste
int list_ix; // Zeilennummer, falls der Benutzer etwas ausgewählt hat
public:
List_Box( int x, int y, int w, char * lst[], int& res );
~List_Box();
static void listbox_cb( Fl_Widget * w, void * u );
};
List_Box::List_Box( int x, int y, int w, char * lst[], int& res ) {
int brw = w - 46;
int brh = 30; // Mindesthöhe wg. Button
int cw = 0;
int ch = 0;
int lcnt = 0;
int maxh = 0;
char ** lp = lst;
if( *lp == NULL )
return;
list_ix = 0;
while( *lp != NULL ) {
lcnt++;
lp++;
}
fl_measure( "Hight", cw, ch, 0 ); // dummy text, ermitteln der Zeichenhöhe
maxh = (ch * 10) + 4;
ch *= lcnt;
ch += 4; // + margin
if( ch > brh ) brh = ch;
if( brh > maxh ) brh = maxh;
lbwin = new Fl_Window( x, y, w, brh+4 );
lbwin->begin();
lbwin->border( 0 );
lbbr = new Fl_Hold_Browser( 2, 2, brw, brh );
Fl_Group * g = new Fl_Group( brw+4, 2, 40, brh );
Fl_Box * b = new Fl_Box( brw+4, 2, 40, brh-26 );
b->box( FL_FLAT_BOX );
//b->color( FL_GREEN ); // Layout test
lbbt = new Fl_Button( brw+4, brh+2-26, 40, 26, "ok" );
g->resizable( b );
g->end();
lbwin->end();
lbwin->resizable( lbbr );
lbbt->callback( listbox_cb, this );
lp = lst;
while( *lp != NULL ) {
lbbr->add( *lp );
lp++;
}
lbwin->set_modal();
lbwin->show();
while( lbwin->visible() ) {
Fl::wait();
}
res = list_ix;
delete lbwin;
}
List_Box::~List_Box() {}
void
List_Box::listbox_cb( Fl_Widget * w, void * u ) {
List_Box * lb = (List_Box *)u;
lb->list_ix = lb->lbbr->value(); // Zeilenindex abholen
lb->lbwin->hide();
}
|
Von den lokalen Variablen wird keine angezeigt. Die printf() Anweisungen habe ich wieder rausgenommen und der Code funktioniert jetzt auch (hatte Probleme mit der Berechnung der benötigten Fensterhöhe). Ach ja, Fl::wait() ist kein aktives warten, es wird nur der Thread gestoppt.
|
Dee
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20087
Wohnort: Schwabenländle
|
Bisher bin ich auch davon ausgegangen, das durch "-g" Optimierungen, soweit sie dafür relevant sind, unterdrückt werden.
Per Standard ist ja eh -O0 angewählt, also keine Optimierung. Dennoch optimiert der Compiler meines Wissens, wo er denkt, dass es nicht schlimm wäre. Ich habe Deine Klasse mal durch diverse Stubs zum Laufen gebracht und sehe bei mir im Debugger die lokalen Variablen alle. Vll. müsstest Du doch das ganzen Archiv veröffentlicht oder ein kompilierfähiges Minimalbeispiel abliefern, sodass es mal jemand nachtesten kann. Ich hätte erst gedacht, dass die Variablen bei Dir Konstanten sind, die nicht verändert werden, aber dem ist ja nicht so. Ich sehe keine Grund, warum der Compiler diese wegoptimieren sollte/könnte.
Von den lokalen Variablen wird keine angezeigt.
Das heißt, wenn Du in Zeile 22 einen Breakpoint in ddd setzt und bis dorthin läufst und dann im gdb ein "print lcnt" eingibst, erhältst Du keine 0, sondern ein "optimized out"? Weil das schreibt er eigentlich, wenn etwas wegoptimiert wurde. "No symbol lcnt in current context." klingt eher danach, als würdest Du an der falschen Programmstelle stehen oder z.B. an der falschen Stelle im Stack. Gruß Dee
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6339
Wohnort: Hamburg
|
erhältst Du keine 0, sondern ein "optimized out"?
Nein, das kommt nicht. Aber ich habe nochmal nachgedacht, konnte ja irgendwie nicht so gut schlafen, und mir ist der Verdacht gekommen, das es vielleicht mit der Art der Verwendung zu tun hat. Und eben ist mir noch aufgefallen, das da noch eine andere Meldung kommt, etwa sowas: Breakpoint 2 at 0x80xxxxx: file dbs.cpp, line xxx. (2 locations)
Das List_Box Objekt wird bisher nur an einer einzigen Stelle verwendet und sollte danach eigentlich sofort wieder automatisch zerstört werden (so dachte ich wenigstens). 1
2
3
4
5
6
7
8
9
10
11
12 | // Callback for Open-Listbox Button
void
Head_Bar::headbar_lb_cb( Fl_Widget * w, void * u ) {
Head_Bar * hb = (Head_Bar *)u;
MainWindow * mwp = (MainWindow *)hb->parent();
int i = 0;
List_Box( mwp->x()+hb->x()+hb->w()-406, mwp->y()+hb->y()+hb->h(), 387, hb->lru->lru_tab, i );
if( i > 0 ) {
hb->in->value( hb->lru->get( i ) ); // String aus LRU Liste in Eingabefenster kopieren
}
}
|
Hier zeigt sich wohl, das ich irgendetwas wichtiges von C++ noch nicht verstanden habe und noch in ANSI C denke. Vielleicht ist in diesem Zusammenhang noch interessant, das die erzeugte Listbox kein Parent-Objekt hat von der ich die Koordinaten direkt abgreifen könnte. Deshalb oben die Orgie mit den Koordinaten. Über das Minimalbeispiel denke ich heute Mittag mal nach, aber da werden wohl dann trotzdem noch an die 300 Zeilen übrig bleiben. Und bei solchen Sachen habe ich immer Angst, das der Fehler dann nicht mehr auftritt.
|
Dee
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20087
Wohnort: Schwabenländle
|
Das List_Box Objekt wird bisher nur an einer einzigen Stelle verwendet und sollte danach eigentlich sofort wieder automatisch zerstört werden (so dachte ich wenigstens).
Du erzeugst aber effektiv kein Objekt. Du rufst nur den Konstruktor auf. Du kannst ja spaßeshalber mal ein Objekt auf dem Stack anlegen: List_Box aListBox( mwp->x()+hb->x()+hb->w()-406, mwp->y()+hb->y()+hb->h(), 387, hb->lru->lru_tab, i );
Hier zeigt sich wohl, das ich irgendetwas wichtiges von C++ noch nicht verstanden habe und noch in ANSI C denke.
An Deinem Programmierstil sieht man das etwas. Die Einrückungen sind teilweise inkonsistent (also eingerückt, wo man es nicht erwarten würde), die Variablen sind nicht wikrlich gut benannt (Namen wie w und u gehen maximal als Zählvariablen in einer Schleife durch) und in einer Klasse fängt man normalerweise mit den Sachen an, die für den Benutzer der Klasse interessant sind (und das sind die public-Methoden und nicht die private-Member, auf die man eh keinen Zugriff hat).
Über das Minimalbeispiel denke ich heute Mittag mal nach, aber da werden wohl dann trotzdem noch an die 300 Zeilen übrig bleiben. Und bei solchen Sachen habe ich immer Angst, das der Fehler dann nicht mehr auftritt.
Das ist nicht schlimm. Ganz im Gegenteil findest Du so eher heraus, wieso sich der Code bei Dir dann anders verhält. So löst man die meisten Probleme: Solange reduzieren, bis das Problem nicht mehr auftritt und dann schauen, was dran schuld war. Oft hat Code Seiteneffekte, von dem man es nicht erwartet hätte. Gruß Dee
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6339
Wohnort: Hamburg
|
Ich habe den Aufruf jetzt so geändert das wirklich ein Objekt erzeugt wird.
1
2
3
4
5
6
7
8
9
10
11
12
13 | void
Head_Bar::headbar_lb_cb( Fl_Widget * w, void * u ) {
Head_Bar * hb = (Head_Bar *)u;
MainWindow * mwp = (MainWindow *)hb->parent();
List_Box * lb;
int i = 0;
lb = new List_Box( mwp->x()+hb->x()+hb->w()-406, mwp->y()+hb->y()+hb->h(), 387, hb->lru->lru_tab, i );
if( i > 0 ) {
hb->in->value( hb->lru->get( i ) );
}
delete lb;
}
|
das ändert aber nichts. Kann das damit zusammenhängen, dass die Callbacks immer statisch sind?
Die Einrückungen sind teilweise inkonsistent (also eingerückt, wo man es nicht erwarten würde), ...
Das hat mit der Gruppierung der Elemente zu tun und weniger mit der Programmlogik. FLTK verhält sich da etwas merkwürdig, wenn man die Fenstergröße ändert, da muss man dann etwas tricksen, sonst wird alles, aber auch wirklich alles, also auch Buttons, proportional verändert. Die Variablen w und u habe ich einfach aus den Beispielen übernommen ohne weiter darüber nachzudenken. Ich versuche jetzt mal das Problem in einer abgespeckten Version zu reproduzieren.
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6339
Wohnort: Hamburg
|
So, ich habe jetzt alles rausgeschmissen, was irgendwie entbehrlich erscheint und das Problem besteht weiterhin. Die Listbox erscheint, wenn mindestens ein Text eingegeben wurde und dann der Button mit den 3 Punkten gedrückt wird.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309 | /*
** debug-test.cpp
**
** fltk-config -g --compile debug_test.cpp
*/
#include <FL/Fl.H>
#include <FL/Fl_Window.H>
#include <FL/Fl_Double_Window.H>
#include <FL/Fl_Menu_Bar.H>
#include <FL/Fl_Box.H>
#include <FL/Fl_Hold_Browser.H>
#include <FL/Fl_Button.H>
#include <FL/Fl_Input.H>
#include <FL/Fl_Group.H>
#include <FL/fl_draw.H> // fl_measure()
#include <string.h> // strlen(), debug
class
LRU_str {
int lru_cnt;
int lru_max;
public:
char ** lru_tab;
LRU_str( int max );
~LRU_str();
void add( const char * p );
const char * get( int ix );
};
class
List_Box {
Fl_Button * lbbt;
Fl_Window * lbwin;
Fl_Hold_Browser * lbbr;
int list_ix;
public:
List_Box( int x, int y, int w, char * lst[], int& res );
~List_Box();
static void listbox_cb( Fl_Widget * w, void * u );
};
class
Head_Bar : public Fl_Box {
Fl_Box * b;
Fl_Button * sb;
Fl_Button * lb;
Fl_Input * in;
LRU_str * lru;
public:
Head_Bar( int xpos, int ypos, int width, int height );
~Head_Bar();
void draw( void );
void set_label( const char * );
static void headbar_in_cb( Fl_Widget * w, void * u );
static void headbar_bt_cb( Fl_Widget * w, void * u );
static void headbar_lb_cb( Fl_Widget * w, void * u );
};
class
MainWindow : public Fl_Double_Window {
Fl_Box * box;
Fl_Menu_Bar * menubar;
public:
Head_Bar * header;
MainWindow( int w, int h, const char * t );
~MainWindow();
static void Menu_Quit_cb( Fl_Widget *, void * );
};
// ---------------------------------------------------------------------------
//
MainWindow::MainWindow( int w, int h, const char* t ) :
Fl_Double_Window( w, h, t ) {
begin();
color( FL_GRAY );
menubar = new Fl_Menu_Bar( 4, 0, w-(2*4), 30 );
menubar->add( "&File/Open", 0, NULL, this );
menubar->add( "&File/&Exit", 0, Menu_Quit_cb );
header = new Head_Bar( 4, 30, w-8, 26 );
box = new Fl_Box( 4, 56, w-8, h-60 );
end();
box->box( FL_DOWN_BOX );
this->resizable( box );
}
MainWindow::~MainWindow( ) { }
void
MainWindow::Menu_Quit_cb( Fl_Widget * w, void * u ) {
MainWindow * mwp = (MainWindow *)w->parent();
mwp->hide();
}
Head_Bar::Head_Bar( int x, int y, int w, int h )
: Fl_Box( x, y, w, h ) {
int hi = h - 2;
Fl_Group * g = new Fl_Group( x, y, w, h );
b = new Fl_Box( x, y, w - 427, h );
b->box( FL_FLAT_BOX );
b->align( FL_ALIGN_LEFT | FL_ALIGN_INSIDE );
Fl_Group * gi = new Fl_Group( x+w - 426, y, 426, h );
gi->box( FL_DOWN_BOX );
gi->color( FL_BACKGROUND2_COLOR );
in = new Fl_Input( x+w - 400, y + 2, 319, hi-2, "@search" );
in->box( FL_FLAT_BOX );
in->when( FL_WHEN_ENTER_KEY_ALWAYS );
sb = new Fl_Button( x+w-80, y+2, 40, hi-2, "go" );
lb = new Fl_Button( x+w-40, y+2, 40, hi-2, "..." );
gi->end();
g->end();
g->resizable( b );
sb->callback( headbar_bt_cb, this );
lb->callback( headbar_lb_cb, this );
in->callback( headbar_in_cb, this );
in->tooltip( "Suchmuster für regex() eingeben" );
lru = new LRU_str( 8 );
};
Head_Bar::~Head_Bar() {}
void
Head_Bar::draw( void ) {
redraw();
}
// Callback for Head_Bar Input Widget
void
Head_Bar::headbar_in_cb( Fl_Widget * w, void * u ) {
Head_Bar * hb = (Head_Bar *)u;
MainWindow * mwp = (MainWindow *)hb->parent();
hb->lru->add( ((Fl_Input*)w)->value() );
hb->set_label( ((Fl_Input*)w)->value() );
//mwp->filter->pattern( ((Fl_Input*)w)->value() );
//mwp->proc_db_file( );
}
// Callback for Head_Bar Button
void
Head_Bar::headbar_bt_cb( Fl_Widget * w, void * u ) {
Head_Bar * hb = (Head_Bar *)u;
MainWindow * mwp = (MainWindow *)hb->parent();
hb->lru->add( hb->in->value() );
hb->set_label( hb->in->value() );
//mwp->filter->pattern( hb->in->value() );
//mwp->proc_db_file( );
}
// Callback for Open-Listbox Button
void
Head_Bar::headbar_lb_cb( Fl_Widget * w, void * u ) {
Head_Bar * hb = (Head_Bar *)u;
MainWindow * mwp = (MainWindow *)hb->parent();
List_Box * lb;
int i = 0;
lb = new List_Box( mwp->x()+hb->x()+hb->w()-406, mwp->y()+hb->y()+hb->h(), 387, hb->lru->lru_tab, i );
if( i > 0 ) {
hb->in->value( hb->lru->get( i ) );
}
delete lb;
}
void
Head_Bar::set_label( const char * p ) {
b->copy_label( p );
}
List_Box::List_Box( int x, int y, int w, char * lst[], int& res ) {
int brw = w - 46;
int brh = 30;
int cw = 0;
int ch = 0;
int lcnt = 0;
int maxh = 0;
char ** lp = lst;
if( *lp == NULL )
return;
list_ix = 0;
while( *lp != NULL ) {
lcnt++;
lp++;
}
fl_measure( "Hight", cw, ch, 0 ); // dummy text
maxh = (ch * 10) + 4;
ch *= lcnt;
ch += 4; // + margin
if( ch > brh ) brh = ch;
if( brh > maxh ) brh = maxh;
lbwin = new Fl_Window( x, y, w, brh+4 );
lbwin->begin();
lbwin->border( 0 );
lbbr = new Fl_Hold_Browser( 2, 2, brw, brh );
Fl_Group * g = new Fl_Group( brw+4, 2, 40, brh );
Fl_Box * b = new Fl_Box( brw+4, 2, 40, brh-26 );
b->box( FL_FLAT_BOX );
//b->color( FL_GREEN ); // Layout test
lbbt = new Fl_Button( brw+4, brh+2-26, 40, 26, "ok" );
g->resizable( b );
g->end();
lbwin->end();
lbwin->resizable( lbbr );
lbbt->callback( listbox_cb, this );
lp = lst;
while( *lp != NULL ) {
lbbr->add( *lp );
lp++;
}
lbwin->set_modal();
lbwin->show();
while( lbwin->visible() ) {
Fl::wait();
}
res = list_ix;
delete lbwin;
}
List_Box::~List_Box() { }
void
List_Box::listbox_cb( Fl_Widget * w, void * u ) {
List_Box * lb = (List_Box *)u;
lb->list_ix = lb->lbbr->value();
lb->lbwin->hide();
}
// ---------------------------------------------------------------------------
// LRU table object (last recently used)
//
LRU_str::LRU_str( int max ) {
lru_cnt = 0;
lru_max = max;
lru_tab = new char * [lru_max+1]; // last pos is constant end marker
for( int i = 0; i < lru_max + 1; i++ )
lru_tab[i] = NULL;
}
// add a new string to the LRU table
// if the string is already in the table, move it to the first position
// if the table is full, forget the oldest string
void
LRU_str::add( const char * p ) {
int i;
int l;
char * tmp;
if( (l = strlen( p )) == 0 )
return; // ignore empty strings
l += 1;
for( i = 0; i < lru_cnt; i++ ) { // check for duplicate strings
if( strcmp( lru_tab[i], p ) == 0 ) {
if( i == 0 )
return; // dup already in first position
tmp = lru_tab[i];
while( i > 0 ) { // move to first position ...
lru_tab[i] = lru_tab[i-1];
i--;
}
lru_tab[0] = tmp;
return;
}
}
// we have a new string to store
i = lru_max - 1;
if( lru_tab[i] != NULL )
delete lru_tab[i];
while( i > 0 ) {
lru_tab[i] = lru_tab[i-1];
i--;
}
lru_tab[0] = new char [l];
strcpy( lru_tab[0], p );
if( lru_cnt < lru_max )
lru_cnt++;
}
// get string[ix] from the LRU table and move it to the first position
// Index ix is 1-based because Fl_Browser returns 0 for no selection
//
const char *
LRU_str::get( int ix ) {
char * tmp;
int i = ix - 1; // convert to 0-based index
if( i < 0 || i >= lru_cnt )
i = 0;
if( i > 0 ) {
tmp = lru_tab[i];
while( i > 0 ) {
lru_tab[i] = lru_tab[i-1];
i--;
}
lru_tab[0] = tmp;
}
return lru_tab[0];
}
LRU_str::~LRU_str( ) {
delete lru_tab;
}
int
main( int argc, char**argv ) {
Fl::get_system_colors();
Fl::scheme("gtk+");
MainWindow * mwin = new MainWindow( 600, 300, "debug test" );
mwin->show();
return( Fl::run() );
}
|
|
Dee
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20087
Wohnort: Schwabenländle
|
Okay, habe das übersetzt und kann ohne Probleme debuggen. Ich denke also, dass es ein Bedienfehler ist. Mach bitte mal einen Screenshot vom ddd-Fenster inkl. der gdb-Ausgabe beim "print lcnt"-Versuch und inkl. Backtrace-Fenster. Dann sehe ich hoffentlich, in welchem Kontext Du gerade stehst. Bitte gib auch mal die Zeile zum Kompilieren an. Ich habe es mit $ g++ -g main.cc -lfltk
$ ddd ./a.out übersetzt und ausgeführt. Gruß Dee
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6339
Wohnort: Hamburg
|
Hallo Dee, danke für Deine Bemühungen (ist ja bei so exotischen Programmen nicht selbstverständlich). Das Backtrace-Fenster kannte ich bisher noch nicht. Ich werde nachher mal sehen, was ich damit anstellen kann. Ich muss zugeben, das ich mit der Bedienung von ddd noch Probleme habe. Das ist ja für jemanden der die sehr intuitiv zu bedienende Borland IDE kennt doch sehr gewöhnungsbedürftig. Ausserdem bin ich etwas in Zeitnot, weil ich da noch ein anderes Programm habe, wo ein anderer Benutzer einen nervigen Bug entdeckt hat.
Bitte gib auch mal die Zeile zum Kompilieren an.
Die steht doch ganz oben im Quelltext:
fltk-config -g --compile debug_test.cpp
Ich benutze das mitgelieferte Script. Deine Variante scheint dynamisches linking zu benutzen und ein völlig anderes Setup vorauszusetzen. Bei mir kommen mit Deinen Eingabe gefühlte 2km Fehlertext, die darauf schlissen lassen, das sowhl die Header Dateien als auch die Libs nicht gefunden werden. Das Installationsscript hat mir die Libs nach /usr/local/lib/ installiert und die Includes liegen in /usr/local/inclide/FL/. Aber da fällt mir noch ein, könnte das auch ein Versionskonflikt sein? Denn ich habe FLTK nicht aus den Paketquellen installiert, sondern vom Quelltext der Webseite. Bei der Installation aus den Paketquellen funktionierten zu viele der Beispielprogramme nicht. Ich melde mich morgen Vormittag noch einmal. Nachtrag: Die Includes werden wohl gefunden, nicht aber die Libs. Alle Fehlermeldungen sehen so aus: ... undefined reference to Fl...
|
Dee
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20087
Wohnort: Schwabenländle
|
Deine Variante scheint dynamisches linking zu benutzen und ein völlig anderes Setup vorauszusetzen.
Da ich natürlich FLTK nicht manuell kompiliere, habe ich Version 1.3 aus den Quellen genommen. Aber das war ein guter Hinweis. Ich habe nun mal mit $ fltk-config -g --compile main.cc
$ ddd ./main übersetzt und gestartet. Und was ergibt sich dann, wenn man im Debugger den Wert ausgeben will: (gdb) print lcnt
$1 = <optimized out> Und woran liegt das: Ganz einfach an dem Compileraufruf, den fltk-config macht (gekürzt): g++ ... -g -O2 ... -g -o 'main' 'main.cc' ... -L/usr/lib/x86_64-linux-gnu -lfltk Also hast Du bzw. FLTK -O2 als Optimierung eingeschaltet, was zusammen mit -g geht (steht auch so in der Manpage von g++). Das erklärt auch, wieso man den Wert nicht anzeigen lassen kann. Kompiliere also lieber manuell, damit Du sicher bist, dass nicht optimiert wird.
Die Includes werden wohl gefunden, nicht aber die Libs. Alle Fehlermeldungen sehen so aus:
Schau auf die Ausgabe des fltk-config-Aufrufs und gib alles mit -L... und -l... auch bei Deinem manuellem Compileraufruf mit an. Gruß Dee
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6339
Wohnort: Hamburg
|
Ich glaube jetzt nähern wir uns dem Kern des Problems. Aber wie ich das manuell übersetzen kann muss ich erstmal sehen. Ich habe jetzt erstmal abgefragt was FLTK da überhaupt in Sachen Optimierung macht.
manfred@qube:~/prog/dir$ fltk-config --optim
-Os -Wall -Wunused -Wno-format-y2k -fno-exceptions -fno-strict-aliasing
Wenn ich das richtig verstanden habe, wird da immer auf "size" optimiert. Ich habe mir die entsprechenden Angaben in "man c++" mal angesehen und die Hinweise klingen teilweise gruselig.
Könnte folgende Meldung ebenfalls damit zu tun haben?
(gdb) file /home/manfred/prog/dir/debug_test
(gdb) break debug_test.cpp:192
Breakpoint 1 at 0x804c008: file debug_test.cpp, line 192. (2 locations)
(gdb)
Ich hatte in dieser Zeile nur EINEN Breakpoint gesetzt. Er hält da auch an, zeigt aber kein rotes Symbol. Ich werde mal versuchen, ob ich die benötigten Angaben zusammen kriege. Eigentlich hatte ich das schonmal für ein Makefile versucht, was aber nicht richtig funktionierte. Ich denke die Screenshots haben sich erstmal erübrigt.
|
Dee
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20087
Wohnort: Schwabenländle
|
Die Meldung sagt wahrscheinlich aus, dass Du in der Zeile nicht anhalten kannst, weil sie weg optimiert wurde. Aber Dein Problem ist das -O von fltk-config. Wenn Du mit "fltk-config" kompilierst, siehst Du doch die gesamte Ausgabe-Zeile von g++. Die musst Du doch nur einfach kopieren und darin alle "-O" weglassen. Gruß Dee
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6339
Wohnort: Hamburg
|
Die Meldung sagt wahrscheinlich aus, dass Du in der Zeile nicht anhalten kannst, weil sie weg optimiert wurde.
Doch, ich kann da anhalten. Es fehlt nur das Breakpoint Symbol. Der grüne Pfeil ist beim tracen aber da. Und die übergebenen Variablen werden auch angezeigt, nur die lokalen nicht. Ich würde den Text eher so interpretieren, das der zugehörige Code 2 mal vorhanden ist, was dann allerdings nichts mehr mit size-Optimierung zu tun hätte. Und nätürlich sehe ich die ganze Zeile, aber da ist nirgends ein "O" drinne. Original: g++ -I/usr/local/include -I/usr/local/include/FL/images -I/usr/include/freetype2 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_THREAD_SAFE -D_REENTRANT -g -o 'debug_test' 'debug_test.cpp' /usr/local/lib/libfltk.a -lXft -lfontconfig -lpthread -ldl -lm -lX11
und das kürzeste, was ohne Fehler durchläuft:
g++ -I/usr/local/include -g -o 'debug_test' 'debug_test.cpp' /usr/local/lib/libfltk.a -lXft Aber ich setze das jetzt trotzdem mal auf "gelöst", denn ich weiss jetzt ja wonach ich suchen muss. Ich werde in den nächsten Tagen mal sehen wie sich das Ganze auf meinem Debian PC verhält (mein Ubuntu ist ja nicht mehr das neueste).
|
Dee
Anmeldungsdatum: 9. Februar 2006
Beiträge: 20087
Wohnort: Schwabenländle
|
Echt seltsam, dass, obwohl wir den selben Quellcode kompilieren, die gcc-Zeile eine andere ist. Ich muss nach Deiner Art zum Beispiel: $ g++ -g -o 'debug_test' 'debug_test.cpp' /usr/lib/x86_64-linux-gnu/libfltk.a -lXft -lXinerama (Also ich brauch noch eine Library mehr als Du.) Aber auch dann: Wenn ich mit ddd debugge, sehe ich alle Symbole, die es zu sehen gibt. Ich glaube, es wäre nach dem Start von ddd und Öffnen der GUI wichtig, was Du tust. Also was gibst Du ein, wo drückst Du drauf und wo setzt Du Deine Breakpoints und was wird genau angezeigt (Screenshot)? Du kannst dem gerne noch weiter nachgehen. Ich denke nach wie vor, dass es ein Bedienfehler ist, aber will natürlich nicht völlig ausschließen, dass sich mein gcc und ddd anders verhält als Deiner. Gruß Dee PS: Und ich nutze auch Xubuntu 12.04. Wichtiger wäre wohl, was passiert, wenn Du das fltk 1.3 aus den Ubuntu-Quellen nimmst.
|