We currently assume that plugins using the old-style NPP apis are CFM, and, if you try to make a Macho one, we'll crash when it tries to call back via CFM T-Vectors. I don't see any reason not to suppport old-style MachO plugins; we need it for the default plugin (bug 166998), for one.
Created attachment 104230 [details] [diff] [review] patch to allow loading of old-style Macho plugins This patch allows the loading of Macho plugins by: 1. requiring that such plugins use a main entry point named "mainMachO" 2. not wrapping the function pointers for such plugins (both plugin and netscape tables) with T-Vector glue. Is requiring a different entry point name a good thing? NSPR can't tell us what the format of the library is (suckage), so this seems like a reasonable solution.
cc wtc who may wish to comment on the inability to determine the format of a library (CFM vs. Macho) given a PRLibrary*.
Status: NEW → ASSIGNED
Simon, I don't know what you want me to say. Do you want me to confirm the inability to determine the format of a library given a PRLibrary*, or do you want me to add a function to determine that? Mac is the only platform on which there are multiple executable formats of dynamic load libraries. NSPR seldom provides a function that's only useful on one platform. It should be simple to add such a function though because the format of a library is stored in the PRLibrary structure.
I'm going to WONTFIX this. The plugin API specifies that plugin entry points are CFM TVectors, so MachO plugins will have to provide compatible function pointers. See the patch in bug 166998 for the default plugin for an example of how to do this.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.