I reopened http://code.google.com/p/chromium/issues/detail?id=17943 . Please leave further instructions there and I'll fix it.
On Mon, Oct 26, 2009 at 10:19 AM, David Sehr <[email protected]> wrote: > If what Antoine's saying is true, it has to do with ELF symbol visibility > and the dubious concept of symbol "preemption". The NPAPI interface should > actually only require a small number of symbols be "visible" from the > plugin, and none (the best I know) from the browser. There's an interface > description exchange at the start of the NPAPI module that handles the rest. > There are potential performance penalties on some architectures to permit > symbol preemption, and it certainly inhibits cross-module optimization > (whenever we would get to that in our builds). It would be best if we could > use -fvisibility=hidden for all Linux binaries -- the browser, plugins, > whatever. It would have been better still if the Linux community had made > this crufty feature available on request rather than by default. > David > > On Mon, Oct 26, 2009 at 10:10 AM, Evan Martin <[email protected]> wrote: >> >> 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 -~----------~----~----~----~------~----~------~--~---
