KDE 3.1 build issues w/ DRT templates
thiagom at wanadoo.fr
Fri Feb 7 11:59:32 GMT 2003
Amir Michail wrote:
>(2) we would like to instrument a shared library, such as kdeui say,
> and have applications make use of this instrumented library
> instead of the standard one. Yet using LD_LIBRARY_PATH to get the
> application to use the instrumented version doesn't work; it simply
> uses the uninstrumented version instead. Adding
> -Linstrumented_lib_path to LDFLAGS before configuring appears to only
> work sometimes: it usually fails because the configure script ignores
> LDFLAGS and even when it doesn't ignore it, the application still
> links with the uninstrumented version for some reason.
That could be because KDE binaries come with the path to the library hardcoded
by the linker. That is, they have a search path in the RPATH record of the
header that takes precedence over LD_LIBRARY_PATH. You have to disable rpath
(--disable-rpath) in order for LD_LIBRARY_PATH to work.
>(3) for packages such as kdelibs, it appears that certain directories
> depend on other directories. We would like to build an instrumented
> version of kprint say without having to compile/instrument other
> libraries that it may depend on. Rather, if we compile/instrument
> kprint only, it should use the existing installed libraries (which
> are perhaps not even compiled in the kdelibs-3.1 directory at this
> moment); this doesn't appear to be possible in the current setup.
Indeed, all KDE programs depend on kdecore, which in turn depends on dcop and
kdefx. GUI programs also depend on kdeui.
I don't think I understand the impact of the instrumentation. What happens if
you run an instrumented kprint with the standard kdecore?
Thiago Macieira - UFOT Registry number: 1001
thiagom at mail.com
ICQ UIN: 1967141 PGP/GPG: 0x6EF45358
Registered Linux user #65028
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
More information about the kde-core-devel