Static Linking and LGPL

Isn't that how all dynamic linking works. You have to include a header which defines the API to the library. I'm pretty sure this clause is accounted for in the LGPL license ( but you'll have to do more searching to be certain ).

-ddn

Well that's just it. I don't do a lot of C++ so I don't know if that's how all dynamic linking works. It's the only way I know. I assumed that the headers and the lib were just accompanying files, not considered part of the source and that so long as you needed to distribute the DLL in order to run, you were linking dynamically. Then I was told by "someone who knows better" that I was wrong and I was statically linking. So I thought I'd put it out there and be sure.

The only part of the LGPL I can find which gets close to this subject is this:

Quote:

1) Use a suitable shared library mechanism for linking with the Library. A suitable mechanism is one that (a) uses at run time a copy of the Library already present on the user's computer system, and (b) will operate properly with a modified version of the Library that is interface-compatible with the Linked Version.

From my knowledge of C++ this is true. If the library is interface-compatible, the LibX.a would be identical so it would work without me modifying anything.

Quote:

Original post by sybixsus Well that's just it. I don't do a lot of C++ so I don't know if that's how all dynamic linking works.

It's not the only way. There are essentially two ways to accomplish dynamic linking under Windows (and Linux and OSX). Implicit linking and explicit linking.

Implicit linking provides the linker with information about the DLLs structure, so that the DLL can be automatically linked when the executable is run (or at some later point, if delay linking is used). This structural information (import and export symbols) is supplied by a lib file, and can be generated in various ways (through declspec directives, DEF files, etc).

Explicit linking doesn't require a lib file. The DLL will not be automatically loaded by the application, but manually. The application uses functions such as LoadLibrary and GetProcAddress to load the DLL and bind to entry points. In this scenario, no additional files apart from the DLL itself (and the headers) are required.

Now about the LGPL, I would assume that both methods are fine, because they both allow other people to replace the DLLs code with their own (*shudder*). IANAL though. To be entirely honest, I would avoid anything remotely resembling the GPL or LGPL like the plague, unless you put your own code under the same license. What LGPL'ed library are you using ? There might be a better alternative with a more convenient license available.

Thanks for the information, Yann. I was loosely aware of GetProcAddress but I thought it was only really suitable for pure C libraries, as I couldn't see how you could include classes and methods within them, etc.

I have traditionally stayed away from the GPL and the LGPL, having always preferred to find libraries with a ZLib/BSD license. On this occasion, however, the project is going to involve some pretty heavy duty tools (which would be released, not private tools) and I really wanted to use the newly-LGPL'ed QT for the GUI.

In the past I've used WXWidgets and it's very nice, but it's not quite up to QT standards. I guess I could always send Nokia an email for clarification, but it always seems a bit of a cheek to ask for assistance when you're using their software for free. I was hoping it was fairly well-established how LGPL projects could be linked, but in truth, I didn't think it would be so. The GPL and LGPL have caused arguments and opposite interpretations for as long as I can remember.

You have to link dynamically to QT. It just means that you use the default config of QT and you have to ship the DLLs next to your executable. Apart from that, you're fine.

And I can really recommend Qt. I'd normally stay away from GPL/LGPL as much as possible, but Qt is a notable exception.

Over all it really depends on what you want and the license the library uses.

"Static Linking" does not require the dll's everything is embedded into the exe.
"Dynamic Liniking" the dll's must be present.

The license is very important here. For instance SDL uses LGPL. Under the LGPL if you read it carefully if you Dynamic Link the libraries it does does not matter what license you release the app under however, if you static link a LGPL library you must release your code under the LGPL.

Quote:

Original post by blewisjr Under the LGPL if you read it carefully if you Dynamic Link the libraries it does does not matter what license you release the app under

Correct.

Quote:

however, if you static link a LGPL library you must release your code under the LGPL.

Incorrect. Here are your responsibilities if you static link a LGPL library:

1. You must mention somewhere in your docs that you use the library, and that it is covered by the LGPL.
2. You must include a copy of the LGPL.
3. You must include the source code of any file that directly uses that library; for instance any wrappers. Your code that calls the wrappers need not be included.
4. You must include the rest of the program as object files, or something to link with. Source code is not required.

The theory is that the user should be able to change the way you interface with the library, compile the changes to the interface, and then relink the whole thing into a new executable.

So let's say you are using some (made up) library, GNUsound. Let's also assume you are horrible at organizing you code and you have:

main.cpp, gnusound.cc



Well, now you have to hand out the source code to main.cpp! We don't want that, so we'll create a new file as a wrapper (but not because we don't want to share, but because generic interfaces are better design!).



Now, when we send out our project, we have to include the following files:

1. this_program_uses_gnusound.txt
2. LGPL.txt
3. sound.cpp
4. main.o

Then the user could change the sound interface to the (also fictional) BSDsound library, recompile the interface file, and relink the project into a new executable.