Linkerproblem mit Library

Gast #77895
Lesenswert?

Hallo zusammen!

Aus irgendeinem Grund fehlen mir nach dem Linken einige Objekte im
binary.
Es handelt sich hier um die arm-elf Toolchain.
Die Library enthält folgende Objekte:

$ ar -t /cygdrive/c/Programme/GNUARM/lib/libnewlib-lpc.a
_close_r.o
_fstat_r.o
_ioctl_r.o
_lseek_r.o
_open_r.o
_read_r.o
_sbrk_r.o
sys_dev.o
sys_mam.o
sys_pll.o
sys_time.o
sys_vpb.o
uart0_poll.o
_write_r.o

Wenn ich die .o-Files einzeln mit angebe, beim Linken, dann
funktioniert alles wunderbar, verwende ich dagegen NUR die Library,
dann fehlen einige Referenzen. Das .hex-File ist mit Angabe der .o's
ca. 1kB größer als nur mit der Library.

Ich weis nicht, ob ich das jetzt genügend beschrieben habe, falls
nicht, bitte nachfragen!

Vielleicht hat Jörg Wunsch ja auch grad mal Zeit um ein Auge drauf zu
werfen...

Gruß,
Patrick...
Gast #77897
Lesenswert?

Hallo Jörg!

Die Zeile sieht so aus:

$ arm-elf-ld -v -ohello.prg \
cygdrive/c/Programme/GNUARM/lib/newlib-lpc_rel_2/crt0.o \
hello.o -Tlpc210x.ld

(hab die "\" wegen der Lesbarkeit hingemacht)

Ich wundere mich ja gerade, daß es keine ungelösten Symbole gibt.
Wenn ich die .o's mitlinke, wird der Code ja größer und läuft auch auf
dem Zielsystem (im Gegensatz zur Library), also ist da doch irgendwo
eine Abhängigkeit zwischen meinem Code und den objectfiles...!?

Gruß,
Patrick...
Gast #77898
Lesenswert?

Hier mal die Funktionierende Variante:

$ arm-elf-ld -v -ohello.prg \
/cygdrive/c/Programme/GNUARM/lib/newlib-lpc_rel_2/crt0.o hello.o \
/cygdrive/c/Programme/GNUARM/lib/newlib-lpc_rel_2/_close_r.o \
/cygdrive/c/Programme/GNUARM/lib/newlib-lpc_rel_2/_fstat_r.o \
/cygdrive/c/Programme/GNUARM/lib/newlib-lpc_rel_2/_ioctl_r.o \
/cygdrive/c/Programme/GNUARM/lib/newlib-lpc_rel_2/_lseek_r.o \
/cygdrive/c/Programme/GNUARM/lib/newlib-lpc_rel_2/_open_r.o \
/cygdrive/c/Programme/GNUARM/lib/newlib-lpc_rel_2/_read_r.o \
/cygdrive/c/Programme/GNUARM/lib/newlib-lpc_rel_2/_sbrk_r.o \
/cygdrive/c/Programme/GNUARM/lib/newlib-lpc_rel_2/sys_dev.o \
/cygdrive/c/Programme/GNUARM/lib/newlib-lpc_rel_2/sys_mam.o \
/cygdrive/c/Programme/GNUARM/lib/newlib-lpc_rel_2/sys_pll.o \
/cygdrive/c/Programme/GNUARM/lib/newlib-lpc_rel_2/sys_time.o \
/cygdrive/c/Programme/GNUARM/lib/newlib-lpc_rel_2/sys_vpb.o \
/cygdrive/c/Programme/GNUARM/lib/newlib-lpc_rel_2/uart0_poll.o \
/cygdrive/c/Programme/GNUARM/lib/newlib-lpc_rel_2/_write_r.o \
-Tlpc210x.ld
Gast #77899
Lesenswert?

Hmm, tja, ohne ungelöste Referenzen kann er natürlich auch nicht
wissen, was er noch hinzulinken muß...  Was Dir genau fehlt, mußt Du
mal selbst herausfinden.

Eine ungelöste Referenz kann man auch durch -u verursachen (und damit
das Linken des entsprechenden Bibliotheksmoduls erzwingen).
Gast #77900
Lesenswert?

Ich werde mal "selektives Weglassen" der objectfiles ausprobieren
g.
Eigenlich müsste es aber doch mindestens eine ungelöste Referenz geben,
da sonst der Code ja laufen würde...

grübel

Danke für's draufschauen jedenfalls!

Gruß,
Patrick...
Gast #77901
Lesenswert?

Kurze Aufklärung:

In der libc.a befinden sich sog. "dummy-hooks" der Funktionen, die
dann tatsächlich in der newlib-lpc.a implementiert wurden!
Beim erzeugen der libc.a sollte man über einen switch im Makefile
angeben, daß diese Funktionen vom "Portierenden" bzw "Anwender"
bereitgestellt werden. Näheres dazu in der Yahoo-Group, bald im Wiki
oder auf Nachfrage poste ich es nochmal hier.

Thanks for help!

Gruß,
Patrick...
Gast #77902
Lesenswert?

Hallo Ich habe auch gerade probleme mit dem Einbinden von Lib
und zar will ich die vom I2C Bus einbinden jetzt wollte ich fragen
welch einstellung ich vornehmen muß und wo an welcher stelle auch im
Mfile?
MFG jogi

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren