How to connect the library to the project DLL and use the procedure / function?
I have a *.dll, I created *.Def file, created *.dll.a, *.ali and *.o, as its use is not clear.
Set an example for the use of ...
To link with a dll you first have to know the location of the dll library in relation to the where your binary application will be on the user's computer (its file path) -- then use the pragma "Link_With".
If you wanted to link with opengl on windows you would do all of the c imports into a package spec and put something like this in the file:
pragma Link_With("/Windows/System32/opengl32.dll");
Related
Let's say I want to build a simple windows exe that does HTTP requests with curl.
( See example: https://github.com/JetBrains/kotlin-native/tree/master/samples/curl ).
The example above works, but in order for the exe to run, it needs to find libcurl-4.dll, either in the local dir, or e.g. in the installation dir ( e.g. C:\msys64\mingw64\lib ).
I would like to ship just the exe file, without having to provide the dll files separately. Is it possible to build the exe file with all the things it uses from the library (and transitive dependencies...) bundled into the exe file?
(This question is about if I can do this with a Kotlin 1.3.61 Native project, and how.)
I'm studying Kotlin too and it took many hours until I realize how to handle def file, includes and static library.
I made an example of how to use static library (curl with gzip and SSL support compiled with mingw) on kotlin-native. This way you dont need to dll files to be supplied with your app
https://github.com/carlosrafp/Libcurl-Kotlin-Native-standalone
On libcurl.def file you can see:
headers = curl/curl.h // path to curl header
libraryPaths = src/nativeInterop/cinterop // path to your static library
staticLibraries = libcurl.a // the static library
linkerOpts.mingw = -lws2_32 -lwldap32 // linking dependences
I based on the nice post of jonnyzzz:
https://jonnyzzz.com/blog/2018/10/29/kn-libcurl-windows/
You need to build the static libraries using mingw (libcurl, gzip) and msys2/mingw(openssl) to use with kotlin-native compiler
You can definitely do this for a static library(see this), but not for the .dll. About the shared library bundling, I would just recommend you to see this question. It's about the same but a bit generalized.
I've dynamically linked libhunspell.dll (HunSpell) to my application. It works, but there is a dumb problem which I don't know why it happens.
Even before I use LoadLibrary("path\\to\\libhunspell.dll"); to load it and use it, on the start of the application it attempts to load the library by itself. If I place the libhunspell.dll into the path where my main executable resides, it can load it, otherwise it reports an error, immediately after starting the application - This application has failed to start because LIBHUNSPELL.DLL was not found. Re-installing the application may fix this problem. and the application doesn't start.
I would understand if the LoadLibrary would use invalid path but this happens as soon as the executable runs, even before the first statement in WINAPI _tWinMain(HINSTANCE, HINSTANCE, LPTSTR, int) executes (I've tried to place a breakpoint and it doesn't even reach it, so this happens before).
So, as a result, I must place libhunspell.dll in the same folder as my application executable, and not in the path I want.
This is probably easy to fix although I don't what to look for.
So the question is - how do I avoid it loading it immediately and have it wait until I use LoadLibrary call?
Here is how I linked if it can help:
1) compiled libhunspell.dll in Visual Studio 2015 (I used /MT option to link it statically so it doesn't have VC++ Redistributable as a dependency).
2) created import library (libhunspell.lib) using implib.exe -a -c -f libhunspell.lib libhunspell.dll
3) linked that to the source .cpp unit which is using it using #pragma comment(lib, "libhunspell.lib") (it is RAD Studio 2010 so the .lib is required unlike newer versions).
4) later in the same .cpp used LoadLibrary to load this library and used it.
By linking in the import stubs (libhunspell.lib) the OS will load the DLL for you as it is now a static dependency.
One approach would be specify the library as a delayload dependency: /DELAYLOAD:libhunspell.lib via the linker options. You can then call LoadLibrary on the DLL.
The only other option is to stop including the .lib in the linker step, making it truly a dynamic dependency.
I assume you did Add to project a *.lib file for your DLL. That is a kind of "static" linkage done in the App initialization (prior to your forms are created). So it has two disadvantages.
You DLL must be in the same path as the Apps EXE file
Sometimes DLL file name is locked (can not be changed)
The advantage is that you do not need to do any coding for the DLL loading as the VCL do it for you ... so your app should not contain the LoadLibrary,GetProcAddress calls you just include the *.h file with propper import declarations ...
For dynamic linkage you need to remove the *.lib from your project and use WinAPI LoadLibrary + GetProcAddress for loading your DLL as josh poley suggested. Here an example:
Builder C++ calling VC++ class
Beware there was/(is?) a bug in the GetProcAddress preventing from loading all the functions from your DLL in some cases. Especially if the DLL has old legacy mangling of names the count of functions is high and the DLL was created on compiler incompatible with the mangling in question.
I have a VS2010 SL4 project which uses an external Silverlight DLL. The project is localized with multiple RESX files, and the DLL is, too. I usually include external DLLs in my solutions as follows:
1) create a set of virtual folders in my solution like (say the imported DLL is named Sample.dll):
/Lib/Sample/Debug
/Lib/Sample/Release
2) create the same folders structure in the file system and copy under Debug and Release the respective versions of the DLL, so that now I find the following files:
/Lib/Sample/Debug/Sample.dll
/Lib/Sample/Release/Sample.dll
3) add to all the client projects in the solution a reference to /Lib/Sample/Debug/Sample.dll.
4) open the .csproj file of each project with the added reference, and change the Debug part of the path with $(Configuration), so that the right Debug/Release version is picked during build.
Now the question is: in my SL4 solution I can follow the same procedure for importing the language-neutral DLL. But what about its satellite resources? For instance, the French version of the imported DLL is built under subfolder fr-FR and named Sample.resources.dll. How should I include it correctly? Even If I try to manually add it in the compiled XAP under folder fr, it is ignored and the application falls back to its neutral culture...
I think I found it, here's a recap for whom may be interested:
open the .csproj file and ensure you add all your desired languages (separated by semicolons) in . For instance, if you support fr-Fr add <SupportedCultures>fr-Fr</SupportedCultures>.
(had to do this manually, I supposed 1. should be enough): once compiled, open your xap (rename it to .zip and open) and add if not present an element like <AssemblyPart Source="fr-FR/Sample.resources.dll" /> for each imported satellite with resources.
Thanks anyway!
I am facing the the problem to link to a third party dll. It is windows mobile application, where I am try to link to this third party dll.
Here first I had the dll and lib file. I was not able to link to it explicitly, but implicit linking is working. In the explicit linking the getprocaddress was failing. The dumpbin showed only the dllmain functions being exposed and no other function being exposed, hence the getprocaddress was failing.
However my application doesnot start if the dll is not found/installed in the device. It is expected as it is imlicit linking of a dll hence my application does not start.
I reported this to the third party dll provider and said that I want the explicit linking as the dll takes more space in my application if it is linked implicitly.
They replied by providing the .def file and said that I can use this .def file in my app to explicitly link to a dll.
I don't know how to use this .def file to explicitly link to a dll. Can any one please explain briefly about how to use this .def file in my app to explicitly link to a dll.
Use the *.def file when you build the DLL, to specify what function names the DLL is supposed to export.
After the DLL is built, use dumpbin /exports to verify that the functions are indeed exported from the DLL.
After you have verified that the DLL is exporting functions, you can either link to them at run-time using LoadLibray/GetProcAddress, and/or you can link to them at build-time by passing the DLL's *.lib file (which was created when you built the DLL using its *.def file) as an argument to your application's linker.
I'm trying to use a open source library from a Windows application, and the only pre-built version I can find comes as a file called "lib.dll.a"
What format is this, and can I convert it to a normal dll file?
Naming the output file libjvm.dll.a will allow gcc to recognize it as a
library named jvm. The .dll.a suffix indicates (by convention) that it is
an import library, rather than a static library (which would simply be named
libjvm.a, again by convention).