4. VS2022 C++ LIB-Project vs. EXE-Project (Verständnis Lib-Abhängikeiten)

VS2022 C++ LIB-Project vs. EXE-Project (Verständnis Lib-Abhängikeiten)

  • S

    Guten Morgen Gemeinschaft,

    ich habe ein paar Problem(chen) hinsichtlich lib Abhängigkeiten in einer Vs Solution, und zwar folgendes:

    Ich habe ein LIB Projekt, und habe hoer einen "Service" (Pseuod):

    Lib.h

    class Service
{
...
public:
void DoSomeThing();
....
}

    Lib.cpp

    #include "Service.h"
#include "ThirdPartyLib.h"

void Service::DoSomeThing()
{
  ThirdPartyLib::Foo x; // <-- linker probleme ();
}

    Exe file:

    #include "Lib.h"

int main()
{
   Service x;
   x.DoSomeThing();
}

    in meiner Exe habe ich unter folgend abhängigkeiten

    • C\C++\Allgemein\Zusätzliche Includeverzeichnisse: lib.h
    • Linker\eingabe\Zustäzliche Abhängikeiten : lib.lib

    in meiner Lib habe ich diese :

    • C\C++\Allgemein\Zusätzliche Includeverzeichnisse: thirdParty.h
    • Bibliotheksprogramm\Allgemein\Zusätzliche Biliotheksverzeichnisse : "thirdParty.lib"

    Wenn ich nun meine exe kompliere, kommen Linker meldungn LNK2019, dass es die thirdparty.lib nicht auflösen kann!?
    aber ich dachte dass diese schon statisch in meiner lib drin hängt!?

    füge ich nun zu meiner Exe die "thirdparty.lib" explizit mit hinzu geht es..

    Wo liegt der Fehler!?

    0

  • Alle Libraries müssen in dem Anwendungsprojekt angegeben werden (bei einem Library-Projekt werden keine weiteren Libraries mitgelinkt, egal ob es sich um statische oder dynamische Libs handelt).

    0
  • S

    @Th69 sagte in VS2022 C++ LIB-Project vs. EXE-Project (Verständnis Lib-Abhängikeiten):

    Alle Libraries müssen in dem Anwendungsprojekt angegeben werden (bei einem Library-Projekt werden keine weiteren Libraries mitgelinkt, egal ob es sich um statische oder dynamische Libs handelt)

    hmm ok danke dir.. dachte ich könnte die thridparty lib kapseln.

    Aber mal angenommen ich möchte den Service austauschbar machen, so dass eine alternativer Service eine alternative ThirdParty2.lib beinhaltet, so muss ich in der Exe auch die alterntavie thridparty.lib austauchen!?

    0
    F
     1 Antwort

  • Ja, (leider) - im Gegensatz z.B. zu der Verwaltung der Assemblies bei .NET.
    Lesenswert: A journey across static and dynamic libraries

    Die einzige Alternative wäre zur Laufzeit die ThirdParty.dll mittels LoadLibrary und GetProcAddress anzusprechen (aber dies ist auch nur mit C-Funktionen zu empfehlen, u.a. wegen dem Name-Mangling bei C++ als auch der Schwierigkeit C++ Klassen damit zu verwenden).

    0
  • S

    @Th69 sagte in VS2022 C++ LIB-Project vs. EXE-Project (Verständnis Lib-Abhängikeiten):

    Ja, (leider) - im Gegensatz z.B. zu der Verwaltung der Assemblies bei .NET.
    Lesenswert: A journey across static and dynamic libraries
    Die einzige Alternative wäre zur Laufzeit die ThirdParty.dll mittels LoadLibrary und GetProcAddress anzusprechen (aber dies ist auch nur mit C-Funktionen zu empfehlen, u.a. wegen dem Name-Mangling bei C++ als auch der Schwierigkeit C++ Klassen damit zu verwenden).

    Ohh ok, danke für Deine Hilfe man lernt nie aus;)

    ja dynamische libs wäre jetzt mal erst ein overkill, noch habe ich nichts austauschbarers;)

    0
  • F

    @SoIntMan sagte in VS2022 C++ LIB-Project vs. EXE-Project (Verständnis Lib-Abhängikeiten):

    @Th69 sagte in VS2022 C++ LIB-Project vs. EXE-Project (Verständnis Lib-Abhängikeiten):

    Alle Libraries müssen in dem Anwendungsprojekt angegeben werden (bei einem Library-Projekt werden keine weiteren Libraries mitgelinkt, egal ob es sich um statische oder dynamische Libs handelt)

    hmm ok danke dir.. dachte ich könnte die thridparty lib kapseln.

    Letztendlich sind statische .lib/.a-Dateien auch nur Archive, welche die Objektdateien beinhalten. Wenn man will, sollte man die auch in ein gemeinsames Archiv kopieren können, so dass dieses dann die Objektdateien beider Bibliotheken enthält. Ich weiss nicht, ob und wie das mit den MSVC-Tools geht, abermit der GCC-Toolchain kannman sowas definitiv machen (Fun fact: 7-Zip kann .lib-Dateien sogar als Archiv öffnen, unterstützt aber leider kein Hinzufügen, sonst könnte man die Objektdateien einfach per Drag&Drop rüberziehen* 😉 ).

    Ich würde davon aber generell abraten, wenn du nicht andere wichtige Gründe dafür hast. Das verlagert nur das Problem der ganzen transitiven Abhängigkeiten, die man bei größeren Projekten hat, von der .exe auf deine "Super-Lib".

    Eine Motivation könnte sein, dass du den Anwendern deiner Lib eine All-In-One-Fire-And-Forget-Lösung anbieten möchtest, und diese nur die eine Lib linken müssen. Aber auch das halte ich für eine schlechte Idee. Wenn die Anwender die thirdParty.lib z.B. auch im eigenen Projekt verwenden wollen, oder eine weitere Lib verwenden, welche diese ebenfalls als Abhängigkeit hat, nagelst du die damit auf die Version fest, die du mit ausgeliefert hast.

    Aber mal angenommen ich möchte den Service austauschbar machen, so dass eine alternativer Service eine alternative ThirdParty2.lib beinhaltet, so muss ich in der Exe auch die alterntavie thridparty.lib austauchen!?

    Du kannst deine eigene Lib auch als .dll bauen. Da werden dann alle Abhängigeiten wie bei einer .exe mit reingelinkt. Dann bräuchtest du nur deine lib.dll.lib oder lib-service2.dll.lib zu linken, wenn du den Service austauschen willst. Für Servicetausch zur Laufzeit würde ich den Ansatz von @Th69 empfehlen.

    *7-Zip beeindruckt mich in der Hinsicht ohnehin: Nicht nur .lib-Dateien, das Program kann z.B. auch PE-Executables (.exe) oder ELF-Executables als Archiv öffnen und man kann sich die Sections da raus-extrahieren. Und in den Datei-Eigenschaften gibts jede Menge Infos, z.B. so Sachen obs eine 32-oder 64-Bit Executable ist. Das Ding hat ein echter Nerd geschrieben 😉

    0
  • S

    @Finnegan sagte in VS2022 C++ LIB-Project vs. EXE-Project (Verständnis Lib-Abhängikeiten):

    Du kannst deine eigene Lib auch als .dll bauen. Da werden dann alle Abhängigeiten wie bei einer .exe mit reingelinkt. Dann bräuchtest du nur deine lib.dll.lib oder lib-service2.dll.lib zu linken, wenn du den Service austauschen willst. Für Servicetausch zur Laufzeit würde ich den Ansatz von @Th69 empfehlen.

    Hey Finnegan, danke für deinen Beitrag, vermutlich werde ich auch rein aus Lerneffekt das ganze mit ner Dll versuchen;)

    EDIT: Wenn ich allerdings Dynamische Bibliotheken werden troztdem eine lib erzeugt bzw. vom host benötigt!?

    Sprich Service1.dll + Service1.lib , für was brauche ich dann denn noch die Lib!? reichen nicht die API (public includes) er library?

    0
Anmelden zum Antworten