ARM Keil uVision .lib einbinden

analogon schrieb:
> #ifndef __INTERFACE_H
> #define __INTERFACE_H

Bezeichner die mit doppeltem Unterstrich, oder Unterstrich+Großbuchstabe 
anfangen, sind verboten.

analogon schrieb:
> extern int calculate_numbers(int a, int b);

Das "extern" hat an Funktionen absolut keine Wirkung und ist 
überflüssig.

analogon schrieb:
> Ich habe auch berücksichtigt, dass beim einbinden der .lib File in
> Projekt-A das object-file (in diesem Fall die interface.o) auszuwählen
> ist.

Hä? Ich kenne mich mit µVision nicht besonders aus, aber eigentlich 
sollte die .lib das .o enthalten.

analogon schrieb:
> Jedoch habe ich beim einbinden in meinem Hauptprojekt, keine Chance
> einen Zugriff auf meine Funktionen zu bekommen.

Was passiert denn, wenn du ganz frech calculate_numbers(1,2) aufrufst, 
nachdem du die interface.h inkludiert hast? Sagt der Compiler, "Ätsch, 
keine Chance"?

Dr. Sommer schrieb:

> Hä? Ich kenne mich mit µVision nicht besonders aus, aber eigentlich
> sollte die .lib das .o enthalten.
 Tut es ja, jedoch muss bei KEIL nochmal gewählt werden, welche objekte 
verwendet werden sollen.

> analogon schrieb:
>> Jedoch habe ich beim einbinden in meinem Hauptprojekt, keine Chance
>> einen Zugriff auf meine Funktionen zu bekommen.
>
> Was passiert denn, wenn du ganz frech calculate_numbers(1,2) aufrufst,
> nachdem du die interface.h inkludiert hast? Sagt der Compiler, "Ätsch,
> keine Chance"?
Beim einbinden der interface.h bekomme ich ein "No such file or 
directory"


Wird das Einbinden der interface.h weg gelassen, wird der Aufruf der 
calculate_number-Funktion im Projekt-A als implicit declaration 
gedeutet...


viele Grüße

analogon schrieb:
> Beim einbinden der interface.h bekomme ich ein "No such file or
> directory"

Dann musst du das Verzeichnis, welches die interface.h enthält, zum 
Inklude-Pfad des Projekt A hinzufügen. Nur die .lib hinzufügen reicht 
nicht.

analogon schrieb:
> Wird das Einbinden der interface.h weg gelassen, wird der Aufruf der
> calculate_number-Funktion im Projekt-A als implicit declaration
> gedeutet...

Normal.

Ok da hätte ich auch drauf kommen können.

Ich dachte als, dass es nicht mehr nötig wäre die Files nachträglich zu 
inkludieren :-)



Danke dir !


Beste Grüße

analogon schrieb:
> Ok da hätte ich auch drauf kommen können.
>
> Ich dachte als, dass es nicht mehr nötig wäre die Files nachträglich zu
> inkludieren :-)
>
> Danke dir !
>
> Beste Grüße


Aber dann kann ich doch im Grunde die .lib weg lassen und wie immer mit 
den .h/.c files arbeiten?

Welchen Zusatznutzen bringt mir dann die .lib?

analogon schrieb:
> Welchen Zusatznutzen bringt mir dann die .lib?

Dass der Nutzer von Projekt A den Quellcode der Library nicht sehen kann 
(für proprietäre Software) und dass du nicht für jedes Projekt, welches 
die Library nutzt, alle .c Dateien kompilieren musst, was je nach Größe 
der Library länger dauern kann.

Jan K. schrieb:
> Woher wüsstest du ohne Header denn sonst, wie die Funktionen
> heißen und wie sie aufzurufen sind?
>
> Der header soll (oder sollte) alle öffentlich zugänglichen Funktionen
> und ggf. eine kurze Dokumentation enthalten, die zur Benutzung der lib
> benötigt werden. Dem Linker versprichst du damit, dass er diese
> Funktionen irgendwo in den .o files findet.

Das sehe ich ja ein.
Aber fehlt das .c file, funktioniert auch das nicht.

Also muss ich nach wie vor die .c und .h inkludieren, bzw dessen Pfad ?


Viele Grüße

analogon schrieb:
> Also muss ich nach wie vor die .c und .h inkludieren, bzw dessen Pfad ?

Nein, nur die .h ! Das Kompilat der .c ist in der .lib enthalten.