I need to include Security32.dll windows library into my project. Of course, I can load this library dynamically with LoadLibrary function, but is it possible to link the library during linking? I mean something like this (The following example is not correct, I just tried that and provide it as an example):
g++ -o bin main.o -lsecurity.dll
I really depends on your actual linker.
The GCC toolchain provided as part of the MinGW project will allow you to use dynamic link libraries (dll files) directly under Windows rather than static libraries only (or MSVC's lib files), but you'll still need the proper header files so the compiler knows what to call.
Microsoft Visual C++ on the other hand won't support this and will always need static libraries (lib files) with the proper information, even when you're linking against a dynamic/shared library.
Related
I am writing a program that uses the hashlib++ library (or will use it) but I don't want to add all of it's source files to my project because it's huge. Is there anyway to link to the hashlib++ source files so that I can use it in my project? I've tried linking to the header directly with a simple
#include "path/to/hashlibpp.h"
But I receive a nifty error for it as soon as I attempt to call any functions from the library. For example:
undefined reference to `sha1wrapper::sha1wrapper()
I am using the Code::Blocks IDE and GCC compiler.
First you have to have the library installed on your machine, already compiled into a static or dynamic library file. You can install from source, or you may find a pre-built package available for your OS (depending on which OS you are using). You will need to know the name of the library.
In the case of hashlib++ they have provided instructions to build a static library from source in their README; see section 3.2.
In most cases, dynamic linking is the best choice. This means that the library is linked with the library at run time, instead of adding the library to your executable when it is compiled (which would make your executable file much larger).
Unfortunately, according to their README.txt, hashlib is only available as a static lib, which limits your choices.
When compiling a program on the command line using gcc, the '-l' option links in a library:
gcc -o MyProg -lhl++ MyProg.c
When using an IDE like Code::Blocks, you normally have to specify the libraries to be linked. See this answer for details on how to do this with Code::Blocks.
I have been trying to get this working for a while now and am unable to find an answer elsewhere, here is my problem.
When I make a static library in Visual C++ any dependencies that this library uses are carried on to the executable program that I link the library to. Here is an example
Test.lib depends on
- SDL
- OpenGL
TestApp.exe links Test.lib
In Visual C++ I do not have to add the dependencies for Test.lib in my TestApp executable, they are carried over and it works great.
However when I port my code to Linux g++ (With the Code::Blocks IDE), if I make a Static Library which is .a in g++, and I make a TestApp that links the library, it gets undefined references to the dependencies.
Is g++ able to do this, and if so what am I missing to have the dependencies carried over to my executable?
As for my settings for my library I simply use the IDE's Static Library setting.
With Microsoft's compiler, header files can have library dependency information in them (source files, too, but this is typically done in headers); this gets compiled into the object file, and the linker understands and applies that information. That can be handy: you don't have to remember long, funky names, and if you compile two source files with incompatible options you may get a library name conflict that the linker will complain about. Most compilers and linkers don't do this kind of thing, and you have to tell the linker explicitly which libraries you want to link with.
Static libraries do not statically link with other libraries. Does that sound right?
However you can pack many object files together with a tool called ar.
What happens on windows is probably because you have the (SDL, opengl32) dlls somewhere in a system env path.
I've been using libarchive in my project for some time now and it's working great, at the moment I am dynamically linking to it, so on Windows the libarchive.dll file has to present on the system.
I would now like to statically link to the library so I don't have to bother distributing the DLL, but I'm having real trouble trying to achieve this!
Currently, in my make file, I have something like this:
-Lpath/to//libarchive/ -larchive
And this works, but it does a dynamic link. I don't know how to enforce a static link.
I can see in the libarchive directory there are two a files, libarchive.dll.a and libarchive_static.a. I suppose I want to link to libarchive_static.a but I can't seem to specify this, doing -larchive_static in the make file results in linker errors.
I was under the impression that static libraries under windows are lib files, but I get no such file type when I build libarchive.
How can I make a .lib file from libarchive. Also, as an extra question, what is the difference between an a file and a lib file?
Update
To statically link to libarchive, your library command for make should contain:
-Lpath/to//libarchive/ -larchive_static
This will link to the libarchive_static.a file. However, you also need to define LIBARCHIVE_STATIC in your code.
Now the problem is that libarchive depends on the bzip2 libraries (as well as others), and if you do not have a static build of them you will get linker errors something like:
undefined reference to `BZ2_bzCompressInit'
You need a static build of the dependent libraries and a similar command to the linker after the libarchive command:
-Lpath/to/bzip2/ -lbzip2
You can either build bzip2 from source, or do it the easy way and get a pre-built binary from the Gnu32Win project here: http://gnuwin32.sourceforge.net/packages.html
Just add libarchive_static.a explicitly to your link command.
gcc -o YourApp.exe $(OBJS) path/to/libarchive_static.a $(OtherLibs)
".lib" files differ from compiler to compiler (Borland, Microsoft etc.), ".a" is an old "archive" format from UNIX's ar tool. It is now used only for the bundling of static libraries.
Currently, in my make file, I have something ...
And this works, but it does a dynamic link
The .a file actually contains some code for dynamic linking to the .dll file, not the libarchive itself. On the startup the pointers to functions are allocated and dynamic linking is done.
I want to build a shared library that uses ZipArchive using GNU Autotools but I'm having this problem:
Warning: linker path does not have real file for library -lziparch.
I have the capability to make that library automatically link in when
you link to this library. But I can only do this if you have a
shared version of the library, which you do not appear to have
because I did check the linker path looking for a file starting
with libziparch and none of the candidates passed a file format test
using a file magic. Last file checked: /usr/local/ZipArchive/ZipArchive/libziparch.a
The inter-library dependencies that have been dropped here will be
automatically added whenever a program is linked with this library
or is declared to -dlopen it.
If I build a static library or if I use a shared library of ZipArchive it works but the problem is that the makefile that comes with ZipArchive source code only builds a static library.
How can I force Libtool to link with a static library?
Generally, static archives are created with non-pic object files and they cannot be put into shared libraries.
What this message is telling you though, is that when a program links to YOUR library using Libtool, that -lziparch will get added to the link. So you don't need to change anything unless you're building a module for an interpreted language. In that case, you will have to build ZipArchive as a shared library. In addition, this wouldn't work on a platform like MS Windows where shared libraries (DLLs) have to resolve all their symbols at link time.
All that said, if your ziparch static lib is PIC code, you can use the -whole-archive flag when linking it to your library. This would be the least portable solution though.
i have a c program that relies on a second library whose compilation i can control. i want to be able to compile my program into a shared object library without it linking to the second library. in other words i want a single monolithic shared object library at the end. how can i do this?
if i separately compile the second library into a .so and include that as a dependency when compiling my program, i can see that i need that file when i run ldd on the binary.
You need to compile your second library as a .a (static library) and statically link that into your c program.
Static linking is when object files are linked at compile time and are part of the final binary, the resulting executable can be executed with no dependencies..
Shared libraries (.so) are linked at run time and must be available when you execute the binary that links them.
the gcc flag to link statically is: -static this will automatically search for .a files.
What radman said above.
http://www.network-theory.co.uk/docs/gccintro/gccintro_25.html