how can i make lib file in c

[Mahmed]

i want to know how can i make function in library files. in fact i want source code in c to make function's defination in library files, and prototyping in header file
for example:
int sum()
{
return 5+5;
}
pleaze send me step by step procedure.
i want prototyping of function sum() in header file sum.h and defination in sum.lib
how can i make both these files. i want to hide my source in lib files Thanks

 

[cfant]

On Linux create a libray file using ar.

 

[sinu_gowde]

Hi Mahmed,

A library is a collection of modules, each module containing one or more
function and/or data definitions. The granularity of the library is the
module, so the linker will extract full modules from the library, even if
it only needs one of the symbols defined within. The data inside a
library file is structured in such a way as to make the linker job as easy
as possible (linking in large static libraries used to be a major pain
back when disks were (much) slower than today).

Libraries are created with a special tool, let's call it the librarian.
Its input is one or more object files created by the compiler. The output
is a library containing each object file as a module. The librarian can
also perform library maintenance: remove modules, replace modules, add
new modules to the library, list the contents of a library.

The compiler typically doesn't know anything about libraries. And all
it needs to be told about them is the functions and data they contain.
This is usually achieved with the library header file(s) that accompany
the library itself. The compiler doesn't link *any* library, as this is
the job of the linker.

The linker will link, by default, the libraries that come with the
compiler, implementing the standard C library and whatever extensions
the implementor provides (I'll refer to them as the system libraries, in
the rest of this tutorial). To link your own libraries, you must
explicitly ask the linker to search them in the symbol resolving
process, by including their names, typically after the names of the
object files that use stuff from the libraries.

Here's a demo example, that should work on any Unix system. The code
itself is platform independent, only the commands used are Unix specific.
Finding their equivalents on your non-Unix system should be an instructive
exercise.

Our library contains two modules, each of them containing one function.
The library header file has to declare these two functions:

fangorn:~/tmp 74> cat demo.h
#ifndef DEMO_H_INCLUDED__
#define DEMO_H_INCLUDED__

void demo_foo(void);
void demo_bar(void);

#endif

The preprocessing directives are not really needed for this trivial
example, their purpose being to avoid the multiple inclusion of the
header. More complex headers need this kind of protection, however,
especially if they define their own macros.

Now, we have to implement the functions declared in the header:

fangorn:~/tmp 78> cat demo_foo.c
#include <stdio.h>
#include "demo.h"

void demo_foo(void)
{
puts("This is demo_foo in action");
}
fangorn:~/tmp 79> cat demo_bar.c
#include <stdio.h>
#include "demo.h"

void demo_bar(void)
{
puts("This is demo_bar in action");
}

Note that each file also includes the library header. This is necessary
to be sure that the actual function definition matches the function
declaration in the library header. It is very easy to change a function
defintion and forget to update the library header accordingly, so,
by including the library header we delegate to the compiler the job of
checking that the function declaration in the header and the function
definition in the source file are still in sync.

Now, it's time to build our library. First, compile our two functions to
object code:

fangorn:~/tmp 80> cc -c demo_foo.c
fangorn:~/tmp 81> cc -c demo_bar.c

As a result of this we have the files demo_foo.o and demo_bar.o that can
be used to build our demo library:

fangorn:~/tmp 82> ar r demo.a demo_foo.o demo_bar.o

Now, we have demo.a, a library (or archive in the Unix lingo, hence the
name ar for the librarian (archiver) and the .a suffix of the library
file). We can check its contents using the same command we used to
build it, invoked differently, of course:

fangorn:~/tmp 85> ar t demo.a
demo_foo.o
demo_bar.o

This doesn't tell us, however, what's inside each module. For that
purpose, Unix provides another command, the name extractor utility:

fangorn:~/tmp 83> nm demo.a

demo_foo.o:
00000000 T demo_foo
U puts

demo_bar.o:
00000000 T demo_bar
U puts

The symbols flagged with T are defined by the module, the symbols flagged
with U are used by the module but expected to be defined somewhere else.

And now we can use our demo library, with a program as trivial as the
library itself:

fangorn:~/tmp 89> cat demo.c
#include "demo.h"

int main()
{
demo_foo();
demo_bar();
return 0;
}

To build the application, we have two choices:

1. Compile the main program separately, then link the resulting object
with our library (and, implicitly, with the system libraries):

fangorn:~/tmp 90> cc -c demo.c
fangorn:~/tmp 91> cc -o demo demo.o demo.a
fangorn:~/tmp 92> ./demo
This is demo_foo in action
This is demo_bar in action

2. Take a shortcut and do everything with a single command line. This is
actually not possible on some non-Unix systems.

fangorn:~/tmp 93> cc -o demo demo.c demo.a
fangorn:~/tmp 94> ./demo
This is demo_foo in action
This is demo_bar in action

The cc command recognises files with the .o and .a suffixes as object and,
respectively, library files and doesn't attempt to perform any operation
on them, except for passing them to the linker. The linker will put all
the object files together and then try to resolve any missing symbols from
the libraries supplied by the user, by including only the modules needed
for that purpose. If one library module uses symbols not already defined,
the libraries are searched again. For any symbols that are still
undefined, the system libraries are searched.

I have only addressed static libraries in this article, as these are the
libraries you're likely to be interested in, at your current level.

For completeness, dynamic (or shared) libraries need to be mentioned, too.
Some library functions, especially those from the system libraries, are
used by many programs. Including their code into each program needing
them would be quite wasteful, in terms of linking time, executable file
size and loading time. There is also the issue of libraries being
updated, security fixes applied and so on. Programs using static
libraries would need to be relinked in order to benefit from new
libraries.

The solution to this problem is the usage of shared libraries. Their
modules are not included into the executable file, the linker merely
checks which shared library modules are needed for resolving all the
unresolved symbols of the program. When the program is run, the loader
will check which shared modules needed by the program are not already
loaded in the system memory and load them there, rather than together
with the rest of the program. Once loaded in the system memory, any
other program needing them can use the same copy, thus saving both memory
and disk space. Another advantage is that no relinking is necessary to
take advantage of a library upgrade.

Unfortunately, everything related to the creation and installation of the
shared libraries is extremely system specific, but, most of the discussion
about how to write a library applies in their case, too. In many cases,
the same library exists in both shared and static format, built from the
very same source files.

cheers...

 

[niket_304]

use keil. caopy the function in txt fiel. rename the file with "name".h extension. define the variables & the functions as extren

 

[btbass]

most ide's compilers have a project option to compile to exe or lib.