I've created an XPCOM DLL in CPP using Gecko/XULRunner v12 (which works on v12), but when I run it with v13, or v14 of firefox I get the following error:
-Native module at path '...\PowerFoxDll.dll' is incompatible with this version of Firefox, has version 12, expected 14
is it possible that the XPCOM DLL XULRunner SDK is not backward compatible???
Is there a way to solve it?
I'm looking for a solution that will not require re-compiling the code for each new version.
Unfortunately, you are right. There is no backward (and forward too) compatibility between native XPCOM plugin and browser. You have to compile code for each new version of Firefox with accordingly version of XULRunner SDK. Thus, if you want to have an up to date solution you have to update you source code every six week.
There is only one way to make stable working solution - using JavaScript. Google 'js-ctypes' - this is solution allows to use code from native dll into Firefox JavaScript extensions directly.
Related
Example: I want to call libffmpeg.dll in flutter-windows-app. Where should I put the libffmpeg, make it could be packed in release and debug app, so i just use ffi.DyncamicLibrary.open('libffmpeg.dll') to call the native functions ? Should i need to change the windows indrectory? and how to achieve it?
I was also digging this theme for quite a while. I was able to find following infomation:
Each platform requires different way of C/C++ dynamic/static libraries integration, thus it won't be possible to simply add '.dll'/'.so'/etc to, say, '/assets' folder
To include dynamic library in Ios and Android flutter project you have to make several changes in 'ios'/'android' folders respectively
You can try out those materials, they might help you:
Integrating C library in a Flutter app using Dart FFI
Calling Native Libraries in Flutter with Dart FFI
There seems to be a conflict between the version of zlib used in the SDK and what may exist on a user's machine. For example...
On macOS 10.11.6 and Xcode 8, the version of zlib used during compilation doesn't match the version of libz.dylib loaded at runtime. Specifically, the header file used during compilation is for zlib v1.2.8, but the dylib file loaded at runtime is for 1.2.5.
This can result is a runtime crash because it can attempt calling a function that doesn't exist in 1.2.5. The problem is the header (from the SDK) thinks we are using 1.2.8 so it will compile code that is 1.2.8-specific based on any #if defined for a version check.
What then is the best way to link against and use zlib?
Should I compile it as a static lib and ignore the OS supplied version? I am currently doing that and using 1.2.8 in my app, but it may be causing a problem for a user on 10.14.3. I am considering switching to a dynamic lib, but the above situation comes into play there too.
We're developing an SDK for our technology for iOS, the sdk is delivered in a static framework. Our code uses openCV and we link OpenCV into the delivered framework binary.
This normally works well but we're having an issue with a client which is indirectly using a different version of openCV in another framework.
This is causing a conflict and the clients app crashes.
Beside switching to the same version of openCV, removing our openCV dependency or switching to a dynamic library (which allows to hide open CV inside), is there an another option to fix this?
I tried to compile our lib using "Perform Single-Object Prelink and add the openCV libs in "Prelink libraries" but this produced link error when I tried to integrate it and it looks as if it ignored "Prelink libraries", maybe I'm doing something wrong here.
Any thoughts or ideas on the matter would be much appreciated.
I am trying install OpenGL on VS2010.
I use this tutorial.
And I get the following error:
Unable to start program 'C:\Users\s151310\Tutorial 0.3.8\frameworkD.lib'.
The specified file is an unrecognized or unsupported binary format
How can I fix this?
Actually don't have to install anything at all to start OpenGL development with Visual Studio. As long as you limit yourself to OpenGL-1.1 and core Win32 APIs everything is already in place for you.
However to get modern OpenGL features one must use the so called extension mechanism to load pointers to functions of newer versions – a tedious and uninteresting process. Hence extension loader wrappers have been developed.
Also creating a window and setting up a matching OpenGL context is laborous as well. So you want to use some framework for that two.
Extension loader wrappers and frameworks are 3rd party libraries that need to be installed separately.
Unable to start program 'C:\Users\s151310\Tutorial 0.3.8\frameworkD.lib
Why are you trying to execute a library file? This is the framework library that's supposed to be linked into your executables. So this raises the question: How did you setup your project, specifically which build options did you configure. Without that I can't give better advice.
I'm using firebreath to develop a browser plugin in windows xp using visual studio 2010. The plugin uses boost signals, filesystem and system, libcurl libraries.
The plugin builds successfully but gives error while registering it using regsvr32:
LoadLibrary("np<plugin name>.dll") failed. The specified procedure could not be found.
After checking for a while, I found that if I remove the boost signals module, the plugin gets registered. I checked the plugin dll in dependency walker but there were no missing dlls. Though it showed module warning in ADVAPI32.DLL and MPR.DLL. Can anyone help me to solve this problem because I can't remove signals module from my project?
As discussed on the FireBreath mailing list, this could be something that firebreath isn't doing correctly when including its subset of boost. I would recommend trying to build and install boost yourself and then use the external boost flags on the prep script.
You can find the flags you need and others for prep scripts on the Prep Scripts page on the firebreath website.
At the very least you'll need to use "-D WITH_SYSTEM_BOOST=1"; you might need some of the other ones too.
-D BOOST_ROOT="/path/to/boost" - set to path to your Boost installation
-D Boost_ADDITIONAL_VERSIONS="<versions>" - set specific Boost version (e.g. "1.43;1.43.0")
-D Boost_USE_STATIC_LIBS=on
-D Boost_USE_STATIC_RUNTIME=on should be used in windows to force linking to the boost libraries built with /MT(d).