From: John R. <jr...@bi...> - 2013-07-07 20:17:20
|
> gcc tsvd3.o -o tsvd3 -l:/libHigh.so -l:/libblasB.a -l:/libblas.so -l:/liblapack.so > > I am using -l: rather than -l because I was using debug versions > of libraries in different locations, but I was not able to get the > debug-info packages to work in the intended seamless way. > > Removing either the High or blasB library ( or both) from the link > line results in no errors being reported by valgrind. > This raises the following questions: > > -- The High library is not being referenced by the tsvd3 executable, so > why does the map file show that the blasB library is being used to > resolve references in the High library? Consult the output from "readelf --dynamic tsvd3". Naming a .so shared library on the command line generates a [DT_]NEEDED entry in the Dynamic table of the executable, so that shared library is *required* at execution time. The .so is not optional, even if the .so satisfies no undefined references at static link time. At static link time (during the running of /bin/ld), any undefined symbols of the .so get added to the set which ld will try to satisfy. Thus ld will search for any symbols which are undefined in libHigh.so, and if some .o in libblasB.a defines such a symbol, then ld will load that .o from libblasB.a into tsvd3. > > -- In the above link line, the lapack library comes at the end. I thought > that this would cause the lapack library not to see the blas symbols > earlier in the link line i.e. the linker should be complaining about > unresolved symbols. Why is the linker not so complaining? The search procedure for symbols which are undefined in shared library liblapack.so is an amalgamation of the [DT_]NEEDED entries within liblapack.so, the module tsvd3 (including its [DT_]NEEDED entries), any .a archive libraries that are specified on the command line at static link time, any -Rpath specifications, and the value of environment variable LD_LIBRARY_PATH. There are different rules between static link time and dynamic run time. Read the documentation carefully (info ld, man ld, etc.) > > -- Why is the linker not complaining about doubly defined symbols > in the blasB.a and blas.so libraries? "Doubly defined" pertains only to within one module (main program or shared library.) Separate modules can have definitions of the same symbol without complaint. Which symbol gets used depends on the search path, and the search path depends scope rules at both static link time (/bin/ld) and run time (dynamic link time, ld-linux.so) > > Of course, how does all this trick valgrind into flagging uninitialized > memory locations? The output of the svd3 program is correct with > both versions of the tsvd3 executable. Construct the smallest example which causes trouble. Post it here. |