[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: debugging/developing libraries, library is installed under the same
Re: debugging/developing libraries, library is installed under the same name in 2 different version
Thu, 9 Dec 2004 11:35:32 +0100
* Hebenstreit Michael wrote on Thu, Dec 09, 2004 at 10:37:20AM CET:
> I a problem and hope you can help me. I tried to debug a kde/korganizer
> library in my home-dir, having installed the same package on the (linux)
> system. This leads to the following situation
> standard library: /opt/kde/lib/libkcal.so.2.0.0
> library with debug
> information: /home/heb/temp/kde-pim-3.3.1/lbkcal/.libs/libkcal.so.2.0.0
> programm to be
> debuged: /home/heb/temp/kde-pim-3.3.1/korganizer/.libs/lt-korganizer
> According to the output of libtool at compile/link-time
> is linked to the correct library
> (even the "--rpath" statements are included).
> Unfortunetly the "ldd" has "/opt/kde3/libs" first in line, and during
> uses /opt/kde/lib/libkcal.so.2.0.0
Helpful information (please use copy and paste) includes the
- system used (OS, hardware, distribution)
- link line and produced output (`libtool --mode=link...')
$ objdump -p .libs/lt-korganizer
$ ldd .libs/lt-korganizer
$ ldd .libs/libcal.so
> The easiest way to prevent this is to generate a link
> /home/heb/temp/kde-pim-3.3.1/korganizer/.libs/libkcal.so ->
> focing the ldd to take the correct library.
No, what you did should Just Work[tm].
> Is there a simple way to use automake/libtool to circumvent this problem?
> libtool used:
> ltmain.sh (GNU libtool) 1.5a (1.1240 2003/06/26 06:55:19)
Hmm, this is a development release, and a quite old one. Did you build
this yourself, or is there a software distributor who packs this into a
release? Can you perchance try again with either released 1.5.10 or
unreleased current branch-2-0?