LoadLibrary unter iOS

[Peter666]

Hi,

ich wollte hier eine dynamische Bibliothek in ein Projekt einbinden. Unter Android geht loadlibrary einwandfrei und die DLL wird auch geladen. Unter iOS will das aber nicht.

Die DLL habe ich im StartUp\Library deployed und lade diese via dll := loadlibrary(PChar(IncludeTrailingPathDelimiter(sys tem.IOUtils.TPath.GetLibraryPath)+'mylib.a');

Ich kann mir nicht vorstellen das Apple das laden von Bibliotheken verbietet, oder?

Peter
PS: Die Datei ist im richtigen Pfad und Fileexists findet diese auch.

[Union]

Zitat:

Zitat von Peter666 (Beitrag 1254884)

Ich kann mir nicht vorstellen das Apple das laden von Bibliotheken verbietet, oder?

Laden kannst Du die Library, aber verboten ist das tatsächlich von Apple, genau wie private Frameworks. So was kriegst Du nicht durch's Review.

[mkinzler]

Apple verbietet dynamisches Nachladen in iOS. Du musst Bibliotheken statisch in die Anwendung binden.

[Sir Rufo]

Es wäre besser wenn du durchgängig TPath benutzen würdest.

Delphi-Quellcode:

TPath.Combine( TPath.GetLibraryPath, 'mylib.a' );

[Peter666]

Hmm, in meinem Fall ist dass die LibAV. Soll das bedeuten ich kann die Bibliothek von FlashAVConverter gar nicht benutzen?

[mkinzler]

Doch, aber du musst statisch linken. (Geht wohl nicht mit der Trial-Version)

[Union]

Dummerweise will iOS einen ANSIstring. Und was sind Ansistrings unter den Mobilen Compilern? BÖÖÖÖSE. Also muss man es so machen:

Delphi-Quellcode:

dll : Thandle
begin
  dll := dlopen(MarshaledAString('/woauchimmer/wasauchimmer.dylib'), RTLD_LAZY);
end;

Die kannst Du benutzen. Aber wenn Du es im AppStore haben willst, musst du die .a - Variante linken.

[Peter666]

Die Frage klingt blöde, aber wie linke ich die Bibliothek? Ich kann ja kaum ein {$L Deploy\libav.a} machen, oder?

[mkinzler]

Nein. Diese muss in die Exe. (In das Projekt aufnehmen)

[Daniel]

Du musst mindestens eine Funktion aus der Bibliothek hart referenzieren, ähnlich wie man es unter Windows kennt mit Funktionen, die als "external" deklariert sind.
Wie man das macht, habe ich mal in meinem Blog beschrieben: https://www.danielwolf.eu/blog/2013/...en-a-libraries. Wenn Du ein zweites Beispiel suchst, fiele mir auf die Schnelle das Barcode-Beispiel von Bruno Fierens (TMS) ein, dort hat er auch eine Bibliothek statisch integriert: http://www.tmssoftware.com/site/blog.asp?post=280. In den Sourcen seiner (freien) Komponente findest Du ein weiteres Beispiel.

[Union]

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';

[Peter666]

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 :)

[Peter666]

Komisch ich habe die CFNetwork, AudioToolbox als fehlende Frameworks hinzugefügt, dann importieren geklickt, aber der Linker moniert immer noch die fehlenden Funktionen.

[himitsu]

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."

[Daniel]

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.

[Peter666]

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:

const
  libAudioToolbox = '/System/Library/Frameworks/AudioToolbox.framework/AudioToolbox';
procedure AudioServicesPlaySystemSound( inSystemSoundID: integer ); cdecl;
  external libAudioToolbox name _PU + 'AudioServicesPlaySystemSound';

Ich mag nur nicht auf diese Weise die noch fehlenden Frameworks hinzufügen. Gibts da nicht eine einfachere Methode das einzubinden?

[Union]

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.

[Peter666]

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 :)