I use webview in webkitgtk to open a html file to play flash files on server in my code. But it suggest me that Missing Plug-in. So I want to know how webkit finds libflashplayer.so and what should I do?
The plugin search path on Unix systems is defined in the WebKit source code at WebKit/Source/WebKit2/Shared/Plugins/unix/PluginSearchPath.cpp. Currently it loads plugins from the following locations:
$MOZ_PLUGIN_PATH
$MOZILLA_HOME/plugins
$HOME/.mozilla/plugins
$HOME/.netscape/plugins
/usr/lib/browser/plugins
/usr/local/lib/mozilla/plugins
/usr/lib/firefox/plugins
/usr/lib64/browser-plugins
/usr/lib/browser-plugins
/usr/lib/mozilla/plugins
/usr/local/netscape/plugins
/opt/mozilla/plugins
/opt/mozilla/lib/plugins
/opt/netscape/plugins
/opt/netscape/communicator/plugins
/usr/lib/netscape/plugins
/usr/lib/netscape/plugins-libc5
/usr/lib/netscape/plugins-libc6
/usr/lib64/netscape/plugins
/usr/lib64/mozilla/plugins
/usr/lib/nsbrowser/plugins
/usr/lib64/nsbrowser/plugins
So WebKitGTK+ will find libflashplayer.so if it is installed to one of those locations.
It is in /usr/lib/flashplugin-installer
fullt path:
/usr/lib/flashplugin-installer/libflashplayer.so
Related
I'm trying to run SALOME GUI using run_salome.bat. GUI doesn't start and gives "Can't find a free port to launch omniNamesTry to kill the running servers and then launch SALOME again." error.
SALOME version 9.4
Windows 10
I have searched the files in C:\Users<username>\AppData\Roaming that contain "omniORB_PortManager" in their name and deleted them.
Here the issue can be resolved be removing several files generated by SALOME.
start a Windows file browser
in the search bar, type: %userprofile%\.config\salome
delete all files present in that directory
in the search bar, type: %APPDATA%\salome
remove all files present in that directory
in the search bar, type: %APPDATA%
delete all files wich name starts with: .omni
delete file: .salome_PortManager.cfg
Finally, I strongly suggest to raise such questions directly on SALOME forum at this link
We've installed Sybase 16 Express in our Linux box, it was able to startup right after the installation. When we recently try restarting it with the startserver -f RUN_FILE command, it failed to find the libsapcrypto.so file.
~/sap/ASE-16_0/bin> ../sap/ASE-16_0/bin/dataserver: error while loading shared libraries: libsapcrypto.so: cannot open shared object file: No such file or directory
We searched this file, multiple matches presented in the following paths:
./DM/OCS-16_0/lib3p/libsapcrypto.so
./DM/OCS-16_0/lib3p64/libsapcrypto.so
./DM/OCS-16_0/devlib3p64/libsapcrypto.so
./DM/OCS-16_0/devlib3p/libsapcrypto.so
./DM/REP-16_0/lib64/libsapcrypto.so
./DataAccess/ODBC/lib/libsapcrypto.so
./DataAccess64/ODBC/lib/libsapcrypto.so
./OCS-16_0/lib3p/libsapcrypto.so
./OCS-16_0/lib3p64/libsapcrypto.so
./OCS-16_0/devlib3p64/libsapcrypto.so
./OCS-16_0/devlib3p/libsapcrypto.so
Since this hasn't been answered yet, running this command worked for me:
. /opt/sap/SYBASE.sh
Note the different syntax to make sure the environment variables are set in the terminal session, as opposed to using this syntax:
/opt/sap/SYBASE.sh
I have some code which I am running in debug mode. As I understand it, this runs it through the standard node.js debugger.
I'm frequently getting the following:
...
break in timers.js:77
...
Sometimes I have breakpoints at other files, but they always give absolute file paths, but in this case its just the file name. I cannot find a file with that name which has the content listed on line 77, nor can I find an explanation of how the debugger works in regards to this.
How can I find this timers.js file?
Generally, when you see filenames with no path in the debugger, it means that the file is one of the core libraries that are compiled in to the node binary.
If you want to dig in to source, make sure you're looking at the git tag that matches the version of node you're running.
The builtin files are:
assert.js
buffer.js
child_process.js
cluster.js
console.js
constants.js
crypto.js
dgram.js
dns.js
domain.js
events.js
freelist.js
fs.js
http.js
https.js
module.js
net.js
os.js
path.js
punycode.js
querystring.js
readline.js
repl.js
smalloc.js
stream.js
string_decoder.js
sys.js
timers.js
tls.js
tty.js
url.js
util.js
vm.js
zlib.js
I was trying to convert a pdf into a swf and i was using swftools. To support Chinese, i downloaded xpdf-chinese-simplified.tar and modified the add-to-xpdfrc file like this
#----- begin Chinese Simplified support package (2011-sep-02)
cidToUnicode Adobe-GB1 /usr/local/share/xpdf-chinese-simplified/Adobe-GB1.cidToUnicode
unicodeMap ISO-2022-CN /usr/local/share/xpdf-chinese-simplified/ISO-2022-CN.unicodeMap
unicodeMap EUC-CN /usr/local/share/xpdf-chinese-simplified/EUC-CN.unicodeMap
unicodeMap GBK /usr/local/share/xpdf-chinese-simplified/GBK.unicodeMap
cMapDir Adobe-GB1 /usr/local/share/xpdf-chinese-simplified/CMap
toUnicodeDir /usr/local/share/xpdf-chinese-simplified/CMap
#fontFileCC Adobe-GB1 /usr/..../gkai00mp.ttf
displayCIDFontTT Adobe-GB1 /usr/local/share/xpdf-chinese-simplified/gkai00mp.ttf
#----- end Chinese Simplified support package
When i tried to convert the pdf,
/usr/local/bin/pdf2swf 10434_102_demo_1414995035745.pdf -o test.swf -s
languagedir=/usr/local/share/xpdf-chinese-simplified
an error occured:
Error: Couldn't create a font for 'SimSun'
PS. I have two environments, one is MAC and the other is Redhat, everything is ok in MAC and this error only occurs in Redhat.
As this question is missing an answer, I can add an optional solution (as a workaround) here.
For Flexpaper, if you use the "HTML5" render mode, it will render Chinese, and other unicode text, correctly.
I am trying to test a Mozilla plugin (developed using FireBreath) in the form of an .so shared object file. The plugin was developed on Ubuntu, where it works fine.
I am now trying it under OpenSUSE - so I first symlinked the .so file in ~/.mozilla/plugins:
> ln -s /path/to/npXXX.so ~/.mozilla/plugins/
... and then ran Firefox (7) from command line:
> /path/to/firefox -P myprofile
...
LoadPlugin: failed to initialize shared library libXext.so [libXext.so: cannot open shared object file: No such file or directory]
LoadPlugin: failed to initialize shared library /path/to/npXXX.so [/path/to/npXXX.so: undefined symbol: gtk_widget_get_mapped]
# and the LoadPlugin messages do NOT show a second time - probably because plugin is disabled (via about:addons).
And so I thought to try different stuff to look into this - but first, I restarted Firefox, and realized that on the second run I do not get the "LoadPlugin: failed to initialize" messages anymore! Then I tried removing the plugins symlink, and restarting FF; and adding it again, and restarting FF - still no error messages!
So, this tells me that probably Firefox somehow disabled/blacklisted the plugin (but which one: libXext, npXXX or both?) , but searching (grepping) for (np)XXX in '/path/to/myprofile/blocklist.xml' returns nothing (the plugin should use a email-like id, not those number GUIDs, so I'd expect that string to show in blocklist.xml if it's there).
Does anyone know: is the default behavior of Firefox to disable/blocklist plugins, that fail to load at first? If so, is there a way to force Firefox to load them again (and spit out error messages)? If you'd also have links to where this behavior is documented, it will be much appreciated :)
Many thanks in advance for any answers,
Cheers!
Note: after I stopped seeing the error messages, I did the following:
I am trying "about:plugins": "No enabled plugins found";
then trying "about:addons", and clicking under Plugins: "You don't have any add-ons of this type installed";
This plugin is not embedded in an extension, so nothing new should be added in "about:addons" under "Extensions" - and as expected, nothing new shows there. Under Ubuntu (where all works), just by symlinking the plugin to ~/.mozilla/plugins, the above two locations/screens start showing the plugin info.
This one of the things that puzzle me - if it just showed the plugin as "disabled", maybe I would have had a chance to re-enable it again (to get a new batch of error messages) - however, "about:plugins" and "about:addons" simply show nothing - so there's nothing I can use to enable from there. Which tells me Firefox has used a different method to disable the plugin(s) - but I cannot tell what it is...
Firefox has a cache for XPCOM modules ("fastload cache"), if a module fails to load Firefox won't try again. The cache is reset automatically if an extension is installed or if the application is updated. Starting with Firefox 4 you can also use -purgecaches command line flag to discard the cache.