site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com OK, I hope my goal is clear now :-) Stéphane On Oct 14, 2009, at 4:40 PM, Peter O'Gorman wrote: Hello, On Oct 13, 2009, at 4:30 PM, Peter O'Gorman wrote: Hello, Peter -- Peter O'Gorman http://pogma.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... Here's the real problem that I'm trying to fix in an "elegant" way (I can already fix it, but in a very inelegant way). ObjC 2.0 in 64 bits introduced the ability to not export the symbols of a class and metaclass: <http://developer.apple.com/mac/library/releasenotes/Cocoa/RN-ObjectiveC/inde...

I have a bundle for Mail, which uses the (quite private) Message framework; both Mail and Message framework used to export all their classes (which were easily to retrieve using class-dump), unfortunately it's no longer the case: everything in Mail and Message framework is private, no class/meta-class symbols are exported. This prevents me from subclassing a private class of Message framework nor writing a category on it, without writing some ugly code using class and method swizzling. The idea I have is to write a bundle A that wouldn't use any of the private classes, but would modify the dyld symbol tables and make these private classes no longer private by adding their symbols to dyld tables. Then my bundle A would load the bundle B which is weak- linked to Message framework, and add subclasses and categories to previously private classes. When bundle B is loaded, there are no more private classes, because bundle A registered all the '_OBJC_CLASS_ $_ClassName' and '_OBJC_METACLASS_$_ClassName' needed symbols to dyld tables (it's easy to do introspection in ObjC runtime and get the addresses of the classes and metaclasses). This way of doing things would allow me to still subclass and write categories on private Message classes without having to modify my code and doing class and method swizzlings. On 10/14/2009 08:56 AM, Stéphane Corthésy wrote: On 10/13/2009 02:55 AM, Stéphane Corthésy wrote: For some reason (that I'll explain later), I need to load a bundle which contains symbols undefined in application libraries. BUT, though these symbols are undefined, the actual implementations are present in current runtime, but under a different symbol. Thus, before loading that bundle I need to manually tell dyld that symbol 'my_renamed_function' should be bound to 'my_original_function' already present in system libraries. Or I need a hook that would allow me to do that while loading the bundle. I'm working on 10.6. I tried to look at dyld source code, but got lost :-) I tried to use NSInstallLinkEditErrorHandlers, but my handler wasn't invoked. So, is there a way to do that, and how? Why do you need to do this? There are very likely alternative ways of doing what you need e.g. weak undefined external symbols, That cannot work. As I wrote, the bundle (already weakly linked) has symbols that are not available on 10.6 (they were on 10.5), BUT though the symbols are not exported, the actual functions are available in 10.6, thus I'd like to create a bundle which would augment dyld symbol table and then load the other bundle with (previously unknown) symbols, and it would link well. I am still unsure what you're trying to fix. If I am reading this right, the bundle is using OS symbols that were global and exported in 10.5, but have become local symbols in 10.6, and you want it to keep using them (because you're using a third party plugin and you don't have access to the source code?). You could certainly load a library on 10.6 (or use DYLD_INSERT_LIBRARIES) that provides functions with the names your plugin uses, goes through the symbol tables looking for the address of the local-on-10.6 symbols, and calls them. How to do that is documented in the header files in /usr/include/mach-o and on developer.apple.com. However, if you have access to the source code for the bundle, then I suggest fixing it so that it does not require private symbols. This email sent to site_archiver@lists.apple.com