I have a program in C. I need to use a SQLite library to read data from a database.
When I include sqlite3.h to my source file I get unresolved symbol errors on sqlite3 functions.
If I add lib file as library I don't get any error but program requires sqlite3.dll to run.
I already tried to play with compiler settings but nothing changed.
SQLite is written in C and my program is also C. Why do I need a DLL file to use SQLite?
How can I remove the DLL dependency.
I'm using MCVS2015 community edition IDE.
The recommended way of compiling SQLite is to download the amalgamation source code file (sqlite3.c), and to add it to your project.
Related
The title basically says it all. It might be a dumb question (which probably is) because I am entirely new to programming. I wonder how the desktop apps we use are made of mostly .dll files when you check their program files, but not even a single source code file? Is there any way to open them, or how can I turn my code file into .dll?
Thats exactly what DLL files are. DLL files are libraries which contain code that is called by the 'main' source code, which is compiled into '.exe' files.
You not being able to see such code is intended by its owner, unless the source itself is released alongside the compiled software. A project may integrate .dll files already developed by someone else instead of developing them from scratch.
As to how to turn your code into a .dll, it would depend on the language you are developing in.
More detailed answers at: What exactly are DLL files, and how do they work?
Short answer: The DLL files are "compiled".
Compiled files no longer rely on their source code. Once compiled they can be executed by the operating system directly.
DLL files are not "scripts". In languages like HTML, Javascript and PHP, the files are interpreted at run time by the browser's HTML or Java engine or the PHP engine on a server. Thus you can also read them since they are not yet compiled. But in the case of a DLL file, the original source code files have been compiled (interpreted and converted) and the result is an executable Library which is used by another program to accomplish whatever tasks are in them.
It is possible to "decompile" them with a decompiler, but that will not give you the original source code, any more than a "jpg" will give you the original layered Photoshop file. All you have is the Result.
Please don't answer this as a "How do I cross-compile on Linux for Windows" question, I solved that part. I need some specific instruction on configuring Netbeans. Thank you.
I'm developing a set of C functions that I want to distribute as a .dll on Windows, and a .so on Linux. (This is going to be used from java as a JNI library, but that's irrelevant to the question).
Development environment is Netbeans 8.2.
I have gcc and mingw installed, and compiling my source code for both targets works.
However, I want to create NetBeans configurations "Linux-Release" and "Windows-Release", with Linux-Release using gcc to create the .so file, and Windows-Release using x86_64-w64-mingw32-gcc. So I created a Mingw tools collection that refers to the mingw versions of the C compiler:
In my project properties, I created a Windows_Debug configuration, and told it to use the Mingw tool collection:
I can use this configuration to get a working Dll. However, the output file will be put into the dist/Windows_Debug/Mingw-Linux directory (not dist/Windows_Debug/Mingw-Windows as I'd like), and it's put there with a .so extension, not .dll. I can load this file on Windows when I rename it to .dll, but this will horribly confuse anyone I want to collaborate with.
Naively messing with the CND_DLIB_EXT macro in the generated Makefiles doesn't help at all, they just get overwritten.
I guess I have to either tell Netbeans that the Mingw Tool Collection compiles to Windows, or that the Windows_* configurations compile to Windows, so Netbeans sets the correct values for CND_* and the default output Macro
${CND_DISTDIR}/${CND_CONF}/${CND_PLATFORM}/libSMAQSJni.${CND_DLIB_EXT}
in the linker part of Project Properties works again. (Of course, as a workaround, I could just remove the variables from the macro, and replace them with appropriate constants, but I want to do this "right". I haven't found a way to tell Netbeans "this compiles to Windows" anywhere though, neither in the GUI nor in any of the config files. So, how do I do this?
I used MySQL Connector C 6.1 api in C.
I linked all the header files, libraries etc in the Code blocks IDE and when I try to compile the program,it works and I am able to run the program. But when I copy the .exe file to another computer, a warning comes saying that libmysql.dll is missing. When I copy that libmysql.dll file along with the program,it works fine. But how to avoid that? Is there a way to make it run without copying .dll file?
If your program depends on a .dll (which stands for dynamic link library) then there is no way to run without that .dll being present on the system. This is because there is code in the library that your program depends on. An alternative would be to build your program with a static version of the library, a .lib file.
Related to using cmake to link object files into lib.xxxx.a file, but not quite the same thing, I have built several static libraries on Windows using CMake 2.8.x using VS2008 SP1. Is there a way via CMake alone to relink all of the .obj files inside all of those existing static libraries into one larger monolithic library, preferably via the add_library CMake function, or other similar construct?
I think the answer is "no", and so I have thought about rolling my own via a custom command via the usual add_custom_command + add_custom_target approach, that simply constructs the library manually, by supplying all of the other libraries .obj files when calling LINK.EXE. But I see some problems with that approach:
I could not find a CMake variable that indicates the fully-qualified path to the LINK.EXE executable. I would then have to somehow derive the path to LINK.EXE using a fragile heuristic: It is fragile in the sense that different Visual Studio versions may locate the LINK.EXE file in different directories, and I'm needing this to work for both 32-bit and 64-bit Windows compiler conditions, and be resilient against upgrades between VS2008 and future compiler revisions.
I would have to find a way to find all of the .obj files of the other static libraries, at build time versus at CMake time, since at CMake time the .obj files of course do not (always) exist. For reasons of build performance, I desire not to resort to extracting the .obj files from the .lib files for the sake of adding them to the LINK.EXE command line, so a FILE(GLOB...) construct would be my best second alternative in this case.
It may be possible to simply call LINK.EXE via: LINK.EXE /OUT:monolithic.lib lib1.lib lib2.lib ..., but maybe not all .obj's will be included (EDIT: I have confirmed that LINK.EXE omits some .obj files from lib1.lib lib2.lib ... without any diagnostic messages explaining why, so this approach is a non-starter); the online docs for LINK.EXE are unclear as to that point. Anyone have any experience with using LINK.EXE in that manner?
Thanks,
Brent
P.S., I know how to create a DLL using CMake, but I specifically do not want to resort to building a DLL at this point in time.
Create a static library "merged" with a dummy source file, and add libs to be merged to the STATIC_LIBRARY_FLAGS, so they will be additional input to lib.exe.
This would be something like:
ADD_LIBRARY(merged STATIC dummy.c)
SET_TARGET_PROPERTIES(merged PROPERTIES
STATIC_LIBRARY_FLAGS "full\path\to\lib1.lib full\path\to\lib2.lib")
This approach is used inside MySQL, there is a more general macro here to merge static libraries that works crosss-platform. It can be found here http://www.mail-archive.com/cmake#cmake.org/msg28670/libutils.cmake
In my application I have to explicitly link to a dll. The application is in QT with gcc compiler.
The dll the application have to link to is a wrapper around another old dll. The purpose is to fit the old dll to a new interface.
I use implicit linking when compiling the new dll. The new dll is compiled with msvc 2008. The reason is that the old dll has c++ class functions which can't be recognized by gcc. The new interface uses c functions.
So the big picture is that when I run my application I link the new dll and the new dll depends on the old dll. Everything works fine, except that I have to put the old dll in the same folder as the exe or the same folder as the .pro file.
I have tried to add the old library into the application's qt .pro file but didn't work.
Is there any way I can move the directory of the old dll file?
To state more clearly, If the old dll and application are compiled with the same compiler, I could include the path to the old dll and lib in the .pro file and put it any where I want.
However, now, only the new dll recognizes the old dll functions so I could no longer do that. I wonder whether there is a way to modify the path that the exe file searches while running. Now it searches both the exe folder and its parent folder.
The windows operating system looks for dll's in a specified manner, the following link might help:
Dynamic-Link Library Search
If you want to keep the dll in another folder, then adding the lib folder to your PATH variable will work, but you when you deploy the package you will have to make sure that the dll on the target machine can be found using the library search order as specified in the link.
I tried to modify the dll search order with SetDllDirectory which is mentioned from the link in Steven's answer. However it seems to be a msvc function only. (I'm not sure, but I included the mingw winbase.h file and it still doesn't recognizes it.)
So I tried to modify the PATH variable using putenv and it works.