6

I am trying to build a project which uses an unmodified copy of libconfig (http://www.hyperrealm.com/libconfig/). libconfig is LGPL, but I don't want to open source any of my code. By my understanding, LGPL means I need to provide the source for the library (easy), and a means for them to use their own modified version of the library. It's the latter component that confuses me a bit (apologies for some c naivete).

Currently, my VS2010 solution has my project, and the libconfig project. The libconfig project builds a dll, but I also need to link my project against the .lib of libconfig to get the dll's definitions (Can someone explain why this is necessary, when I'm already including the header file?). Despite the linking, the .dll file needs to be present at runtime for the binary to be able to run

Do I need to provide all of the .obj and .lib files I produce to satisfy the LGPL? Is there a way to avoid the linking of the .lib file? I've looked into LoadLibary and GetProcAddress but it looks way more complicated than I'd like.

Or am I simply overestimating the requirements of the LGPL here?

If there's another, more permissive config library for c++, that would also solve my dilemma. But I haven't been able to find something (and I'd like to avoid boost).

2 Answers 2

8

The "means for them to use their own modified version of the library" in this context is letting users use their own libconfig.dll instead of yours if they want. By making it dynamically linked you have fulfilled this requirement. They can just replace the file. If you had made it statically linked instead, where you don't need the libconfig.dll in order to run, you would also have to provide your object files and build scripts.

3
  • Excellent, thats what I wanted to hear. Can you explain why its necessary to link against the .lib if the .dll is being loaded at runtime? Mar 27, 2013 at 19:36
  • I'm not sure on that one. You might want to split that off into a separate question. I believe it's so the linker can report unresolved symbols at link time. Mar 27, 2013 at 22:00
  • 1
    @user2093082 the lib you link against is called a stub, it just tells your program's linker what the function names and prototypes are in the dll. If the dll doesn't change the function prototypes (in which case you couldn't use them anyway) you don't need to change the stub. Mar 28, 2013 at 2:58
3

The libconfig project builds a dll, but I also need to link my project against the .lib of libconfig to get the dll's definitions (Can someone explain why this is necessary, when I'm already including the header file?).

To put it simply, header file gives you a guide how to call the function(s) from library, i.e. what is the name of function, what parameters does it accept, what is the calling convention, what is return type. On the other hand, Lib file gives your complier a guide where to find the function, i.e. it is in the libconfig.dll library at relative address 0x123456 (or whatever the relative address of function is) , so that compiler can generate code for binding to function.

Is there a way to avoid the linking of the .lib file?

Yes, you can dynamically load the DLL using LoadLibrary and then find address of the Function using GetProcAddress with function's name as parameter. Then you would call the function using its pointer. In this case you would't need lib file, but you still need the header file, where you will find funtion's prototype.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.