Hi there. Thanks for your feedback, Jonathan.
I am as confused as ever, which I think is down to the medium we're using (text). For me this is actually good news, as I'm going to use this as the basis for a new storyboard story (storyboard is a project of mine), where I'll try to explain my side graphically, and try to give others a change to express their views the same way. Anyway, back to treedb. Pkg-config --libs is the way packages express their most common link-case. I showed the output of "pkg-config --libs v3c" as an example. This pkg-config output is independent of whether you want to link statically or dynamically. For a static link it specifies archives. For dynamic, it specifies shared libraries. Libtool only mentions the direct dependants with dynamic linking. For static linking it has to mention direct and indirect dependencies. In treedb, libreedb-0.9.so is the default link library for programs using treedb. It includes libv3c-1.8.so, which has a function-call-tracing system implemented as stubs. If you explicitly want to debug a program, you link with libtreedb-0.9d.so, which includes libv3c-1.8d.so, which has a function-call-tracing system implementation. Shared libraries can't link to libreedb-0.9.so or libreedb-0.9d.so, because, in doing so, they're choosing the function-call-tracing system, stub or real. They can't do this. It's wrong. It's bad. At the very least it would require two versions, and that could mushroom if you're building and using several shared libraries that use v3c. They can't know whether the final shlib or program wants debugging or not. All they can do is link to the libreedb-0.9-bare.so variant and trust that eventually the v3c function-call-tracing-system symbols will find their way into the final link command, either as stubs or as a "real" implementation. There's my problem. Philip -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
