I know that command line apps are standalone and can be called from a shell. Static libraries on the other hand are linked to by other programs.
But what actually is the difference between the two? Is it the same binary with a different interface? Or is it something different altogether?
It is something different altogether. A standalone application has a binary product that can directly be executed. Static libraries however cannot be executed on their own. A standalone application may link to a set of static libraries in which case the symbols defined in those libraries will be accessible to the application.
To give you an example, you can create a static library which declares the following function in helper.h and defines it in helper.c:
int func() {
printf("hi\n");
}
When you build this library, you will end up with something like helper.a which cannot be executed independently (it doesn't have int main()) but can be linked to by one or multiple standalone applications. Once linked, those applications can simply include helper.h and call func() as if they have implemented func().
In the end, choosing between the two depends on what you are trying to achieve. Are you trying to create a tool that multiple applications can link to and use? Then go with static library.
Related
VPP provides the I/S for developing custom plugins that can be hooked into a graph of nodes. I've only seen examples for such plugins written in the C language, and was wondering whether other language, Go for instance, can also be used to write such plugins.
I have no idea what "VPP" is but nonetheless the answer is: "maybe"; here's why:
Go code is able to interface with C libraries via its facility known as cgo.
cgo is a multiple-faceted thing: it allows you to "export" certain Go functions in a certain way so that they can be called from the C side, and it allows you to call functions from the C side. It also allows you to write bits of inline C code to provide glue for the C side, when necessary.
Since some time Go building toolset (at least its "reference" implementation) provides for compiling Go code into a static or dynamic library with C-compatible API.
See this.
With these things in mind, in theory, it should be possible to do what you're after.
Note some possible obstacles:
Most of the time, if a "platform" allows you to write a "plugin" in C, it presupposes your plugin will make extensive use of the platform's own API.
This usually means your plugin is supposed to include certain header files provided by the platform.
The platform might also require your plugin to link against some platform-provided library (usually shared), or libraries.
cgo can do all of the above, but you will need to scrutinize the API provided by the platform and maybe write Go helpers to make its usage more natural for the Go code.
Building/linking issues (usually the locations of the header files and the libs) may also be a thing to solve.
Sorry for the confusing wording.
Basically I want to create a static library (libone.a) that needs to link another static library (libtwo.a). libone.a and libtwo.a are both linked in statically into another program (let's call it program) by doing the following:
$(CC) -o program something.o anotherthing.o -L/path/to/lib -lone -ltwo
Whenever program makes a call to a method in libtwo.a it should go to the libtwo.a that is loaded with program. But whenever program makes a call to a method in libone.a which calls a method in libtwo.a, it should call the libtwo.a that was embedded in when libone.a was created. Yes I understand that this will blow up the file size by loading two of the same libraries but I'm OK with that.
The reason why I'm attempting this is because the program I have is using OpenSSL (in this case libcrypto.a) and my static library is also using libcrypto. However I have a requirement in my library that OpenSSL be FIPS valid (i.e. FIPS_mode_set(1)) but doing that will break program. In short I want to libraries of OpenSSL used. The one called by program natively should use its own and the one called by my library should use the one that I linked and is FIPS valid.
Is this possible?
Is this possible?
No, this simply can not be done with archive libraries (it can be done with shared libraries but requires great care to avoid symbol collisions).
I am on OS X, and I have a .so file which I want to link to a .o file during execution. For example Foo.so should be linked to Bar.o during while calling ./Bar.o . I am using the Terminal application to run my app and I compiled my project using a Makefile.
On Unix and OS X you can do this with libdl.
The basic idea is that you compile and link an executable. At some possibly different point in time and place, someone who might not be you compiles and links a shared libray. If at runtime the executable can get strings for the the shared library filename and the symbol of a function that you want to load, then you can use libdl to get a void* to that contains the address of a function in the shared lib. The appropriate function pointer type must be known to the executable at compile time because the next step is to cast the void* to whatever type was "secretly prearranged" between the executable and the dynamically loaded lib. After casting you're good to go.
This tutorial shows the traditional approach for dynamically loading functions. Classes requires some indirection via factory functions.
http://www.tldp.org/HOWTO/html_single/C++-dlopen/
The approach above is where to start but it has the drawback that all communication between the executable and lib must be through C style function signatures created with extern "C" before functions (most significantly no templates or overloads). This is just a limitation on the ports of communication between the executable and lib. Both can use C++ internally. If you want to dynamically import overloaded functions here's a way.
Dynamic Loading Without extern "C"
You have to be careful with user defined classes. The binary representation of classes is not standardized in C++. If a custom class passes from executable to lib but the executable and lib have different ideas of which bits mean what, you won't get the behavior you wanted.
Also, if you compiled your shared library on OS X, you have a dylib, not an so. They're slightly different.
What are the differences between .so and .dylib on osx?
I have a need to create a static library which will some of it's own code and it will also contain a number of other static libraries I have written.
So normally I have a main project A.xcodeproj which depends on B.xcodeproj which in turn depends on C, D, E etc.
My company has a requirement to distribute only a static library with a simple app, and for there to only be one library sent out, not a multitude of libC.a libD.a etc.
So I create A_static.xcodeproj which has simple application API calls and links to libB.a but everytime I try this libB.a only contains the symbols for B.xcodeproj, I can not get to it also contain libC.a libD.a etc.
Is there an easy way to do this in XCode that I'm missing?
Thanks
It sounds very much like you need to use frameworks. Allows you to bundle multiple libraries and files together into 1 bundle that other parties can include. I'm in the same boat where I work. I've used this guide on github to get our frameworks up and running. Worked great for me.
iOS Framework
What is the difference between a LIB and DLL? I have read plenty of posts on here about it and there are some good, clear answers however I am writing to ask for clarity on one matter.
Is it better to use a LIB (static link library) when there is only one user e.g. for a administration application client installed locally on the PC? and is it better to use a DLL (Dynamic link library) when there are multiple concurrent users accessing a classic asp application that uses vb6 classes?
A LIB file generally corresponds to a static library, which means that all of the library code that your application uses is compiled directly into your application.
A DLL file represents a dynamic library that your application links to, and then when you want to use code from the library, you call into it dynamically while your application is running.
Of course, you'll frequently see a LIB file for a dynamically-linked library as well. That file contains "stubs" that the linker uses to implicitly link to the DLL.
The obvious benefit of a DLL (dynamic linking) is that one DLL with common functionality can be shared with multiple applications that use that same functionality. Bug fixes can be made in a single place, and only one component has to be updated in order for all of the apps to take advantage of those fixes.
If you only have a single application that uses your code, there's little reason to put it into a DLL. Multiple users on multiple computers are going to have to have their own copy of the DLL anyway, so there will be no code sharing going on in that situation.
All of that said, I have no idea what this question has to do with VB 6. To my knowledge, you can only use it to create ActiveX DLLs (which have a different use case) and it can't create static libraries at all.