While all info you provided was helpful to my general understanding, my link problems remain.
So, its time to give more info.
Examples of the specific linker errors that are troubling me:
/usr/local/lib/libboost_python.so.1.31.0: undefined reference to `PySequence_DelSlice'
/usr/local/lib/libboost_python.so.1.31.0: undefined reference to `PyNumber_InPlaceXor'
../cppTest/libUMLModel.so: undefined reference to `PyInt_FromLong'
There are actually 130 similiar errors.
The vast majority of these errors come from the boost_python shared library. The fact that a few are from my UMLModel library is understandable in that it uses the Python C API directly to do embedding work.
Note that my cppTest application only uses one function from the UMLModel shared library at this point. In fact, I commented out all code and replace it with "cout << "hello world" << endl" just for a test. The link problems remain the same.
The compiler switches employeed to build my cppTest application (obtained via bjam -a -n) are:
...found 27 targets...
...updating 2 targets...
gcc-C++-action ../bin/newUMLModel/cppTest/cppTest/gcc/release/cppTest.o
set -e
g++ -c -Wall -ftemplate-depth-100 -DNDEBUG -DNDEBUG -O3 -finline-functions -Wno-inline -I"../bin/newUMLModel/cppTest" -o "../bin/newUMLModel/cppTest/cppTest/gcc/release/cppTest.o" "../cppTest/cppTest.cpp"
gcc-Link-action ../bin/newUMLModel/cppTest/cppTest/gcc/release/cppTest
LD_LIBRARY_PATH=/usr/local/lib/python2.3/config:../cppTest:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH
g++ -s -o "../bin/newUMLModel/cppTest/cppTest/gcc/release/cppTest" -L"/usr/local/lib/python2.3/config" -L"../cppTest" "../bin/newUMLModel/cppTest/cppTest/gcc/release/cppTest.o" -lpython2.3 -lUMLModel -Wl,-rpath-link,.
Chmod1 ../bin/newUMLModel/cppTest/cppTest/gcc/release/cppTest
chmod 711 "../bin/newUMLModel/cppTest/cppTest/gcc/release/cppTest"
...updated 2 targets...
As per your advice, I investigated use of -rpath, -rpath-link. I see that the above only employs the later. I've tried only substituing it with the former. This had no affect.
Ian Lance Taylor wrote:
Jeffrey Holle <jeff.holle@xxxxxxxxxxx> writes:
The program uses a shared library which I have constructed. This library in turn uses boost.python and the Python C API.
The link errors all concern functions from the later, which start with "Py".
First question. Is it normal that a cpp client of a shared library share the resource requirements of the shared library?
It would help enormously if you posted the exact error you are getting, rather than paraphrase it. Please try to be specific in bug reports.
So I'm not sure I understand the question, but I'll take a stab at it. When you run a program, all the symbol references should normally be resolved somewhere. The linker tries to help you out by double-checking this at link time. It essentially emulates the search done by the dynamic linker to make sure that all symbols are defined.
In the CVS version of the linker there is an option to control this: --unresolved-symbols. It's probably not in your version of the linker, though. I can't remember whether there was another way to control this in older versions.
Anyhow, the sort of error I am talking about, which looks like warning: SYM, needed by FILE, not found (try using -rpath or -rpath-link) does not imply that the client of the shared library shares the resource requirements of the shared library. It implies that when you run the program, there is a good chance that it will fail, because SYM will not be defined. But if you arrange to use the right shared libraries, or in cases of lazy binding carefully avoid calling functions which are not defined, then the program may well succeed.
What is the difference between "normal" symbols and dynamic symbols? The later are obtainable from a library using the "--dynamic" option of the nm utility.
The normal symbol table is a complete list of the symbols in a program, modulo whatever strip options you use.
The dynamic symbol table is used by the dynamic linker to resolve dynamic references. Only symbols which the dynamic linker needs to see are put into the dynamic symbol table. The dynamic symbol table is loaded into memory at run time so that the dynamic linker can see it.
I've constructed a script that utilizes nm to find library modules defining specific symbols. It is: #!/bin/sh # Find the shared libraries that define specific symbol # arg 1 - the root directory from which to search # arg 2 - the library name(s) to search for # arg 3 - the symbol to search for. find $1 -name "$2" -exec nm --print-file-name '{}' ';' | grep " [^ U] ""$3"
Third question Note the use of [ ^ U]. This matches only lines from nm that represent references of the symbols. I'm not sure that is what I want. I wish to find only symbols that lead to resolution of my linker errors. Should I instead by search for a specific type, maybe like "D"?
As you say, U means that the symbol is not defined, and is thus effectively a reference to the symbol. If you are looking for where the symbol is defined, then use nm --defined-only. If you are looking for definitions which the dynamic linker will see, then add --dynamic. (Also I would suggest xargs rather than find -exec.)
Ian
