x.h file definition in y.c file. how to link?

as the title says..

if I create a header file with name MyHeader.h and its corresponding definitions in different file MyFunction.c
or even general case.. I have those function definitions in multiple .c files..
how will the compiler know where the definition of a particular declaration is?

Ex:
MyHeader.h

Code:

---

#ifndef __MYHEADER_H
      #define __MYHEADER_H
        void f1(void);
        void f2(void);
    #endif

---

f1.c

Code:

---

void f1(void)
{
  printf("I am f1");
}

---

f2.c

Code:

---

void f2(void)
{
  printf("I am f2");
}

---

test.c

Code:

---

#include "MyHeader.h"
int main()
{
  f1();
  f2();
  return 0;
}

---

how should be the Makefile now?

The compiler does not know, it will be up the linker to resolve that issue. The various source code files (*.c) should all be a part of a project so that they all get compiled/linked together.

Quote:

---

how should be the Makefile now?

---

What are you using to compile/link?

Quote:

---

Originally Posted by hk_mp5kpdw

The various source code files (*.c) should all be a part of a project so that they all get compiled/linked together.

---

ok.. I will come to the exact problem..
its like I have a collection of lot of functions that might come handy while programming.. example: quicksort integers..
and these are in different locations & files
so I use the header file from the current program I am working on..
now I want to see that evertime I dont need to get the .c files and functions from that huge collection..
and I dont want to make them lib too.. as I want their code to be copied in my current program.. (portable)

Quote:

---

Originally Posted by hk_mp5kpdw

What are you using to compile/link?

---

cc on linux

So there seems to be two different problems:
1. Keeping a bunch of useful functions in multiple source files and making them into something that is useful elsewhere.

This is best solved by building the object files and making it a library using "ar". This will provied a file called "libsomething.a". Note that naming convention states that ALL libraries start with lib, hence "libiberity" makes sense when you use it in gcc with "-liberity" :)

2. Linking your application to those previously mentioned useful functions.

Just specify the ".a" file with

Code:

---

gcc -o myapp myapp.c -lsomething -L${HOME}/something/lib

---

Of course, to build all the source files and creating a .a file is best done with a Makefile or some other "automated build process" - Makefile is probably the most flexible and portable method.

You probably also need to have a set of automated tests that check if your library functions do what they should [which should include testing for reasonable error conditions].

--
Mats

Quote:

---

Originally Posted by matsp

So there seems to be two different problems:
1. Keeping a bunch of useful functions in multiple source files and making them into something that is useful elsewhere.

This is best solved by building the object files and making it a library using "ar". This will provied a file called "libsomething.a". Note that naming convention states that ALL libraries start with lib, hence "libiberity" makes sense when you use it in gcc with "-liberity" :)
Mats

---

Quote:

---

Originally Posted by gibsosmat

and I dont want to make them lib too.. as I want their code to be copied in my current program.. (portable)
cc on linux

---

i want them to be static.. i.e I dont want to ship the lib with my program..
if I make them lib and do what you said.. I will need to have that lib to run my program..
these are afterall assignments.. and will be run on different comp and they wont like me bringing libs for simple programs

If you link with a ".a" file generated using ar, rather than a ".so" file generated by a "ld" [possibly hidden behind gcc], then your code will be completely contained within your applicaiton. A .a file is essentially just a collection of object files that are extracted by the linker as needed. The entire object module is then included into your final executable.

A library is a very good way to "store" and "find" a bunch of small functions.

But if that's not what you want, then you probably want to copy the necessary source files into your current directory (or use "links", look up the subject of soft and hard links in Linux if you don't know what that means). But that's not very good concept for code-reuse.

--
Mats

ok.. thanks for the info..
I will try that..
I was thinking that .a & .so are both dynamically linked libs
so I didnt make those functions a lib