problem making my own library 
Author Message
 problem making my own library

all,
i am trying to understand making and calling libraries in C.

i think i have established that my code is correct (it will compile and
execute using gcc at the DOS prompt), however, it produces no results when
trying to use {*filter*}shed and the project facility.

i have done the following:

created a project with three files header.h, header.c and main.c

they compile fine, but produce nothing. code is listed below:

header.h

#ifndef _header_h
#define _header_h

extern int sum (int, int );

#endif

listing of header.c:

#include "header.h"

int sum (int x, int y)

{
int z;
z = x + y ;
return z;

Quote:
}

listing of main.c:

#include <stdio.h>
#include "header.h"

int main ()

{
int s;

s = sum (6,5);
printf("s equals %d",s);
system ("PAUSE");
return 0;

Quote:
}

this same code, when using gcc at the command prompt produces the desired
output.

any ideas what i am doing wrong?



Sat, 05 Jul 2003 07:47:50 GMT  
 problem making my own library

Quote:

>s = sum (6,5);
>printf("s equals %d",s);

try putting "\n" on the end of hte printf string, to force output.
Maybe that system command is messing with stdout ?
Quote:
>system ("PAUSE");



Sat, 05 Jul 2003 08:18:42 GMT  
 problem making my own library
You want to make a libarary of sum, is that correct?
Or are you just trying to compile a project with several files?
Anyway, youre code worked fine when I compiled those three files.
When you compile it, you must type like:
gcc main.c header.c -o main.exe.
You have to specify every file in your project.

If it was a library you wanted to make, then you have to make a object file
first.
You do this by typing:
gcc -c header.c
The you type something like:
ar r libhead header.o
and last:
ranlib libhead.a

So the procedure is
gcc -c <source file>
ar r <lib name> <object file>
ranlib <lib name>

Now, all you have to do is place the libhead.a in DJGPP\Lib folder and you
compile your program by typing:
gcc main.c -o main.exe -lhead

I hope this is what you wanted to perform.

By the way, I don't think you need that "extern" infront of the prototype to
the function sum.
As far as I know, extern is for other files to get access to your global
variables.


Quote:
> all,
> i am trying to understand making and calling libraries in C.

> i think i have established that my code is correct (it will compile and
> execute using gcc at the DOS prompt), however, it produces no results when
> trying to use {*filter*}shed and the project facility.

> i have done the following:

> created a project with three files header.h, header.c and main.c

> they compile fine, but produce nothing. code is listed below:

> header.h

> #ifndef _header_h
> #define _header_h

> extern int sum (int, int );

> #endif

> listing of header.c:

> #include "header.h"

> int sum (int x, int y)

> {
> int z;
> z = x + y ;
> return z;
> }

> listing of main.c:

> #include <stdio.h>
> #include "header.h"

> int main ()

> {
> int s;

> s = sum (6,5);
> printf("s equals %d",s);
> system ("PAUSE");
> return 0;

> }

> this same code, when using gcc at the command prompt produces the desired
> output.

> any ideas what i am doing wrong?



Sat, 05 Jul 2003 12:00:50 GMT  
 problem making my own library

Quote:

>If it was a library you wanted to make, then you have to make a object file
>first.
>You do this by typing:
>gcc -c header.c
>The you type something like:
>ar r libhead header.o
>and last:
>ranlib libhead.a

>So the procedure is
>gcc -c <source file>
>ar r <lib name> <object file>
>ranlib <lib name>

>Now, all you have to do is place the libhead.a in DJGPP\Lib folder and you
>compile your program by typing:
>gcc main.c -o main.exe -lhead

This isn't quite right. I think.

Static archives (what you create with ar) are not linked that way. Basically,
static archives contain object files and a table of contents. The linker simply
finds the desired object file and links it with the rest of the object files to
create an executable. Anyways, instead of doing "-lhead" you do "libhead.a".
You would do "-lhead" if you had a dynamic library (shared object) called
libhead.so (on most systems).

HTH.

--
"Gee, Toto, I don't think we are in Kansas anymore."



Sat, 05 Jul 2003 18:00:08 GMT  
 problem making my own library


Quote:
> By the way, I don't think you need that "extern" infront of the
> prototype to the function sum.
> As far as I know, extern is for other files to get access to your
> global variables.

you don't need it (and I don't put it in), but it does no harm.

Sent via Deja.com
http://www.deja.com/



Sat, 05 Jul 2003 18:37:54 GMT  
 problem making my own library
Oki, I didn't know that. Though it worked.

Jon,


Quote:

> >If it was a library you wanted to make, then you have to make a object
file
> >first.
> >You do this by typing:
> >gcc -c header.c
> >The you type something like:
> >ar r libhead header.o
> >and last:
> >ranlib libhead.a

> >So the procedure is
> >gcc -c <source file>
> >ar r <lib name> <object file>
> >ranlib <lib name>

> >Now, all you have to do is place the libhead.a in DJGPP\Lib folder and
you
> >compile your program by typing:
> >gcc main.c -o main.exe -lhead

> This isn't quite right. I think.

> Static archives (what you create with ar) are not linked that way.
Basically,
> static archives contain object files and a table of contents. The linker
simply
> finds the desired object file and links it with the rest of the object
files to
> create an executable. Anyways, instead of doing "-lhead" you do
"libhead.a".
> You would do "-lhead" if you had a dynamic library (shared object) called
> libhead.so (on most systems).

> HTH.

> --
> "Gee, Toto, I don't think we are in Kansas anymore."



Sat, 05 Jul 2003 19:04:50 GMT  
 problem making my own library
You can do something like:

gcc file.c -lhead -L.

and it should try loading it from the current directory.


Quote:
> You would do "-lhead" if you had a dynamic library (shared object) called
> libhead.so (on most systems).



Sun, 06 Jul 2003 08:02:46 GMT  
 problem making my own library

Quote:

...
> >gcc -c <source file>
> >ar r <lib name> <object file>
> >ranlib <lib name>
...
> This isn't quite right. I think.

> Static archives (what you create with ar) are not linked that way. Basically,
> static archives contain object files and a table of contents. The linker
simply
> finds the desired object file and links it with the rest of the object files
to
> create an executable. Anyways, instead of doing "-lhead" you do "libhead.a".
> You would do "-lhead" if you had a dynamic library (shared object) called
> libhead.so (on most systems).

ar archives/libraries contain (unmodified) copies of the
input files (here object files) plus metadata, although
it is distributed and not really a table of contents.

The linker normally starts with the object files you specify,
plus at least one supplied by the driver (gcc) typically crt0.o,
and then looks in each specified library to find object files
that satisfy unresolved references.  Some linkers do only
a single sequential pass, so if a module occurring later
in a library references something defined in a module
earlier in the library and _not_ referenced directly
by the user code or a yet earlier library module,
that definition isn't pulled in and linking fails.

Thus modules in a library have to be sorted
in an order which avoids backward references.
In the case of mutual recursion, you have to
put duplicate copies of at least some modules.
A real {*filter*} could work this all out by hand
and explicitly specify ar r lib.a first.o second.o third.o
but most folks let the computer do it, although the
canonical way was to compute the tsort-ed order
_first_:  ar cr lib.a `ranlib *.o`

GNU ar instead creates an index of the symbols
defined in members, so the linker can find them;
this is usually more efficient than a full scan too.
Some (other) linkers solve the problem by doing
an additional scan of the earlier library members,
or even earlier libraries, to resolve new references.

On (most?) Unices, and pseudoUnix gcc ports, -lfoo
will use either (shared) libfoo.so _or_ (static) libfoo.a;
if both exist it will usually prefer the former.
If you care about getting one or the other (only)
you should specify the exact filename.
On really different systems (OS/MVS? Be? ?)
this pattern of flags and filenames may not work,
not to mention that shared (or nonshared!)
libraries may not even exist.

--
- David.Thompson 1 now at worldnet.att.net



Thu, 17 Jul 2003 06:59:54 GMT  
 
 [ 8 post ] 

 Relevant Pages 

1. function scope when making your own libraries

2. making own libraries

3. making own libraries

4. Making a view own it's own DC in MFC

5. C4251 - enhancing 3rd-party library with own library

6. making my own irc client

7. Advice on making your own header file

8. Advise on making own header files

9. making my own UNIX2DOS program: questions

10. Making my own CRecordset superclass

11. Making my own device...

12. I'd like to use own DLL made from C functions in a VC program

 

 
Powered by phpBB® Forum Software