* 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 > /home/heb/temp/kde-pim-3.3.1/korganizer/.libs/lt-korganizer > is linked to the correct library > /home/heb/temp/kde-pim-3.3.1/lbkcal/.libs/libkcal.so.2.0.0 > > (even the "--rpath" statements are included). > > Unfortunetly the "ldd" has "/opt/kde3/libs" first in line, and during > run-time > 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 -> > /home/heb/temp/kde-pim-3.3.1/lbkcal/.libs/libkcal.so.2.0.0 > > 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? Regards, Ralf _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
