NO

Author Topic: Problem with using a static library  (Read 3890 times)

karzzon

  • Guest
Problem with using a static library
« on: June 23, 2014, 07:38:14 PM »
I am having an issue when I try to use a static library that I have previously created.  I wrote a binary tree implementation first as a console project and then later made it in to a static library.  Now I am trying to link the library in a new console project.  I have added the projects path to both the includes path and libraries path.  The project does fine the header and even autocompletes its name for me.  The project seems to find the .lib file too since it is not complaining about not finding it.  The compiler error I am getting when I try to use a function from the library is:

Code: [Select]
POLINK: error: Unresolved external symbol '_btree_init'.
POLINK: fatal error: 1 unresolved external(s).

This error changes to display about the specific function I try to use.  I don't know why it is appending an underscore to each function.

I have tried adding my library to the "Library and object files:" and by using #pragma lib "btree32.lib".  I have not tried both at the same time though.  Another thing is that nowhere in my code is there a function called '_btree_init'.  A function exists without the underscore though.

The static library I created is just a header for interface and source file for implementation and compiles without errors.  I used the same code copied to a console application without a problem.

Does anybody know how to properly link a static library that is another project?


« Last Edit: June 23, 2014, 08:17:16 PM by karzzon »

Offline frankie

  • Global Moderator
  • Member
  • *****
  • Posts: 2113
Re: Problem with using a static library
« Reply #1 on: June 24, 2014, 09:07:02 AM »
You have to read something about calling conventions and code decorations  :)
It's standard to prepend an underscore to C symbols representing variables, functions, etc.
If the calling convention is __stdcall symbol will be also postpended by an '@' followed by the number of bytes occupied by function parameters on the stack. You don't need to care about this because the compiler will take care of all.

Now open your static project lib and look in option->compiler you will see that by default the calling convention is set on __stdcall, if you check your console project you will find default calling convention set to __cdecl.
When you include the definition file containing i.e.
Code: [Select]
int MyFunc(int a);Because the default for console project is __cdecl also your prototyped libraries will be considered as __cdecl, and the linker will search for a symbol '_MyFunc' in your library and will not find it.
That's why your library have __stdcall as default and creates the symbol '_MyFunc@4' (for 32 bits project).
The correct way to solve the issue is to always specify the convention in the function prototype:
Code: [Select]
int __stdcall MyFunc(int a);Or, less nice and less correct, change the default calling convention to all your library.

To link a stic library simply add prototypes of functions you want to use in your source, then in project options open linker tab and add the library name in the libraries list. Maybe you want use folders tab to set the folder where is stored your library.

P.S. Forcing the use of the wrong calling conventions, apart from special case of function with no parameters, will lead to a program crash. I.e. if you compile a function in __stdcall then declare it in prototype to be a __cdecl or the reverse.
« Last Edit: June 24, 2014, 09:25:31 AM by frankie »
"It is better to be hated for what you are than to be loved for what you are not." - Andre Gide

czerny

  • Guest
Re: Problem with using a static library
« Reply #2 on: June 24, 2014, 10:01:16 AM »
The correct way to solve the issue is to always specify the convention in the function prototype:
Code: [Select]
int __stdcall MyFunc(int a);
This is only possible, if the -Ze option is set!

karzzon

  • Guest
Re: Problem with using a static library
« Reply #3 on: June 24, 2014, 02:00:45 PM »
Thank you for the help, its working!