KDE 3.1 build issues w/ DRT templates

[Thiago Macieira]

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
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20030207/076c6295/attachment.sig>