How to use SQLite3 library in D language program on Windows?
I found a similar question with Ubuntu, but it didn't work in my case.
import std.stdio, std.string, etc.c.sqlite3;
void main () {
sqlite3* db;
auto ret = sqlite3_open (toStringz("mydb.s3db"), &db);
writeln (ret);
}
As I assume, the sqlite3.d is some kind of header to the real SQLite3 library. I've got an sqlite3.dll, but I have no idea about how to link it with my program. pragma works only with lib formate (like pragma(lib, "sqlite3")).
Maybe I should use the SQLite sources, but how is it possible to compile it together with D code? Or is it better to find some way to convert dll to lib?
What is a general method to solve such problems in D?
Or is it better to find some way to convert dll to lib?
Yes. From the question Statically linking SQLite with DMD (Windows x86), just run the .dll file through implib with the /system switch (linking with the resulting .lib file will still result in dynamic linkage and a dependency on the .dll file).
You can also compile the sqlite source (with modification) using Digital Mars C copmiler which will then give you an object file you can statically link.
Related
So I'm trying to use stb_image in my Kotlin/Native project and I am having trouble trying to include it in my project. It's a header only library and konan seems to expect a compiled object file anyways so I was wondering if there is any way of just generating the cstubs and then using the header for linking unless I have to compile a basic translation file since stb_image only requires you to have a translation unit that defines STB_IMAGE_IMPLEMENTATION however I have that defined in my compilerOpts -GSTB_IMAGE_IMPLEMENTATION. Would it be easier to just compile a translation unit, create the static object, and then link against it or does K/N have some way of doing that for me?
I am using Gradle Multiplatform so if there is some gradle script I can run then please let me know.
My -GSTB_IMAGE_IMPLEMENTATION is supposed to be -DSTB_IMAGE_IMPLEMENTATION and I needed to put my -I switch in my compilerOpts not linkerOpts.
I recommend actually creating a translation file but it's not required.
You can just give the header file with the compileropts as you've done and that should work.
You can look at this as a reference. I'm working on a wrapper in my free time.
I have a static library written in objective-c. I have it in the form of a libFoo.a file.
I'd like to extract the classes and methods that are contained within the library, similar to the output of class-dump-z.
I've tried using otool -tV as suggested here.
However, the output is very verbose and includes lots of things other than just the interface declarations.
Per comment from H2CO3, I tried RuntimeBrowser, which seems like an excellent tool. However, opening the .a files from File -> Open didn't seem to do anything. Could be because I was using the Mac version and trying to inspect an iOS library.
I've also tried running class-dump-z against the static library but it doesn't appear to work:
/**
* This header is generated by class-dump-z 0.2a.
* class-dump-z is Copyright (C) 2009 by KennyTM~, licensed under GPLv3.
*
* Source: (null)
*/
Tried regular class-dump but got this error message:
Error: Fat file doesn't contain a valid Mach-O file for the specified
architecture (i386). It probably means that class-dump was run on a
static library, which is not supported.
I downloaded the evaluation version of IDA for Mac (6.4.1303322) and so far it's been the best yet. Very useful--just pop open the static library and you can see a list of the classes and it understands Objective-C 2.0 syntax and you can see the methods.
That being said, I'd still love to see a way to get the output in the same format as class-dump-z.
Anyone know of a way to extract the classes and methods that are contained in an objective-c static library? I can see them in the stack when I stop in the debugger and when I use [NSThread callStackSymbols] so I know the debugging symbols are present.
Does anyone know where I can find a Firebreath sample (either Mac OS X or Windows) that illustrates how to create a plugin that includes 1 or more other libraries (.DLLs or .SOs) that each rely on other sub-projects built as static libraries (LIBs)?
For example, let's say that the Firebreath plugin is called PluginA, and that PluginA calls methods from DLL_B and DLL_C. DLL_B and DLL_C are C++ projects. DLL_B calls methods from another project called LIB_D, and DLL_C calls methods from a project called DLL_E.
Therefore, the final package should contain the following files:
PluginA.dll
DLL_B.dll (which also incorporates LIB_D)
DLL_C.dll
DLL_E.dll
I am currently forced to dump all source files in the pluginA solution, but this is just a bottleneck (for example I cannot call libraries written in other languages, such as Objective-C on Mac OS X).
I tried following the samples on Firebreath, but couldn't get them to work, and I found no samples from other users that claimed they were able to get it to work. I tried using CMAKE, and also running the solutions directly from X-Code, but the end result was the same (received linking errors, after deployment DLL_C couldn't find DLL_E etc.)
Any help would be appreciated - thank you,
Mihnea
You're way overthinking this.
On windows:
DLLs don't depend on a static library because if they did it would have been compiled in when they were built.
DLLs that depend on another DLL generally just need that other DLL to be present in the same location or otherwise in the DLL search path.
Those two things taken into consideration, all you need to do is locate the .lib file that either is the static library or goes with the .dll and add a target_link_library call for each one. There is a page on firebreath.org that explains how to do this.
On linux it's about the same but using the normal rules for finding .so files.
Is there a way to find out what framework / static libraries have been linked with an iOS build (ipa file) assuming you have no access to the source code?
AFAIK no, because symbols from static libraries are copied into your binary without any reference to the original static library. Maybe there's some magic, but I'm not aware of it.
But you can use nm for example to list symbols in your executable and then guess from where they came from.
What is the meaning of building a dll as export library ? I just googled it.I found its a dynamic link library.Can anyone please explain what actually dll is ? and why do we need to add these statement in the .dll file
extern "c" _declspec(dllexport)
I studied the static and shared libraries but Im not sure why do we go for dll files.I learnt .dll is used for the run time. But can you help me and give me more information.Thank you in advance
I may have been a bit harsh in my comments. I am not an authority on dlls, but I have a bit of working knowledge of them, so I will try to give a short explanation.
The difference between static and shared libraries should be easy to find in a web search, but basically the code in a static library gets included into the final executable, so after the linking stage, the actual library file is not needed anymore to run the program; on the other hand, code in a shared library doesn't get included in the main program - the two parts remain separate, so the shared library (called dll on windows) will be needed every time the program is run.
"Building a dll as export library" is a bit of a confusing term. I had not heard of it before, and during a short search could only find it on a cygwin page, which you might have read, considering your initial tags. A dll can export some or all of its functions and data. Exporting means that they are available for other programs and dlls to use. Which names get exported can be controlled in various ways. One of those is inserting _declspec(dllexport) in the declaration of the function. Another way is by using a definition file with an exports section.
When creating a dll, an import library can be created. This is a file that can then be used when building an executable that uses the dll, during the linking stage, to let it know which names are exported from the dll, so the program knows how to resolve references to those functions; in other words: how to import them. (This is not always necessary. Many linkers allow you to directly link against the dll itself, thereby removing the need for an import library.)
I realize it can be confusing, but try to find a tutorial and some small examples to see how it works, and play with it a bit.