When gcc supports hiding all symbols by default, the null plugin and probably all other in-tree plugins are broken, because they don't explicitly mark any symbols as exported. Consequently, the plugin loading code does not find the symbols it needs (NP_GetMimeDescription et al).
Created attachment 206731 [details] [diff] [review] Patch to make the missing NP_* symbols visible I've encountered this problem as well, and the attached patch fixes it for me on Fedora Core 4
Comment on attachment 206731 [details] [diff] [review] Patch to make the missing NP_* symbols visible It's not a good idea to mix the NSPR macros in with mozilla code: I suggest using NS_EXPORT_(type) here.
bsmedberg: this file is part of the plugin SDK, is it not?
Does the plugin SDK depend on NSPR but not mozilla?
does it depend on NSPR?
PR_VISIBILITY_DEFAULT sure does...
yeah, I think this patch is not good because of that
What about using NS_VISIBILITY_DEFAULT and then including "nscore.h" inside npupp.h? Would that work?
The question is, is the plugin SDK allowed to depend on NSPR and/or XPCOM?
ok, so, npapi.h already includes prtypes.h, so clearly the NSPR dependency is ok. please ignore my comments.
Created attachment 218752 [details] [diff] [review] Updated patch for exporting plugin NP_* symbols Compiled this on Unix / Windows / Mac (ppc/x86).
the comment is wrong... it's not the compiler that has the default visibility, it's mozilla's build system which uses a default visibility of hidden on certain compilers.
Created attachment 220548 [details] [diff] [review] Patch for exposing the plugin symbols, i.e. make symbols visibile The previous patch did not really work well, so I've changed from using: #undef IMETHOD_VISIBILITY #define IMETHOD_VISIBILITY NS_VISIBILITY_DEFAULT ... #define IMETHOD_VISIBILITY NS_VISIBILITY_HIDDEN to use: NS_VISIBILITY_DEFAULT for each function that needs to be exposed.
this got fixed in bug 380984