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. Kind regards, Anselm --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
