A shared library usually (if not always) provides header files containing the public API.
So, instead of trying to grab (public) function directly from the library, you should try to find these header files, because they:
- are required for compiling your application
- might contain documentation
- contain the public API as intended by the developer
EDIT
In you example you define
void libtest1();
This should typically go into the header files belonging to the library. And instead of the definition you should use:
#include "libtest1/public_api.h"
(or something similar, depending on your library/header names)
If you 'lose' the header then the library becomes 'worthless', as you do not know the public API anymore and need to guess (which is obviously undesired).
The reason why, not using a header file, 'just' works, is because you actually know the definition of the function. The compiler trusts your definition (as it does not know whether you guessed it or not) and accepts it. When you are going to link your object files into the executable, the linker tries to find all references to undefined function in libraries. During this stage the linker finds out whether your function actually exists (with the correct parameters and return type), if not it will generate an error.
In the case of libstone2goldconverter.so
you should look really hard to find the accompanying header files (on your system, supporting website, by emailing the author, etc.). As there is no way you can use the library (properly) without the header files.
This goes not only for you (the developer), but also for the owner of the library. So, you can be certain that the header files do exists somewhere. Only thing is: your libstone2goldconverter.so
library look proprietary and the author/company of the library is not likely to give you their header files, as it severely compromises their marketing position... ;)