On Fri, Oct 23, 2009 at 1:58 AM, Anselm R Garbe <[email protected]> wrote:
> > 2009/10/23 Anselm R Garbe <[email protected]>: > > I rebuilt chromium yesterday from yesterday's tip on Linux (last time > > I did that was about 8 weeks ago or so). I'm involved in developing > > some NPAPI plugins that used to work well with my older chromium linux > > build and that work without any issues in all other NPAPI supporting > > browsers including firefox, Opera and some webkitgtk based ones, such > > as surf. > > > > Anyway, the symptom I see in chromium is this (in about:plugins): > > > > Native Client Plugin > > > > File name: npfoo.so > > Native Client Plugin was built on Oct 22 2009 at 12:28:12 and expires > > on 11/4/2009 (mm/dd/yyyy) > > MIME Type Description Suffixes Enabled > > application/x-nacl-srpc NativeClient Simple RPC module nexe Yes > > > > So the Native Client Plugin somehow overrides the original mime type > > (application/x-vnd-foo-x and foo as suffix) now and makes it > > impossible to use the NPAPI plugin as usual. Also note that this > > Native Client Plugin stuff seems to be totally untested on Linux, at > > least the borken extension "nexe" (.exe?) hints that there seems to be > > something not in sync between code that's used on Windows perhaps? > > > > On the other hand some plugins seem not to be wrapped by Native Client > > Plugin, such as Adobe's PDF plugin (nppdf.so) and I wonder why that's > > the case (is there any hard-coded trusted plugins list somewhere?). > > > > Any insight on how to make it work would be really helpful. > > Ok, I'm a moron and found the issue. 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. > > The original pattern came from some initial mozilla NPAPI plugin > example I started from a long while ago and that contained the pattern > to call NPP_GetMIMEDescription() on returning from > NP_GetMIMEDescription entry point. I never bothered to change that > until now ;) > > This might not happen of course if I'd use a C++ compiler that mangles > the symbols, but my definitions are plain C symbols and hence the > conflict. > > 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... Antoine --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
