Static Library für Simulator umwandeln oder mehrmals einbinden

  • Static Library für Simulator umwandeln oder mehrmals einbinden

    Hi,

    ich habe einen externen Barcode-Scanner von Koamtac hier liegen.
    Vom Hersteller gibt es ein SDK mit dem man mit dem Gerät direkt kommunizieren kann.
    koamtac.com/techDownloads.html

    Wenn ich das SDK herunterlade ist dort ein Demo Projekt enthalten in dem eine static Lib integriert ist.
    Das Demo-Project z.B. läuft nur auf dem Simulator, Lib's sind aber scheinbar für alle Arten dabei (Siehe Screenshot).

    Jetzt zur Frage :)
    Wie kann ich von der "gleichen" Lib mehrere gleichzeitig einbinden?
    Oder ist es möglich diese static Librarys umzuwandeln das diese für alle Typen funktionieren?
    Oder kann ich Xcode irgendwie beibringen das er sich aus der Ordnerstruktur die passende Datei sucht?

    Merci
    Dateien

  • generell ist lipo dein freund.

    in dem fall gibts aber einscheinend keine 64-bit library sondern nur armv7s und armv7.
    also einfach nicht für 64 bit compilieren. ob du damit trotzdem in den ios store kommst, darfst du mich nicht fragen.

    aber eine anfrage an den hersteller schadet sicher nichts ;)

  • Okay ich schau mir das später mal an - danke schonmal :)

    2 Fragen hab ich dazu noch:
    - Können die libs dann den gleichen Namen haben oder checkt Xcode das durch die Ordnerstruktur?
    - Kann ich das ganze Projekt nicht für 64Bit Geräte kompilieren wenn die eine Lib nicht 64Bit tauglich ist? Ich musste nämlich auch auf $(ARCHS_STANDARD_32_BIT) stellen...

  • H1990 schrieb:

    Okay ich schau mir das später mal an - danke schonmal :)

    2 Fragen hab ich dazu noch:
    - Können die libs dann den gleichen Namen haben oder checkt Xcode das durch die Ordnerstruktur?
    - Kann ich das ganze Projekt nicht für 64Bit Geräte kompilieren wenn die eine Lib nicht 64Bit tauglich ist? Ich musste nämlich auch auf $(ARCHS_STANDARD_32_BIT) stellen...


    wenn die lib nicht 64 bit ist kannst du die app auch nicht für 64 bit bauen.

    beim dynamischen linken müssen die libs gleich heisen sonst wirst du probleme bekommen.
    beim statischen wohl auch. beim statischen linken wäre mir lieber dass der linker einen festen pfad der lib verwendet und nicht einfach nur den namen (das kann zu bösen fehler führen wenn man irgendwo in einem build-verzeichnis oder lib-verzeichnis noch eine alte lib rumliegen hat oder das system selbst die gleiche lib hat, jedoch eine uraltversion davon)

  • gritsch schrieb:

    beim dynamischen linken müssen die libs gleich heisen sonst wirst du probleme bekommen.

    Dynamisches Linken ist hier doch nicht relevant.

    gritsch schrieb:

    beim statischen wohl auch.

    Nein, das ist egal. Der Linker nimmt die Lib, und schaut sich an, was da drin ist. Wenn er den Kram nicht verwenden kann (falsche Architektur), verwendet er ihn auch nicht.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    gritsch schrieb:

    beim dynamischen linken müssen die libs gleich heisen sonst wirst du probleme bekommen.

    Dynamisches Linken ist hier doch nicht relevant.

    gritsch schrieb:

    beim statischen wohl auch.

    Nein, das ist egal. Der Linker nimmt die Lib, und schaut sich an, was da drin ist. Wenn er den Kram nicht verwenden kann (falsche Architektur), verwendet er ihn auch nicht.


    er verwendet aber die erste passende die er findet und nicht die, die man mit vollem pfad angibt (man könnte ja davon ausgehen dass diese verwendet wird doch leider ist dem nicht so).

  • gritsch schrieb:

    nicht mehrfach angeben, aber mehrfach im system vorhanden sein.
    ich hatte mal so einen fall dass eine version in den deub-builds lag und diese dann verwendet wurde (und in der gab es ein mem-leak).

    Oh ja, das ist nervig; besonders bei Libs (z. B. iconv, icu usw.), die OSX schon in einer veralteten Version vorinstalliert hat.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    gritsch schrieb:

    nicht mehrfach angeben, aber mehrfach im system vorhanden sein.
    ich hatte mal so einen fall dass eine version in den deub-builds lag und diese dann verwendet wurde (und in der gab es ein mem-leak).

    Oh ja, das ist nervig; besonders bei Libs (z. B. iconv, icu usw.), die OSX schon in einer veralteten Version vorinstalliert hat.


    jup, da gibts keinen anderen weg als eigenen namen verwenden (und nicht nur die versionsnummer mit reinpacken, denn auf einem anderen system hat apple vielleicht genau die version drin - aber wie halt meist mit apples eigenen anpassungen mit denen man ja nicht rechnet ;-))