[SOLVED] .a, .dll, and LGPL, turns out it was an "import library"

Before we begin, let me warn you that I started working with Code::Blocks last week, just started working with .DLL files today, and I likely have no idea what I'm talking about. Work with me here. Okay? Okay.

Long story short, I'm attempting to build a DLL out of some LGPL'd source code... in a handful of different IDEs... because I can.

Visual C++ 2008 Express: successfully build .dll and .lib files with default compiler; open new project; compile; link; run; OK.
Dev-C++: successfully build .dll and .a files with default compiler; open new project; compile; link; run; OK.
Code::Blocks: successfully build .dll and .lib files with GCC; open new project; compile; link... ERROR

Undefined References To half a dozen class methods. Right-clicking on said methods and choosing Find Declaration Of opens header files successfully. Right-clicking and choosing Find Implementation Of results in Not Found.

Here's the thing, though: when I replace the .LIB file with the .a produced by Dev-C++, everything works. Compile, link, run. So as far as I can tell (see initial disclaimer), I don't have Code::Blocks configured to build the correct library type. How do I do that?

Win Condition (pick any 1 of the following):
1. Configure Code::Blocks IDE to build an .a file which can be linked with successfully. (FULFILLED)
2. Configure Code::Blocks IDE to successfully link with existing .lib file using GCC compiler.
3. Phrase which, when Googled, returns a solution to (1) or (2) within the first 30 results.

Oh, one last thing: Wikipedia redirects ".a" to "static library". Can I use LGPL'd .a files without being required to release my entire game engine source code?

See rant on last post.

This post has been edited by exenefevex on Oct 25 2009, 07:46 PM

Go to Code::Blocks, Right-Click your project, click properties, click the build targets tab, change the type to Dynamic library.

You cannot link LGPL'd .a files without releasing the entire source code, as static linking with LGPL forces your project to be LGPL.

The type is already set to dynamic library. The files produced are [filename].dll and [filename].lib. I need to produce lib[filename].a (condition 1), or find a way to link with [filename].lib (condition 2).
Here was the problem: when I moved the project from VC to C::B, I copied the entire project folder, along with the VC output folders debug and release. Can you guess what happened? That's right, I used the dll and lib files from debug and release instead of the files in bin/debug and bin/release.

C::B is already configured to produce .a files. There was never a problem.

I want to make absolutely sure we are talking about the same thing here. The process I am referring to is discussed here in LazyFoo's tutorial. I was under the impression that this was a form of dynamic linking, but if we are both talking about the same thing then I will have to stop using SDL because the library files for DC and C::B are in .a format. (SDL files for VC2008 are in .lib format, but I cannot use VC2008 to build completed games because they are not guaranteed to run on every Windows system without additional installations.)

Please note that in both cases, I am still linking with the DLL file; the major difference is whether I use linker option -[filename].lib or linker option -l[filename], and whether the latter (which requires the presence of an .a file during the build process) is grounds for LGPL violation.

You know what? After further research, I'm going to assert that this is most definitely a dynamic link, by virtue of the fact that:

• Assigning LGPL to sdl.dll wouldn't make sense unless the provided files could be dynamically linked;
• Code::Blocks calls it a dynamic library;
• .Lib and .a files do not have any relevant differences in this case;
• The .a file is created in tandem with a dynamic link library file; and
• The new project will not run without the .dll file.

And after further examining the project options interface, it appears that the .a/.lib file in question is an "import library" and "accessor" which will not infect the rest of my source files.

This post has been edited by exenefevex on Oct 25 2009, 07:57 PM