Gast
#568180
hallo, ich möchte verschiedene Quelldateien je nach Funktion zusammenfassen und die enstandenen Pakete wiederrum gegeneinander linken. Häufig ändert sich nur das main(), der Rest bleibt schlicht gleich. Also wie eine Library, wenn man so will. Gegen die möchte ich dann den anwendungsspezifischen Code linken. Linken tue ich die "library" mit dem avr-ld, aufruf: avr-ld -Map=c.map -o c.elf <die ganzen Object-Files> --defsym=__heap_end=0x0 -L <Pfad zum avr-gcc und avr-libc> -lgcc -lc ok. Verdammt unschick finde ich das leidige Symbol "heap_end". das wird in der c-runtime definiert, wenn ich mich recht entsinne. Auch wenn ich nichts mit malloc am hut habe, ok. Binde ich aber die crtXX ein, hab' ich gleich den ganzen Sack voll Startup-Symbole wie u.a. auch "__do_copy_data" am hals. und ausführbaren code will ich ja noch nicht. afag. Linke tue ich das entstandene .elf mit meiner main.o wie folgt: avr-gcc -mmcu=at90can128 -I. -D GCC_MEGA_AVR -I. -I../../Source/include -I../Common/include -g -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -Wall -Wextra -Wshadow -Wpointer-arith -Wcast-align -Wsign-compare -Waggregate-return -Wunused -Wa,-adhlns=c/c.o -I<die ganzen include-Dirs> c.elf main.o --output co.elf -Wl,-Map=co.map,--cref,--section-start=.text=0x0000 Spätestens jetzt beschwert sich der Linker über ein mehrfach definiertes "__do_copy_data". Das hat er sich aus der libgcc.a schon zum bauen des ersten Pakets (c.elf) geholt. und will das jetzt noch einmal beim Linken zum Executable reinpfrimeln. Die libgcc muss ich aber dank "udivmodh14" und konsorten mit einbinden. Was kann ich tun? Die libgcc.a kann ich nicht weg lassen, funkt mir aber durch ihr(e) symbol(e) dazwischen. Besteht die Möglichkeit, dem Linker zu sagen, dass er zum bauen des ersten Pakets doch bitte schön auf die Initialisierung des Datenbereichs verzichten kann? danke für eure hilfe, ich hoffe, es kam halbwegens verständlich rüber, andernfalls bescheid geben, und ich versuch's noch einmal, bye kosmo