Probleme mit Compiler-Versionen

erin

Ich versuche, ein schon betagtes c++-Programm (Edges, von 1999-2000) zu beleben. Es gibt dazu nur die Sourcen, und das ohne Build-System. Als erstes habe ich die rund 35 Dateien (jeweils C und h) in ein Makefile gepackt und unter Debian über den Compiler (Vers. 3.3) laufen lassen. Es regnete Fehlermeldungen, und mir wurde klar, dass ich an den Quelltext muss (deshalb die Anfrage in diesem Forum).

Da das Programm älter ist, habe ich den Dateibaum mal zur alten Suse7.3 rübergeschoben und dort mit Vers. 2.95 compiliert. Sämtliche Objektfiles wurden anstandslos compiliert, nur der Linker brachte noch ein Dutzend Fehlermeldungen, hauptsächlich fehlende Libraries. Da ich die nicht nachinstallieren will und kann, bin ich zurück zu Debian gegangen, habe aber die o-Dateien drin gelassen und nur noch den Linker bemüht. Ergebnis: rund 500 Fehlermeldungen, von denen ich hier nur einige typische wiedergebe:

: undefined reference to `ostream::operator<<(char const *)'
TriStrip.o(.text+0x2359): In function `TriStrip::output(char const *)':

: undefined reference to `terminate(void)'
TriStrip.o(.vector<Vertex *, allocator<Vertex *> >::gnu.linkonce.t._M_insert_aux(Vertex **, Vertex *const &)+0xf8): 
In function `vector<Vertex *, allocator<Vertex *> >::_M_insert_aux(Vertex **, Vertex *const &)':

: undefined reference to `terminate(void)'
TriStrip.o(.gnu.linkonce.t._._8PriQueue+0x1c): In function `PriQueue::~PriQueue(void)':
: undefined reference to `__builtin_delete'
TriStrip.o(.gnu.linkonce.t._._5Timer+0x1c): 
In function `Timer::~Timer(void)':

: undefined reference to `terminate(void)'
TriStrip.o(.vector<vector<Vertex *, allocator<Vertex *> > *, 
allocator<vector<Vertex *, allocator<Vertex *> > *> 
>::gnu.linkonce.t.(allocator<vector<Vertex *, allocator<Vertex *> > *> 
const &)+0x21): In function `vector<vector<Vertex *, allocator<Vertex *> > *, 
allocator<vector<Vertex *, allocator<Vertex *> > *> 
>::vector(allocator<vector<Vertex *, allocator<Vertex *> > *> const &)':

: undefined reference to `istream::operator>>(int &)'
UWashFilter.o(.text+0x781): In function `UWashFilter::readFile(char *, Mesh &)':

Die Fehlertypen wiederholen sich teilweise bis zu 50 mal. Ich vermute stark, dass der Quelltext nicht den neuen c++-Normen entspricht. Deshalb meine Frage: Ist es möglich, den Quelltext mit erträglichem (!) Aufwand zu modernisieren und wo muss ich dabei ansetzen?

Hinweis: Die Includes entsprechen den neueren Normen (z.B. <iostream> ohne .h), Namespaces konnte ich nicht entdecken.

erin

CStoll

erin schrieb:

Hinweis: Die Includes entsprechen den neueren Normen (z.B. <iostream> ohne .h), Namespaces konnte ich nicht entdecken.

Das könnte das Problem sein, über das dein Compiler gestolpert ist - die C++ Bibliothek befindet sich komplett im Namensraum std. Und die einfachste Möglichkeit, das Programm lauffähig zu machen, dürfte ein using namespace std; in deinen Quellcode-Dateien sein (jeweils hinter den #include's für die Standard-Header).

DaRpH

erstmal "using namespace std;"
Das fehlt bei den meisten alten Sachen.

Dann schau nochmal wahrscheinlich werden dir Biblotheken noch fehlen.

tntnet

Also wenn ein <iostream> ohne .h vorhanden ist, dann ist entweder ein using namespace std irgendwo oder es werden voll qualifizierte Namen verwendet.

Das Problem ist ein anderes. Es funktioniert definitiv nicht, mit gcc 2.95 object-files zu erzeugen und dann mit gcc 3.3 zu linken. Du musst alles mit gcc 3.3 übersetzen. Du zeigst uns Fehlermeldungen aus diesem Versuch, verschiedene Versionen zu mischen, was genau dieses Resultat hat. Die Ursache liegt im Name-mangling. Aber das nur nebenbei.

Zeige uns doch mal die Fehlermeldungen, die beim compilieren mit 3.3 auftreten. Da können wir möglicherweise helfen.

Tntnet

HumeSikkins

@tntnet

Die Ursache liegt im Name-mangling. Aber das nur nebenbei.

Zwischen gcc 2.95 und gcc 3.x hat sich nicht nur das Name-mangling, sondern das Ganze ABI geändert. Selbst wenn die Namen identisch wären, käme es zu Linkerfehlern.

Also wenn ein <iostream> ohne .h vorhanden ist, dann ist entweder ein using namespace std irgendwo oder es werden voll qualifizierte Namen verwendet.

Meines Wissens nach stimmt für den gcc 2.95 nicht. Dort waren die Namen der Standard-Header nicht alle in std bzw. wurden sie auch in den globalen NS importiert.

erin

Wie vorgeschlagen, habe ich den Quelltext nun über den gcc 3.3 laufen lassen. Der Compiler steigt schon beim 3. Objektfile aus, so dass die Fehlerliste überschaubar ist. Ich hoffe, auch aufschlussreich:

g++ -c grsh.C
g++ -c Common.C
g++ -c DualEdge.C
In file included from DualVertex.h:10,
                 from DualEdge.C:6:
Point.h:90: error: ISO C++ forbids declaration of `ostream' with no type
Point.h:90: error: `ostream' is neither function nor member function; cannot be
   declared friend
Point.h:90: error: Fehler beim Parsen before `&' token
In file included from DualEdge.C:6:
DualVertex.h:34: error: ISO C++ forbids declaration of `ostream' with no type
DualVertex.h:34: error: `ostream' is neither function nor member function;
   cannot be declared friend
DualVertex.h:34: error: Fehler beim Parsen before `&' token
DualVertex.h:69: error: ISO C++ forbids declaration of `ostream' with no type
DualVertex.h:69: error: `ostream' is neither function nor member function;
   cannot be declared friend
DualVertex.h:69: error: Fehler beim Parsen before `&' token
In file included from DualEdge.h:9,
                 from DualEdge.C:7:
Vector.h:105: error: ISO C++ forbids declaration of `ostream' with no type
Vector.h:105: error: `ostream' is neither function nor member function; cannot
   be declared friend
Vector.h:105: error: Fehler beim Parsen before `&' token
make: *** [DualEdge.o] Fehler 1

grsh enthält main (), und in Common steckt nur eine leere Klasse. Was die Namespaces betrifft: Es sind wirklich keine im Text enthalten.
Reinhard

CStoll

Ja, das ist der Klassiker - da fehlt das "std::" vor der ostream (und möglicherweise einigen weiteren Bezeichnern der Standard-Bibliothek, die der Compiler gar nicht mehr kontrolliert hat), also stuft der Compiler den Namen als potentielle Variable ein (solange er es nicht besser weiß, gilt alles als Variablenname) und beschwert sich über die fehlende Typ-Angabe.