Compile-Fehler treten nur in FBSD auf - wo liegt der Fehler?

Herakles

Profifragensteller
Moin!

Ich habe mich mal ein wenig dra gemacht, einen kleinen Bundesligamanager schreiben zu wollen und habe eine kleine Prozedur innerhalb des späteren Programms bereits fertiggestellt. Bei einem Kumpel, mit dem ich heute per ICQ ein wenig an dem Programm gebastelt habe, kompiliert der Code unter Windows Problemlos durch.

Bei mir jedoch sieht das Spiel folgendermassen aus:


Code:
> gcc41 staerke STAERKE.C
staerke(.data+0x4): multiple definition of `__dso_handle'
/usr/local/lib/gcc/i386-portbld-freebsd5.3/4.1.0/crtbegin.o(.data+0x0): first de                                                                                       
fined here
staerke(.init+0x0): In function `_init':
: multiple definition of `_init'
/usr/lib/crti.o(.init+0x0): first defined here
staerke(.data+0x0): multiple definition of `__progname'
/usr/lib/crt1.o(.data+0x0): first defined here
staerke(.text+0x0): In function `_start':
: multiple definition of `_start'
/usr/lib/crt1.o(.text+0x0): first defined here
staerke(.fini+0x0): In function `_fini':
: multiple definition of `_fini'
/usr/lib/crti.o(.fini+0x0): first defined here
/var/tmp//ccHnLhLf.o(.bss+0x0): multiple definition of `vorz'
staerke(.bss+0x650): first defined here
/var/tmp//ccHnLhLf.o(.text+0xaa): In function `main':
: multiple definition of `main'
staerke(.text+0x130): first defined here
/usr/bin/ld: Warning: size of symbol `main' changed from 228 in staerke to 277 i                                                                                       
n /var/tmp//ccHnLhLf.o
/usr/lib/crt1.o(.dynamic+0x0): multiple definition of `_DYNAMIC'
/usr/lib/crt1.o(.got.plt+0x0): multiple definition of `_GLOBAL_OFFSET_TABLE_'
/var/tmp//ccHnLhLf.o(.eh_frame+0x11): undefined reference to `__gxx_personality_                                                                                       
v0'
collect2: ld returned 1 exit status
                                                                                                                                                                       
[19:57 - herakles@schleppi - ~/fett/studieren/programme/bulimanager]                                                                                                   
>

Was mag das sein? Ein gcc41 -v ergibt:

> gcc41 -v
Using built-in specs.
Target: i386-portbld-freebsd5.3
Configured with: ./..//gcc-4.1-20050508/configure --disable-nls --with-system-zlib --with-libiconv-prefix=/usr/local --program-suffix=41 --with-gxx-include-dir=/usr/local/lib/gcc/i386-portbld-freebsd5.3/4.1.0/include/c++/ --disable-shared --disable-libgcj --prefix=/usr/local i386-portbld-freebsd5.3
Thread model: posix
gcc version 4.1.0 20050508 (experimental)
[20:01 - herakles@schleppi - ~/fett/studieren/programme/bulimanager] >

Ich komm nich weiter. Was mag da faul sein?


Herakles
 
Ja, oenone, das habe ich getan, vorher habe ich mit dem gcc3 gearbeitet, da war dergleiche Fehler, deshalb habe ich den 41 installiert, um auszutesten, ob da evtl. der Fehler liegt.

Scheinbar tritt der Fehler aber mit dem gcc3 und mit dem 41 auf...


Herakles
 
Einfach mal das -o flag vor das Output file und dann wird das auch. Du versuchst nämlich gerade das (wohl schon vorhandene) binary file zu kompilieren ;)

Edit:
Oh, gleichzeitig gepostet :ugly:
 
So, ich habe den Fehler gefunden:

Zum Einen war es keine gute Idee, die Datei STAERKE.C zu nennen, denn die Extension .C bringt den Effekt, dass vorm compilen noch preprocessed wird. (Ehm, moment mal, wird das nicht eh gemacht?)

Naja, jedenfalls wird eine Endung .C anders behandelt als eine Endung .c. Siehe auch

man gcc41

file.C
C++ source code which must be preprocessed. Note that in .cxx, the
last two letters must both be literally x. Likewise, .C refers to
a literal capital C.

Ja, und der zweite Fehler war, dass ich kein "-o" mit eingefügt habe.

Wenn ich jetzt eingeben

Code:
# gcc41 -o test test.c

wird die Datei test aus dem code test.c erstellt.

Herakles
 
Back
Top