Making static library with MinGW

[Tex Killer]

Hi.

There is a file compressor called FreeArc (that has GPL code) and a sub project called Unarc (meant for file extraction only) that is free for any use.
Their source codes can be downloaded from here: http://freearc.org/Download-Alpha.aspx

Unarc has a makefile for making a dll. I am trying to make it static instead (.a file), using MinGW, but am failing.

If I use the .o files compiled by the makefile to make one .a file, the decompression methods don't seem to be recognized as they should, so I can't extract anything. These decompression methods are added through static functions called withing the .cpp files of each method, so I guess their code is not being executed.

Do you guys happen to know what am I missing?

By the way, this is my first post here, so I'm sorry for any mistakes I did. I'm also sorry for any english misspelling errors, as english is not my main language.

[Tex Killer]

Anyone?

[laserlight]

From the MinGW Wiki: HOWTO Create an Import Library for a DLL using MinGW

[Paul McKenzie]

If I use the .o files compiled by the makefile to make one .a file, the decompression methods don't seem to be recognized as they should,

First, it isn't as simple as just collecting the .o files and creating one .a file. Those .o files were compiled with certain command line switches that more than likely effect how the code is compiled with respect to creating a DLL. The effect is that the functions being called could have a different signature, calling convention, and other things that make them "DLL aware" as opposed to being used in a static library.

You need to look at the source code, look at a function you would call, and see if there is something in the signature, calling convention, etc. that must be changed for it to be used in a static library. Usually for DLL's, the calling convention for exported functions is __stdcall, but for static libraries/internal code is __cdecl.

So again, it isn't as simple as just using the .o files. More than likely, you have to recompile the code using different command switches, or worst case, change the code so that the functions are just normal functions you would call as opposed to exported DLL functions.

Regards,

Paul McKenzie

[Tex Killer]

Thank you for your answers.

Paul, does that also apply to functions called statically inside the .o files, or just the ones I call? Because the function I am calling is being executed ok, but the functions that were supposed to be statically called on the .o files are not being called, or so it seems.

This is an example of those functions:

static int LZMA_x = AddCompressionMethod (parse_LZMA);

Thank you for your time.

[Paul McKenzie]

Thank you for your answers.

Paul, does that also apply to functions called statically inside the .o files, or just the ones I call? Because the function I am calling is being executed ok, but the functions that were supposed to be statically called on the .o files are not being called, or so it seems.

Any function that is in the static library, whether you call them or some other entity calls them, it makes no difference.

You should create a debug version of your static library and debug the code.

The bottom line is this -- when you move from using a DLL to using a static library, you have to change something for your code to recognize those functions are no longer exported DLL functions. That may mean recompiling the .o files with different command line options, maybe compiling your code that uses the library with a different set of switches, or possibly having to change the source code itself.

My company creates static libraries from the DLL's that we have. In no way could we just compile the code from the DLL and package it into a static library as-is. Calling conventions had to change, any reference to module handles has to change (since a module handle in a DLL is different than an application's module handle), etc.

My advice -- you need to have a good, thorough understanding (and experience) of making a static library instead of a DLL. Unless the authors documented how to go about creating the static library version, I seriously think you don't go this route until you know for sure what you're doing.

Regards,

Paul McKenzie

[Tex Killer]

Thanks.

Can you point out the topics I have to study?

[Tex Killer]

Man, all the tutorials I find about static libraries teach how to use ar.exe and how to do the linking, but that I already got covered... Can anyone point me to the specific topic(s) I have to learn in order to do this?

Thank you.

[Paul McKenzie]

Man, all the tutorials I find about static libraries teach how to use ar.exe and how to do the linking, but that I already got covered... Can anyone point me to the specific topic(s) I have to learn in order to do this?

Thank you.

Forget about the tutorials and debug the code you have now. That is what I suggested earlier. Since you have the entire source code, run it under the debugger and figure out why the function doesn't get called or doesn't work. Building the static library without compiler or linker errors, regardless of whether it finally works or not, is 3/4ths of the work done. The last 1/4 is diagnosing bugs, and right now it could be a simple bug, or it may require a rebuild with a #define constant being used, etc.

Believe it or not, this approach is one of the best ways to figure out why the static library doesn't work. Once you see up front why the function doesn't work, then you know what you are missing, what needs to be #defined, etc. There is no tutorial for this -- this comes by experience and taking what doesn't work, diagnosing the problem, and fixing it.

Regards,

Paul McKenzie

[Tex Killer]

Thank you very much, but I already debugged the code, and my breakpoint on that file never gets the execution to stop. How would I know why that line is never executed if it is static?

[Paul McKenzie]

Thank you very much, but I already debugged the code, and my breakpoint on that file never gets the execution to stop. How would I know why that line is never executed if it is static?

Somewhere you called a function that does get called that starts the whole chain of events to occur. From there, you single step through your program (do not rely on a breakpoint) and see where the program flows. Setting a breakpoint on code that you know doesn't get called doesn't help -- you know it won't get called, so why waste time putting a breakpoint there?

Stepping through the code, you should discover that some condition made the code "skip" the function call -- whether that is a variables being wrong values (possibly due to the difference between DLL and static library), or some other condition that is "false" (or true) when it should be the opposite value, or maybe there is code that only works if it is called via DLL (the module handle example is one I mentioned).

Regards,

Paul McKenzie

[Tex Killer]

I guess you didn't get the full picture... That function is to be called statically, on the global scope, and not inside other functions.
I did go through the code, as you suggested, but doing that I only found out that the function was never called.


Thank you for your time and help.

[Paul McKenzie]

I guess you didn't get the full picture... That function is to be called statically, on the global scope, and not inside other functions.

So who calls this function? Functions just don't get activated just like that. Some module called the function. So I'll atempt to clarify what you have:

You have an object declared globally, and you're relying on the constructor of that object to be called before main(). Is that it? If it is, then there is a lot of information on the dangers of relying on global objects to be instantiated in a certain order, and even if they're instantiated to begin with.

Regards,

Paul McKenzie

[Tex Killer]

I've posted this line on my third post:

static int LZMA_x = AddCompressionMethod (parse_LZMA);

The thing is, those lines work on the .dll, but not on the .a. Can you tell me what are those dangers you mentioned, and how to fix the problem?

Thank you very much.

[Paul McKenzie]

I've posted this line on my third post:

static int LZMA_x = AddCompressionMethod (parse_LZMA);

The thing is, those lines work on the .dll, but not on the .a. Can you tell me what are those dangers you mentioned, and how to fix the problem?

That one line of code needs more context.

void SomeFunction()
{
   static int LZMA_x = AddCompressionMethod (parse_LZMA);
}

or

static int LZMA_x = AddCompressionMethod (parse_LZMA);  // outside all functions

void SomeFunction()
{
}

Which one is it?

If it's the second, then that function is not going to be called unless a function that is defined below that call actually uses the variable. Since it is a static variable, it is in scope only at the point where it is declared.

Another thing is that in the compilation unit where that static variable is declared, if no function in that compilation unit is ever called, then the linker optimized away all of that code.

If you really want that function to be called, then put it inside a function that will be called instead of making it a static global.

But the question is why did you expect that function to be called? Are you using that static variable anywhere, and is it uninitialized when you use it? Again, if you aren't using that variable anywhere, then the linker optimized that variable away.

Regards,

Paul McKenzie