I am using dart:ffi to interoperate with some C code in order to use the SDK provided by ZeroTier. I have tried and successfully call out a dummy function from the shared library produced by CMake. This is the CMakeList.txt.
cmake_minimum_required(VERSION 3.4.1)
add_library(
weather
SHARED
../../src/weather.c
)
I have followed the documentation of ZeroTierSDK and the output of the compilation is the .dll and .a files. May I know what is the proper way to link the shared library produced from my .c file with the compiled library (.a / .dll) so that I could use the functions provided by the sdk?
I have tried adding the following lines to the CMakeList.txt.
link_directories ("../../src/libzt.lib")
target_link_libraries(weather ../../src/libzt.lib)
The error that I get was as below, I have confirmed that the lib was located in the same director as my .c file.
C:/Users/DELL/AppData/Local/Android/Sdk/ndk/21.1.6352462/toolchains/llvm/prebuilt/windows-x86_64/lib/gcc/arm-linux-androideabi/4.9.x/../../../../arm-linux-androideabi/bin\ld: error: cannot find -l../../src/libzt.lib
Related
I recently made a small library in C, and I wanted to put it together with the standard libraries so I don't have to always copy the files for each new project.
Where do I have to put it so I can import it like the standard libraries?
Compiler : MinGW
OS: Windows
You need to create a library, but you don't necessarily need to put it in the same place as MinGW's standard libraries (in fact I think that's a bad idea).
It is better to put your own library/libraries in specific place and then use the -I compiler flag to tell the compiler where to find the header files (.h, .hpp, .hh) and the -L linker flag to tell the linker where to find the library archives (.a, .dll.a). If you have .dll files you should make sure they are in your PATH environment variable when you run your .exe or make sure the .dll files are copied in the same folder as your .exe.
If you use an IDE (e.g. Code::Blocks or Visual Studio Code) you can set these flags in the global IDE compiler/linker settings so you won't have to add the flags for each new project.
Then when building a project that uses your library you will need to add the -l flag with the library name to your linker flags, but without the lib prefix and without the extension (e.g. to use libmystuff.a/libmystuff.dll.a specify linker flag -lmystuff). The use of the -static flag will tell the linker to use the static library instead of the shared library if both are available.
I have created a minimal example library at https://github.com/brechtsanders/ci-test to illustrate on how to create a library that can be build both as static and shared (DLL) library on Windows, but the same code also compiles on
macOS and Linux.
If you don't use build tools like Make or CMake and want do the steps manually they would look like this for a static library:
gcc -c -o mystuff.o mystuff.c
ar cr libmystuff.a mystuff.c
To distribute the library in binary form you should distribute your header files (.h) and the library archive files (.a).
I currently have two C projects on Clion with cmake. One of the projects is named "sharedLibsDemo" and I am trying to create a shared library in this project. In the other project I want to use the library that was created by the "shared" project.
Currently, in the "sharedLibsDemo" project I have the following cmake:
cmake_minimum_required(VERSION 3.7)
project(sharedLibsDemo)
set(CMAKE_C_STANDARD 11)
INCLUDE_DIRECTORIES("${CMAKE_CURRENT_BINARY_DIR}")
set(SOURCE_FILES shared.c shared.h main.c)
add_library(shared SHARED ${SOURCE_FILES})
include(GenerateExportHeader)
GENERATE_EXPORT_HEADER(shared # generates the export header shared_EXPORTS.h automatically
BASE_NAME shared
EXPORT_MACRO_NAME SHARED_EXPORTS
EXPORT_FILE_NAME shared_EXPORTS.h
STATIC_DEFINE SHARED_EXPORTS_BUILT_AS_STATIC)
set(EXEC_FILES main.c)
add_executable(myexe ${EXEC_FILES})
target_link_libraries(myexe shared)
However, this cmake only creates the shared_EXPORTS.h, libshared.dll, and libshared.dll.a` files.
I managed to create the .lib file using Mingw itself and put all of these files including the .h file of the source code into one folder and placed the folder in the root folder of the second project in order to use it.
However, I've looked everywhere to find a way to link the library into the second project's executable. The documentation for cmake itself assumes I have a tonne of knowledge which I don't. Is there any list of commands that I can use to finally link my library. I have already tried the generic answer of "use find_package() or target_link_libraries" to no avail.
EDIT 1
The following is the contents of shared.h :
#include "shared_EXPORTS.h"
#ifndef SHAREDLIBSDEMO_LIBRARY_H
#define SHAREDLIBSDEMO_LIBRARY_H
void SHARED_EXPORTS sharedHello(void);
#endif
As per the suggestion of #Shmuel H. I placed the shared.h shared.c and the cmakelist.txt for the shared project into a folder in the project that I want to include the library in. And I used add_subdirectory() and target_link_libraries().
The following is the CMakeLists.txt for the project:
cmake_minimum_required(VERSION 3.7)
project(projectFiles)
set(CMAKE_C_STANDARD 11)
include_directories(src ${maker_INCLUDE_DIR})
set(SOURCE_FILES src/nv_runner/main.c src/FactParser/FactParser.c src/FactParser/FactParser.h src/Utils/Utils.c src/Utils/Utils.h src/nv_runner/main.h)
list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_LIST_DIR}")
find_package(maker REQUIRED)
include_directories(${maker_INCLUDE_DIR})
set(LIBSHARED_LOCATION ${PROJECT_SOURCE_DIR}/libshared)
add_subdirectory(libshared)
include_directories(${LIBSHARED_LOCATION})
add_executable(${PROJECT_NAME} ${SOURCE_FILES} src/FactParser/FactParser.c src/FactParser/FactParser.c src/FactParser/FactParser.h src/nv_runner/main.h)
target_link_libraries(${PROJECT_NAME} ${maker_LIBRARY})
target_link_libraries(${PROJECT_NAME} shared)
At first, I had to remove the SHARED_EXPORTS macro from the sharedHello function and the shared_EXPORTS.h include in shared.h because otherwise it would not recognize the function for use in other files. But when I ran the program I got this result:
Process finished with exit code -1073741515 (0xC0000135)
EDIT 2
Project setup image
In the screenshot, I've taken all the necessary files from the shared project, placed it in a directory in the current project and marked the directory as a Library. The cmake can be seen in the image. With this setup, whenever I run my program, it just crashes with the error seen in the image.
I found out what the issue was. I did not know that the dll had to be in the same folder as the exe, that's why the program was not executing. Once I placed the .dll file inside the exe folder, it worked.
Credit goes to this question for helping me identify the issue: C++ running file with included library failes without compiling error (CMake / CLion)
And I found out that .lib files are only necessary for MSVC compiler. MinGW uses the .dll.a file; replacing .lib. This post lead me to finding this out: Compatibility of *.dll *.a *.lib *.def between VisualStudio and gcc
Please correct me if I'm wrong however. Here is an image of my current project and cmake setup
In the process of porting a C project from Linux to Windows
Have installed MinGW
Have compiled my shared library using a Makefile
This produces libExample.so
Now I'm trying to link this shared library to a test harness so I can see if everything is working as expected
In the harness Makefile I specify the location of the library, e.g. -LE:/libExample_dir and the name of the library -lExample
but its complaining it cannot find the library, i.e. linker is failing with cannot find -lExample - is there some difference with windows regarding .so and .dll or perhaps pathnames that I am missing?
You need to fix the make file so shared libraries are generated with a .dll extension.
If I had to guess, I'd say that while renaming the generated file is enough to make the linker happy, the loader still expects the .so extension because that's the name that was compiled in...
Using MinGw to compile C code to produce a shared library, remember to rename the output from libExample.so to libExample.dll otherwise the linker will fail to find your library
I'm currently trying to port a C application to AIX and am getting confused. What are .a and .so files and how are they used when building/running an application?
Archive libraries (.a) are statically linked i.e when you compile your program with -c option in gcc. So, if there's any change in library, you need to compile and build your code again.
The advantage of .so (shared object) over .a library is that they are linked during the runtime i.e. after creation of your .o file -o option in gcc. So, if there's any change in .so file, you don't need to recompile your main program.
But make sure that your main program is linked to the new .so file with ln command.
This will help you to build the .so files.
http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html
.a are static libraries. If you use code stored inside them, it's taken from them and embedded into your own binary. In Visual Studio, these would be .lib files.
.so are dynamic libraries. If you use code stored inside them, it's not taken and embedded into your own binary. Instead it's just referenced, so the binary will depend on them and the code from the so file is added/loaded at runtime. In Visual Studio/Windows these would be .dll files (with small .lib files containing linking information).
.a files are usually libraries which get statically linked (or more accurately archives), and
.so are dynamically linked libraries.
To do a port you will need the source code that was compiled to make them, or equivalent files on your AIX machine.
They are used in the linking stage. .a files are statically linked, and .so files are sort-of linked, so that the library is needed whenever you run the exe.
You can find where they are stored by looking at any of the lib directories... /usr/lib and /lib have most of them, and there is also the LIBRARY_PATH environment variable.
Wikipedia is a decent source for this info.
To learn about static library files like .a read Static libarary
To learn about shared library files like .so read Library_(computing)#Shared_libraries On this page, there is also useful info in the File naming section.
Specifications can be seen here:
http://www.winpcap.org/docs/docs_40_2/html/group__wpcapsamps.html
It's very strange,either .lib or .dll is enough IMO,why does it require both?
In general, you need the .lib for the linker, and .dll at runtime. The .lib file is called an "import library", which contains the glue that tells the linker the functions you're calling can be found in the associated .dll file.
You will probably find that only the .dll file is required at runtime.
This is a widely used layout for Win32 DLL projects and is not limited to Winpcap.
Its not only with winpcap, all external libraries are like that.
When you compiles your source codes which using particular library, you need header files *.h from that library, and you will get *.o files
When you link those *.o files to executables, you will need *.lib or *.dll.a files.
When you run those executable files, you will need *.dll files
If you are calling a Dll you will need an Lib with that. you can see the below link for more info
This is from wikipedia
Linking to dynamic libraries is usually handled by linking to an import library (your .LIB) when building or linking to create an executable file. The created executable then contains an import address table (IAT) by which all DLL function calls are referenced (each referenced DLL function contains its own entry in the IAT). At run-time, the IAT is filled with appropriate addresses that point directly to a function in the separately-loaded DLL.