linker errors von gcc++ 2.6.3.

Thread View: de.comp.lang.c++

3 messages

[T] Back to Threads [V] Tree View [G] Group Articles

3 total messages Started by Robert Mueller Tue, 26 Sep 1995 07:51

#472

Author: Robert Mueller
Date: Tue, 26 Sep 1995 07:51

55 lines
2222 bytes

Hallo,

Ich bekomme beim linken einer C++-Datenbank mit gcc 2.6.3. Tonnen von  
"multiple definition" errors der Art

ld: multiple definitions of symbol _peekAtCurrent__t9list_iter1ZP8mapEntry
mapList.o definition of _peekAtCurrent__t9list_iter1ZP8mapEntry in section  
(__TEXT,__text)
mapping.o definition of _peekAtCurrent__t9list_iter1ZP8mapEntry in section  
(__TEXT,__text)

peekAtCurrent wird von einem Template definiert

template <class T> class list_iter
{
   private:
      baseList_Iter *void_Iter;

   public:
      // ... other routines
      T peekAtCurrent();
};

das die beiden Klassen in der linker-Meldung (Mapping.cc und mapList.cc)  
importieren und verwenden (Aufruf von peekAtCurrent).

Ausserdem gibt es in einer Klasse baseList.h noch eine Deklaration von  
peekAtCurrent (void *peekAtCurrent());
die von beiden Klassen importiert wird (fuehrt das zu den multiple  
definitions?)

Hat jemand eine Ahnung, was da schief geht (und wie ein work-around  
aussehen koennte?). Die Autoren der Datenbank haben gesagt, dass sie die  
Datenbank bisher nur mit gcc++ 2.6.0 compiliert haben (verhalten sich  
2.6.3 und 2.6.0 so unterschiedlich?)
 
Im voraus vielen Dank.

Gruss Robert (ein gnu Novize)

___________________________________________________________
Robert Mueller           Tel. (+49) (0) 6131 17 20 22
Medizinische Informatik  Fax. (+49) (0) 6131 17 29 68 (Institute Fax)
Projektgruppe "TheMPO"
Institut fuer Medizinische Statistik und Dokumentation
Universitaetskliniken Mainz


--
___________________________________________________________
Robert Mueller           Tel. (+49) (0) 6131 17 20 22
Medizinische Informatik  Fax. (+49) (0) 6131 17 29 68 (Institute Fax)
Projektgruppe "TheMPO"
Institut fuer Medizinische Statistik und Dokumentation
Universitaetskliniken Mainz

Re: linker errors von gcc++ 2.6.3.

#474

Author: Ullrich von Bassewitz
Date: Tue, 26 Sep 1995 16:27

38 lines
2026 bytes

Robert Mueller (mueller@n1) wrote:
> Hat jemand eine Ahnung, was da schief geht (und wie ein work-around  
> aussehen koennte?). Die Autoren der Datenbank haben gesagt, dass sie die  
> Datenbank bisher nur mit gcc++ 2.6.0 compiliert haben (verhalten sich  
> 2.6.3 und 2.6.0 so unterschiedlich?)

Ich sag's doch:

g++ und templates - zwei Welten begegnen sich.

Was passiert ist folgendes: Die Version 2.6.3 von g++ ist (wie auch schon
die Versionen davor), nicht schlau genug, herauszufinden, wo denn nun die
bei einer Template Instantiierung produzierten Funktionen hingepackt werden
sollen. Wenn der Programmierer nichts weiter unternimmt, und die
Implementation der Templates in ein Header File packt, dann werden diese
Template Funktionen in jedem .o File erzeugt, dessen .cc Gegenpart dieses
Header-File einbindet. Und diese Funktionen haben teilweise external
linkage, d.h. die so erzeugten .o Files lassen sich wegen duplicate
identifiers nicht linken.

Ich habe mich selber eine ganze Weile damit rumgeschlagen und es gibt meines
Wissens keine Moeglichkeit, den Fehler zu umgehen. Man kann auf die
Instantiierung von Templates mit diversen Kommandozeilenparametern und
#pragmas Einfluss nehmen, aber erstens sind das spezielle g++ Konstrukte,
zweitens ist bei g++ 2.7.0 schon wieder alles ganz anders...

Du kannst es mit einer anderen Compiler-Version probieren. 2.5.8 tut hier
einigermassen, hat aber andere, auch etwas nervige Bugs. 2.7.0 koennte auch
tun.

Gruss

        Uz

-- 
Ullrich von Bassewitz                              uz@ibb.schwaben.com

Re: linker errors von gcc++ 2.6.3.

#505

Author: Olaf Pfohl
Date: Mon, 02 Oct 1995 12:01

39 lines
2442 bytes

Ullrich von Bassewitz (uz@wuschel.ibb.schwaben.com) wrote:
: Diese Methode ist nicht compilerunabhaengig, da die verwendeten #pragmas nur
: von gcc verstanden werden und ich deshalb meine Sourcen mit Konstrukten
: zupflastern muss, die nur ein einziger Compiler versteht.

Ab und zu programmiere ich mit dem Borland C++ (ok, in Version 4.0) aber der
beschwert sich jedenfalls nicht "uber die `#pragma interface/implementation'.
Ich benutze in der Tat bei einem Projekt einen einzigen Quellcode, den ich unter
gcc 2.6.3, gcc 2.7.0 sowie Borland C++ 4.0 f"ur DOS und f"ur eine Windows-DLL
compiliere. Nat"urliche sind `#ifdef's' enthalten; diese betreffen aber
*nicht* die Template-Instanziierung (sondern insbesondere den DLL-Kram).
Das funktioniert ganz gut!

: Was tue ich, wenn ein anderer Compiler "#pragma interface" ploetzlich ganz
: anders interpretiert? Natuerlich, die Chance ist nicht besonders hoch, aber
: weisst Du's?

Nein, das w"are sicher ein Problem, falls man alten Code ohne `#pragma
interface/implementation' hat (gefundenes Fressen f"ur eine find-sed-Pipe; so
man regul"are Ausdr"ucke mag nicht sehr aufwendig).

: Ich denke, das Problem ist automatisch dann verschwunden, wenn die g++
: Mannschaft beschliesst, Templates endlich korrekt zu implementieren. Bei
: anderen Compilern tut es schliesslich auch ohne #pragma's in jedem
: Quelltext. Und solange bis das tut warte ich eben. Wenn ich mal ein Programm
: habe, das nur mit dem gcc uebersetzt werden soll, dann kann ich mir immer
: noch ueberlegen, ob ich mich nicht auf das #pragma interface/implementation
: einlasse. Aber bei Programmen mit einigen -zigtausend Zeilen, die auf
: mehreren Plattformen unter mehreren Compilern laufen ist mir das einfach zu
: umstaendlich.

Zustimmung ;-)


Bis dann,
Olaf

--
(signature intentionally left blank)

Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads