On Mon, Oct 26, 2009 at 9:31 AM, Antoine Labour <[email protected]> wrote: > On Fri, Oct 23, 2009 at 1:58 AM, Anselm R Garbe <[email protected]> wrote: >> The problem is that the chrome >> executable (in particular statically linked in >> libnpGoogleNaClPluginChrome.a) exports 'char >> *NPP_GetMIMEDescription(void)' as a C symbol, which my plugin code >> also implements and calls when NP_GetMIMEDescription() is called by >> the browser. So chrome's Native Client Plugin's >> NPP_GetMIMEDescription() takes preference and is called by my plugin >> code instead of its own build-in NPP_GetMIMEDescription() >> implementation. >> >> [snip] >> >> However, I'm not sure if chrome resp. libnpGoogleNaClPluginChrome.a >> does it right with exporting these symbols as plain C symbols because >> this might conflict with other existing plugins as well in the same >> way. > > http://gcc.gnu.org/wiki/Visibility > Make your plugin compile with -fvisibility=hidden, and only explicitly > export the plugin functions by adding __attribute__((visibility("default"))) > That should fix this, and similar problems. > Though agreed, Chrome should aim to do the same...
I recall looking into this before, but I didn't fully understand what I was doing. I think what you're saying is that Chrome by default exports all its symbols to plugins embedded within it, even if those symbols may conflict with the plugin's symbols. Doesn't NPAPI specify the limited set of symbols (the NPN_*) we should provide, or is there more (like malloc) that are implicitly shared? Since I don't know what I'm talking about, can you file a bug with a recommendation as to what we should be doing? --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
