I am trying to run a Haskell program that depends on the Awesomium library. I've compiled it but ran into the following issue at runtime:
Roughly translated, it says that the procedure start address for awe_history_entry_get_visit_count cannot be found in the DLL file [path to my executable].
It seems like it is trying to load that symbol from my program rather than awesomium.dll.
I'm on Windows 10
I'm using stack as my build tool
The program is 32-bit (i386), because that is the only architecture Awesomium supports
I've referenced the DLLs I need in the extra-libraries field in the .cabal file
Any help or hints will be much appreciated.
I eventually managed to solve it on my own. Turns out I was trying to link to a more recent version of the Awesomium SDK.
Having downgraded to Awesomium 1.6.5 and replaced the DLLs in my build folder with the older ones, I am now able to initialise the WebCore and create WebViews.
Unfortunately, I still haven't been able to render any HTML (stuck on loading), but that's for another question...
Related
I have read that incremental linking and non-incremental linking should be functionally equivalent, but I have recently found a situation where this is not the case, and it's kind of baffling me. It that out that my project's build is unable to explicitly load one DLL (out of many) that contains a wxWidgets GUI element during runtime without incremental linking (/INCREMENTAL) enabled.
To give a little context, I have the following targets built by my project:
main.exe
core.dll
foo.dll
bar.dll
core.dll contains general functions that are used by all other projects. main.exe is a desktop GUI application (using wxWidgets) that explicitly loads foo.dll and bar.dll at runtime via "LoadLibraryW". "GetProcAddress" is then used to request GUI elements from within the DLLs to be displayed, which is all done asynchronously via wxEvent. This has worked as intended for the most part. However, I have found that an issue arises when the main.exe is not incrementally linked.
Specifically, when main.exe is not linked with a core.dll that was linked with /INCREMENTAL, and when my project is implicitly linked to the release build of wxWidgets (which is not incrementally linked), foo.dll crashes at runtime on allocation of a new wxPropertyGrid, or wxPropertyGridManager (have tried both). The exception is thrown within "wxmsw30u_propgrid_vc_x64_custom.dll", which is clearly the property grid DLL. Since the debug version of wxWidgets is incrementally linked and does not crash, I was unable to get further information than this.
That is to say, when using the Release DLL version of wxWidgets, my project works if and only if a core.dll is linked with /INCREMENTAL and then linked into main.exe, regardless of whether or not main.exe is linked incrementally. foo.dll can be linked with a core.dll that was linked with /INCREMENTAL:NO and still be opened correctly by main.exe so long as that condition is satisfied. There are no problems with the Debug DLL version of wxWidgets, which is built with /INCREMENTAL.
That summarizes my specific problem. Since the actual code spans several files long, I've decided to reduce this question to the fundamental problem: how could incremental linking enable what I presume to be a faulty build to run successfully? I'd like some insight into this question in particular since it is truly baffling to me.
EDIT: Specifically, I am using wxWidgets-3.0.4 on Visual Studio 2019 targeting the latest Windows 10 SDK. The machine architecture is x64. I am building the project with CMake and have experienced no such issues on Linux when linking with g++-6.3.0 and using dllopen in place of LoadLibraryW.
I have windows dynamic linked library which I want to access from Linux environment. I don't have the source code of that library, so I cannot build .so file.
Is there a way by using Winelib or any other library or tool for converting library file to .so file, so that I can call functions defined in that library?
There is no easy way to do it, because the DLL cannot run in Linux enviromnemt all by itself. It will probably rely on user32.dll msvcrt.dll and friends at runtime, so you'll have to provide those files as well.
You can use winelib, but it doesn't just convert a .dll to an .so. You'll have to link the whole project that wants to call the DLL against winelib, and include the DLL itself with your app at runtime. If you are trying to port a Windows app to Linux, winelib will be able to convert your makefile for you, but it's far from automatic for complex projects.
I have been a long-time visual studio developer, and I am trying to switch over to using mono so I can port my applications to Ubuntu. I have been trying to get some of my VS2010 C++ projects (.vcxproj file types) to load into MD on my Ubunutu 12.04 machine. According to the documentation I have read online this should work, however, every time I try and load a project I get the error shown below. Is there something else I need to be installing in order to be able to load C++ projects in monodevelop? I have done some searching, but have not yet found anything related to this particular question.
VC2010Test.sln(4): Unsupported or unrecognized project : '/home/me/Projects/Test/VC2010Test/VC2010Test.vcxproj'.
Thanks
MonoDevelop has a C/C++ binding, called CBinding.
But:
Beware, it's not meant to target managed C++.
AFAIK, it only works in Unix-like platforms.
So, if you still target non-managed C++ and are not using MonoDevelop for Windows, two questions:
Did you make sure that the binding (addin) is installed and enabled?
If the answer to the above question is yes, you may want to try this: the binding creates projects with the extension ".proj" by default, I think, so maybe you can change this to ".vcxproj", recompile, and test again. If it works, then it should be easy to create a pull request to include this extension of possible file types that this addin can handle?
I am using OpenCV 2.3.1 Win Superpack on MS Visual C++ 10.0.4 on MS Windows 7. Some OpenCV functions run file but cv::cvtColor seems to call msvcp80d.dll, msvcr80d.dll, gpsvc.dll, IEShims.dll and sysntfy.dll. When I add them to my search path I get the following message.
The procedure entry point
?free#allocate_root_with_contect_proxy#tbb##QBEXAAVtask#3##Z could not
be located in the dynamic link library tbb_debug.dll.
Dependency Walker says that I have 64-bit versions of SYSNTFY.DLL and GPSVC.dll where I need 32-bit versions but I copied the files from the System 32(C:\windows) directory. Maybe I need to download the 32-bit versions of those two DLLs but I have not been able to find them on the web.
Many thanks in advance,
Peter.
The superpack is built agsinst vs2008 - if you want to use debug builds with vs2010 it's easier to just build it from source with vs2010
I m working on android application in which I used JNI for native c code.
I build this application on android 2.0 version and ndkr3 and it works fine.
Now when I changed the android sdk version 1.5 and api version 3 I faced problems of unable to open library libtest_demo.so.
05-13 16:54:23.603: INFO/dalvikvm(1211): Unable to dlopen(/data/data/org.abc.test_demo/lib/libtest_demo.so): Cannot find library
I put the libtest_demo.so file at the same place /data/data/org.abc.test_demo/lib/libtest_demo.so but still the same problem arises.
In my java file I called native libraries like,
System.loadLibrary("abc_jni");
System.loadLibrary("test_demo");
And from the logcat I seen both libraries used same memory address.
This is logcat output
05-13 17:56:15.732: DEBUG/dalvikvm(9897): Trying to load lib /data/data/org.abc.test_demo/lib/libabc_jni.so 0x437317f8
05-13 17:56:15.732: DEBUG/dalvikvm(9897): Added shared lib /data/data/org.abc.test_demo/lib/libabc_jni.so 0x437317f8
05-13 17:56:15.742: DEBUG/dalvikvm(9897): Trying to load lib /data/data/org.abc.test_demo/lib/libtest_demo.so 0x437317f8
05-13 17:56:15.752: INFO/dalvikvm(9897): Unable to dlopen(/data/data/org.abc.test_demo/lib/libtest_demo.so): Cannot find library
This error almost always says "Cannot find library" and there can be many reasons for this. What is annoying is that in most cases it is not the missing library but something else. Reasons I have stumbled upon:
library is missing from the directory (obviously),
library that is dynamically linked with your library is missing,
system library versions on the device/emulator that your library uses differ with those that you were linking against in compile time (missing symbols, etc.)
I have described a method that worked for me when resolving an issue with library that was working fine on emulator and was failing to load on Nexus One, maybe this will help you: http://mpigulski.blogspot.com/2010/09/debugging-dlopen-unsatisfiedlinkerror.html