2009/10/26 Antoine Labour <[email protected]>: > 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...
I realized that chromium is using this flag now, though I really dislike this gcc specific flag (which wouldn't have the same result with a different compiler anyways). I'd rather recommend to declare those NPP functions static to aim for a more future-proof and portable solution. In my plugin code I fixed the issue through using a different prefix. Anyway, it's up to you what you prefer, just my 2 cts ;) Kind regards, Anselm --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
