![]() |
AW: LoadLibrary unter iOS
Die gibst Du bei der Funktionsdeklaration mit external an, wie unter Windows auch. Aufrufkonvention muß aber cdecl sein und der Linker muß sie finden können.
Delphi-Quellcode:
function MyLibfunc : LongInt cdecl; external 'Mylib.a' name 'MyFunc';
|
AW: LoadLibrary unter iOS
Ah verstehe, also die Bibliothek in den Programmpfad und mit external Libname verlinken. Manchmal stelle ich mich auch blöd an. Zumindest scheint der Linker jetzt die Bibliotheken mit einzubeziehen. Allerdings liefert er jetzt fehlende Symbole wie _kCFHTTPAuthenticationSchemeBasic etc.
Ich denke mal da muss ich wohl mal sehen was ich an fehlenden Frameworks noch einbinden muss. Vielen Dank für die schnellen Tips von euch :) |
AW: LoadLibrary unter iOS
Komisch ich habe die CFNetwork, AudioToolbox als fehlende Frameworks hinzugefügt, dann importieren geklickt, aber der Linker moniert immer noch die fehlenden Funktionen.
|
AW: LoadLibrary unter iOS
Wenn Apple das dynamische Laden im iOS verbietet, warum gibt es dann überhaupt diese Funktion? (OK, ausgewählte Apps, vorallem die von Apple, dürfen das vermutlich doch)
Bzw., wäre es zumindestens nicht angebracht, wenn Emba derartige Funktionen (wie das dlopen) wenigstens entsprechend markiert? z.B. via deprecated oder plattform "Achtung: Das dynamische Laden ist im iOS verboten." |
AW: LoadLibrary unter iOS
Das dynamische Laden ist unter iOS nicht verboten. Du bekommst eine App nicht in den App-Store, wenn Du das machst - aber auf Ebene des Betriebssystem ist dlopen() ein regulärer Aufruf. Die Beschränkung ist im AppStore zu suchen, nicht im Betriebssystem. Wenn Du mit Deiner App nie in den AppStore willst, kannst Du das schon machen. In Xcode ist die Möglichkeit, dynamische Bibliotheken zu erstellen, per Standard deaktiviert, aber mit minimalen Änderungen an Config-Dateien geht das sehrwohl.
|
AW: LoadLibrary unter iOS
Ich denke ich hab das verstanden und soweit macht das auch Sinn. Man könnte ja sonst eine Lib nachladen und diese ausführen. Da gibts sicher auch andere Wege für so einen Schabernack.
Was mich jetzt nur wundert ist, wie ich die Frameworks für die zu linkende Bibliothek einfügen kann. Für AudioToolbox habe ich folgendes ertrickst:
Delphi-Quellcode:
Ich mag nur nicht auf diese Weise die noch fehlenden Frameworks hinzufügen. Gibts da nicht eine einfachere Methode das einzubinden?
const
libAudioToolbox = '/System/Library/Frameworks/AudioToolbox.framework/AudioToolbox'; procedure AudioServicesPlaySystemSound( inSystemSoundID: integer ); cdecl; external libAudioToolbox name _PU + 'AudioServicesPlaySystemSound'; |
AW: LoadLibrary unter iOS
Speziell für den Audiomanager gibt es in FMX schon relativ viel. Nur keine SystemSounds. Und ja, das Einbinden von Frameworks die nicht direkt unterstützt werden verusacht zusätzlichen Tipp-Aufwand.
Deshalb hat EMBO dafür wohl auch automatische Tools. Aber die rücken sie nicht raus. Für Android gibt es schon 3 in freier Wildbahn, für iOS hat wohl noch niemand gewagt weil das ja ein objectiveC-Lexer und Parser sein müsste. |
AW: LoadLibrary unter iOS
Ich brauchte den Audiomanager ja nicht, aber eines der gelinkten Bibliotheken. Das gleiche gilt für CFNetwork. Ich hab mir jetzt so beholfen jeweils eine Funktion von beiden Frameworks zu linken. Auch wenn ich die nicht benötige. Wäre halt praktisch das etwas einfacher zu gestalten. Über die Projektoptionen ging das irgendwie nicht.
Dennoch nocheinmal vielen Dank für die schnelle Hilfe, mittlerweile kompiliert es und scheint auch zu laufen :) |
Alle Zeitangaben in WEZ +1. Es ist jetzt 02:16 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz