do you mind handing out a primer on linking vs static compiliing. Especially in the context of GPL?
@Ming while it's fresh do you mind handing out a primer on linking vs static compiliing. Especially in the context of GPL?
1 Reply
For the people that watched the Licences & Vulnerabilities Tech Tips where I talked about linking vs static compiling in the context of GPL...
When you want to make use of functions in a library within your code you have options:
So, I have a library,
This is classed as a derivative work so if the library was LGPL or GPL, then your code must also be GPL 2. Use the library as a shared object This means that the library code has been compiled with a
foo.c with some functions that I want to use in my application, bar
1. Use the library statically - that means the functions in the library are going to be part of your binary
- Compile the library
gcc -c -o foo.o foo.c
- Then make it a static library
ar rcs libfoo.a foo.o
- Now use it in your code
gcc -c bar.c -o bar.o
gcc -o bar bar.o -L. -lfoo
You have a single binary that includes both your code and the library's code.This is classed as a derivative work so if the library was LGPL or GPL, then your code must also be GPL 2. Use the library as a shared object This means that the library code has been compiled with a
-shared flag and you end up with a .so file - e.g. libfoo.so
In your code you can then link to that library
gcc -L. -lfoo -o bar bar.c
In this instance, the original library is untouched and your code is just making use of it. As long as the library ls licensed under LGPL, then your code can be commercial.
That is a highly simplified answer - I may do a blog post about it where I can use more space.
For those of you who didn't watch the tech tips... Go watch it on the replay!