I have written a simple library and ended up with a .so file. I have a header file from writing the code that describes how to use the functions in the source code I have written. I think this .h files needs to be available to other programs that access this code.

I have seen lots of tutorials on how to copy the .so file to the relevant directories and make links with the version number. What I can't find is where to put the header file so that any programs I write to use my new library can access the header.

Hope this makes sense. For example, I might use <stdio.h> normally, I will need to access <mylibrary.h> once mylibrary.so is loaded (as far as I understand!)

It's weird, I've been using C compilers for embedded processors over ten years now and never given a second thought to how libraries and headers work behind the scenes!

Many thanks.

The "standard" places for headers are in "/usr/include" and "/usr/local/include". If you're using gcc, the "-I" option can be used to pass additional include paths, if it isn't in one of the default locations that it looks. Other compilers will have similar options.

1 members found this post helpful.

Hi -

For whatever it's worth, I would strongly suggest putting the header(s) in whatever "project directory" is convenient for you, and use "-I".

IMHO .. PSM

PS:
The client code should generally use double-quotes, not brackets:[code]#include "myheader.h"[/quote]

PPS:
If you haven't already done it, you might want to put "guards" in your header. For example:
[code]
/*
* My header file
*/
#if !defined(MY_HEADER_H)
#define MY_HEADER_H
...
#endif
/* MY_HEADER_H */[code]

Thanks, folks, that helps.

Paul, I had, indeed, done the #define thing in the headers. I thought that was something C++ insisted on, though I could well be talking out of my hat.

Hi -

Actually, it's just a "preprocessor thing". Handling the #include's, #ifdef's, and #define's occurs before either C or C++ see a line of code.

The purpose of these "guard's" is to make sure a header gets #included'ed once - and only once.

Otherwise, if A.cpp #include both A.h and B.h, and B.h also #include's A.h, then everything in A.h would be duplicated. Not good. The "guard" syntax prevents this from happening.

'Hope that helps .. PSM

generally one wouldn't put header files in system directories,
they are only needed during the compilation phase.
Unless maybe you have produced some sort of public library or SDK other people
will compile against. something widespread in the community.


plus they'll get clobbered if you install a new OS
unless you have them in 2 places which is a recipe for inconsistency.

If someone builds a program using your library, they will download your source or at least the -devel version of your package.
An end user won't need the header files, but your binary library package will be a dependency.

If you ever installed packages from source, you will notice that you also need the -devel packages for the same dependencies that the binary package uses. The main package will contain and install your .so library. A *-devel package will install the static version of your library and the header files.

For -devel packages that your distro installs, the library is installed to /usr/lib and the -devel libraries and files are installed to /usr/include in a directory named after the library. For example:
For a non-distro package installed from source, using /usr/local/ as the base for lib & include would probably be what you want to use. E.G.
/usr/local/lib/libbosco.so

/usr/local/include/bosco/libbosco.h