How do I source/link external functions in C or C++?

Question

EDIT: I suppose I should clarify, in case it matters. I am on a AIX Unix box, so I am using VAC compilers - no gnu compilers. End edit

<

Answer 1

You've got a third option. In general, your C++ compiler should be able to link C routines. The necessary options may vary from compiler to compiler, so R your fine M, but basically, you should be able to compile with g++ as here:

$ g++ -o myapp myapp.cpp myfunc.c giveint.c

... or compile separately

$ gcc -c myfunc.c
$ gcc -c giveint.c
$ g++ -c myapp.cpp
$ g++ -o myapp myapp.o myfunc.o

You also need to include your declaration of the functions; you do that in C++ as

extern "C" {
    int myfunc(int,int);
    int giveInterger(void);
}

Answer 2

You need to distinguish between recompiling and relinking.

If you put giveInteger() into a separate (archive) library, and then modify it later, you'll (obviously) need to recompile the source file in which it is defined, and relink all programs that use it; but you will not need to recompile such programs [1].

For a shared library, you'll need to recompile and relink the library; but you will not have to relink or recompile any of the programs which use it.

Building C++ shared libraries on AIX used to be complicated; you needed to use makeC++SharedLib shell script. But with VAC 5.0 and 6.0 it became quite easy. I believe all you need to do is [2]:

xlC -G -o shr.o giveInteger.cc
xlC -o myapp main.cc shr.o

[1] If you write correct Makefile (which is recommended practice), all of this will happen automatically when you type make.

[2] There is a certain feature of AIX which may complicate matters: by default shared libraries are loaded into memory, and "stick" there until subsequent reboot. So you may rebuild the shr.o, rerun the program, and observe "old" version of the library being executed. To prevent this, a common practice is to make shr.o world-unreadable:

chmod 0750 shr.o

Answer 3

Yeah you are correct. The first is called a static library, while the second is called a shared library, because the code is not bound to the executable at compile time, but everytime again when your program is loaded.

Static library

Compile your library's code as follows:

gcc -c *.c

The -c tells the program not to link the object file, but just leaves you with object files for each .c file that was compiled. Now, archive them into one static library:

ar rcs libmystuff.a *.o 

man ar will tell you what the rcs options mean. Now, libmystuff.a is a archive file (you can open it with some zip-file viewers) which contain those object files, together with an index of symbols for each object file. You can link it to your program:

gcc *.c libmystuff.a -o myprogram

Now, your program is ready. Note that the order of where the static libraries appear in the command matter. See my Link order answer.

Shared library

For a shared library, you will create your library with

gcc -shared -o libmystuff.so *.c

That's all it takes, libmystuff.so is now a shared object file. If you want to link a program to it, you have to put it into a directory that is listed in the /etc/ld.so.conf file, or that is given by the -L switch to GCC, or listed in the LD_LIBRARY_PATH variable. When linking, you cut the lib prefix and .so suffix from the library name you tell gcc.

gcc -L. -lmystuff *.c -o myprogram

Internally, gcc will just pass your arguments to the GNU linker. You can see what arguments it pass using the -### option: Gcc will print the exact arguments given to each sub process.

For details about the linking process (how some stuff is done internally), view my Linux GCC linker answer.