Making static library with MinGW

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.

Anyone?

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

Quote:

---

Originally Posted by Tex Killer

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

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:

Code:

---

static int LZMA_x = AddCompressionMethod (parse_LZMA);

---

Thank you for your time.

Quote:

---

Originally Posted by 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.

---

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

Thanks.

Can you point out the topics I have to study?

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.

Quote:

---

Originally Posted by 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.

---

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

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?

Quote:

---

Originally Posted by 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?

---

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

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.

Quote:

---

Originally Posted by 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.

---

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

I've posted this line on my third post:

Code:

---

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.

Quote:

---

Originally Posted by Tex Killer

I've posted this line on my third post:

Code:

---

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.

Code:

---

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

---

or

Code:

---

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

Paul, that code was made by the creator, not by me. The thing is, that function adds the method to some static list of compression methods elsewere, and that list is used... This static variable, however, is not.
Does the compiler remove code even without any optimizing option?
By the way, all works fine on the dll with the same source. Is something different for a dynamic library on this regard?

Thank you for your help.

Quote:

---

Originally Posted by Tex Killer

Paul, that code was made by the creator, not by me.

---

So now it's time for you to fix the code so that it works. I mentioned this to you already -- possibly the code as structured will not work correctly if it's a DLL and you have to go in and fix it.

Quote:

---

The thing is, that function adds the method to some static list of compression methods elsewere, and that list is used...This static variable, however, is not.

---

So now in the first line of your main() program, you call these functions, or create your own Init() function that gets called right when main() starts. The fix couldn't be more simpler than that, no? Because of the variable not being used , the linker may have thrown it away. Anyway, that routine should have been written in an Init() method, so that these surprises do not happen.

You are not to think of this as a static library and your code -- it's all your code now that will be used to create a single program. The static library is just a convenient way to take .o (or .obj) files and place them in a single file. Thinking of the static library as something separate and apart from the code you wrote is the wrong way to go about this.

A DLL is a different story -- you are working with two separate and completely different modules, one running independent of the other. The only thing holding your executable and the DLL together is that the DLL is loaded in the same address space as your program. So in this case, it is perfectly valid to think of the DLL as separate from your code, because it is separate. A DLL has it's own module handle, global variables, initialization routine and entry point (DllMain() as opposed to main() ), etc.

Quote:

---

Does the compiler remove code even without any optimizing option?

---

If the variable is not used, the linker has the option to remove it. It's the linker that is in play here, not the compiler. A static variable declared in a compilation unit will be removed if it isn't used. I don't know if functions with side-effects that are called are considered as reasons to keep the static variable around. So again, remove all doubt and call these functions yourself. The entry point for the program is now main(), and this is where you initialize your data structures if you need to.

Quote:

---

By the way, all works fine on the dll with the same source. Is something different for a dynamic library on this regard?

---

Read above.

Regards,

Paul McKenzie

Well, I was now able to add three methods myself (which allowed me to open an .arc file, but only one with uncompressed data), by pasting their signatures into my code and calling the AddCompressionMethod function to register them... But all the others (about 10) gave me "undefined reference", even though their compiled files are inside the .a file.

If I open the .a file on some text editor I can see the names of the files and functions that are not being found by the linker, so they are there. What could be causing the linker to ignore part of the .a file content?

Thank you very much.

Quote:

---

Originally Posted by Tex Killer

Well, I was now able to add three methods myself (which allowed me to open an .arc file, but only one with uncompressed data), by pasting their signatures into my code and calling the AddCompressionMethod function to register them... But all the others (about 10) gave me "undefined reference", even though their compiled files are inside the .a file.

---

Let's make this simple -- forget about creating a static library. Instead, take the source code, add each source to your project, compile, link, and run.

Once you get that to work correctly, then and only then should you be thinking about static libraries. At that point, it is just a matter of using the command-line "static library builder" (not sure which executable creates static libraries) and feed it all of the relevant .o files you created.

Regards,

Paul McKenzie