Re: Migrating shared library plugins to Cocoa Touch Frameworks

On 04.12.2016 at 23:13 Jens Alfke wrote: > Use a “.exp” file. It simply lists symbols, one per line. They need > to have the same naming convention the linker gives them, so most > symbols should have an “_” prefixed to them. Then there’s a target > build setting named something like “Use

Re: Migrating shared library plugins to Cocoa Touch Frameworks

> Le 4 déc. 2016 à 21:41, Andreas Falkenhahn a écrit : > > I've now implemented plugin support using dlopen() in my app and > it works fine so far. > > However, it seems like *all* symbols are exported to the dylib > inside the Cocoa Touch Framework. How can I configure

Re: Migrating shared library plugins to Cocoa Touch Frameworks

> On Dec 4, 2016, at 12:41 PM, Andreas Falkenhahn > wrote: > > However, it seems like *all* symbols are exported to the dylib > inside the Cocoa Touch Framework. How can I configure Xcode to > export only certain symbols? I want to name the symbols that > should be

Re: Migrating shared library plugins to Cocoa Touch Frameworks

I've now implemented plugin support using dlopen() in my app and it works fine so far. However, it seems like *all* symbols are exported to the dylib inside the Cocoa Touch Framework. How can I configure Xcode to export only certain symbols? I want to name the symbols that should be exported

Re: Migrating shared library plugins to Cocoa Touch Frameworks

> On 3 Dec 2016, at 12:00, Andreas Falkenhahn wrote: > > On 03.12.2016 at 00:40 Jens Alfke wrote: > >> dlopen is hardly undocumented; it’s part of the core BSD Unix >> library. It’s got a man page and everything. > > That doesn't mean that it's ok to use it on iOS

Re: Migrating shared library plugins to Cocoa Touch Frameworks

Okay, enough with the F.U.D. which I already addressed. If you really want answers, go search the details yourself; they are there but maybe not as well found anymore, and some are mentioned in related WWDC talks. As for the new point, all dylibs must be part of an existing installation and

Re: Migrating shared library plugins to Cocoa Touch Frameworks

On 03.12.2016 at 00:40 Jens Alfke wrote: > dlopen is hardly undocumented; it’s part of the core BSD Unix > library. It’s got a man page and everything. That doesn't mean that it's ok to use it on iOS because of the sandbox. You aren't allowed to use other standard BSD functions like exit(),

Re: Migrating shared library plugins to Cocoa Touch Frameworks

> On 3 Dec 2016, at 00:40, Jens Alfke wrote: > > >> On Dec 2, 2016, at 2:17 PM, Andreas Falkenhahn > > wrote: >> >> Well, just because apps that use undocumented features aren't rejected from >> the >> app store

Re: Migrating shared library plugins to Cocoa Touch Frameworks

> On 2 Dec 2016, at 23:17, Andreas Falkenhahn wrote: > > On 02.12.2016 at 22:55 Pascal Bourguignon wrote: > >> You would just embed the framework, without linking it. > > I'm not very familiar with the latest Xcode so does this mean I should add > my framework to

Re: Migrating shared library plugins to Cocoa Touch Frameworks

> On Dec 2, 2016, at 2:17 PM, Andreas Falkenhahn wrote: > > Well, just because apps that use undocumented features aren't rejected from > the > app store doesn't make it official for me. dlopen is hardly undocumented; it’s part of the core BSD Unix library. It’s got a

Re: Migrating shared library plugins to Cocoa Touch Frameworks

Documentation on Apple’s site is sometimes difficult to peruse (a whole other thread and, arguably, always difficult nowadays), but I can guarantee you that it has been documented somewhere and is supported. I’ve been involved in the process of using this process to load one version of a

Re: Migrating shared library plugins to Cocoa Touch Frameworks

On 02.12.2016 at 22:55 Pascal Bourguignon wrote: > Yes, it’s “official”. > I’ve read the document about what is allowed and rejected for the > AppStore, and this is not rejected. Well, just because apps that use undocumented features aren't rejected from the app store doesn't make it official

Re: Migrating shared library plugins to Cocoa Touch Frameworks

> On 2 Dec 2016, at 15:37, Andreas Falkenhahn wrote: > > On 02.12.2016 at 07:57 Pascal Bourguignon wrote: > >> Yes, dlopen is supported in iOS 8 and following. > > Is this support official or does it just work by chance and might stop > working in the > future? I've

Re: Migrating shared library plugins to Cocoa Touch Frameworks

On 02.12.2016 at 18:21 Jens Alfke wrote: > Don’t build a framework and don’t link the app with it. Just build > a dynamic library and export the symbols for the entry points. > (Exactly the same way as you do for macOS.) And what about code signing the dynamic library? -- Best regards,

Re: Migrating shared library plugins to Cocoa Touch Frameworks

> On Dec 2, 2016, at 6:37 AM, Andreas Falkenhahn wrote: > > So how does that work in practice? Should I create a Cocoa Touch Framework, > code sign > it, include it in the "Embedded binaries" section in Xcode in my project and > select > "Optional" for that framework

Re: Migrating shared library plugins to Cocoa Touch Frameworks

On 02.12.2016 at 07:57 Pascal Bourguignon wrote: > Yes, dlopen is supported in iOS 8 and following. Is this support official or does it just work by chance and might stop working in the future? I've tried to find an official word from Apple concerning dlopen() on iOS but I haven't been

Re: Migrating shared library plugins to Cocoa Touch Frameworks

> On 2 Dec 2016, at 01:31, Jens Alfke wrote: > > >> On Dec 1, 2016, at 7:58 AM, Andreas Falkenhahn >> wrote: >> >> My app supports external plugins. On macOS, Linux, and Windows those plugins >> are just shared objects/dylibs (or DLLs) loaded via

Re: Migrating shared library plugins to Cocoa Touch Frameworks

> On Dec 1, 2016, at 7:58 AM, Andreas Falkenhahn wrote: > > My app supports external plugins. On macOS, Linux, and Windows those plugins > are just shared objects/dylibs (or DLLs) loaded via dlopen() (or LoadLibrary() > on Windows) at runtime. Does iOS still not support

Migrating shared library plugins to Cocoa Touch Frameworks

My app supports external plugins. On macOS, Linux, and Windows those plugins are just shared objects/dylibs (or DLLs) loaded via dlopen() (or LoadLibrary() on Windows) at runtime. Every plugin needs to export a fixed set of symbols which are then resolved at runtime, e.g. symbols named