Confused about upgrade path...

[Ralph Mack]

Whoops! Ignore the line with all the numbers. It wasn't in the output.
It's just the 80 character marker I use when composing eMail so the
SMTP servers won't wrap it on people. (Or should I use 70? 72? 60
to leave room for >>>>> on long threads?)

Also, I neglected to include my automake/autoconf versions:
automake-1.4p5-4
autoconf-2.13-17

My wife and son were in a hurry to get to breakfast and had waited
for me to finish collecting the data for the message just about as
long as they were about to, so I hit the send button without my last
proof-reading. Sorry about that.

Ralph

On Saturday, August 3, 2002, at 07:50 , Ralph Mack wrote:

> Hello all,
>
> I upgraded my system to Red Hat Linux 7.3 recently, which comes with 
> KDE 3.0
> and KDevelop 2.1. I also have the kde1-compat and kde2-compat stuff 
> installed.
> My automake and autoconf are:
>
> I had been working on a project using KDE 2.x and KDevelop 2.0 before 
> that.
> The project built and ran. In the new environment, I am unable to build 
> my
> project. Somewhere along the line, I may have messed up my settings, 
> as I
> wasn't sure which of the myriad directories I needed to point to for KDE
> and QT stuff. Specifically, I have:
>
> Qt 2.x directory [sic] /usr/lib/qt3-gcc2.96
> KDE 2.x directory [sic] /usr/lib/kde2-compat
>
> In any case, the crux of the matter seems to be on the link. In the 
> compile
> options, I have the kdecore, kdeui, and kfile options checked. The 
> problem
> seems to come with kfile. Here's my link output. (Note: I also 
> explicitly
> include cppunit, but that is my only additional library.)
>
> g++ -O2 -O0 -g3 -Wall -fno-exceptions -fno-check-new -fexceptions -o 
> kfudge
> traittabletest.o kfudgetraittable.o kfudgeview.o charactertest.o
> fudgecharacter.o traittest.o trait.o kfudgedoc.o kfudge.o main.o
> kfudgeviewbase.o kfudgetraittable.moc.o kfudgeview.moc.o
> mocktraittablecontroller.moc.o kfudge.moc.o kfudgedoc.moc.o 
> kfudge_meta_unload.o
> -L/usr/local/lib
> -L/usr/X11R6/lib
> -L/usr/lib/qt3-gcc2.96/lib
> -L/usr/lib
> /usr/local/lib/libcppunit.so
> -lkfile
> /usr/lib/libkdeui.so
> -L/usr/lib/gcc-lib/i386-redhat-linux/2.96
> -L/usr/lib/gcc-lib/i386-redhat-linux/2.96/../../..
> /usr/lib/libkdefx.so
> -lresolv
> -lXrender
> /usr/lib/libkdecore.so
> /usr/lib/libDCOP.so
> -lqt-mt -lpthread -ldl -lresolv -lXinerama -lstdc++ -lc -lgcc -lqt 
> -lpng -lz -lm
> /usr/lib/libjpeg.so
> -lXext -lX11 -lresolv -lSM -lICE -lresolv
> -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/local/lib 
> -Wl,--rpath
> -Wl,/usr/lib -Wl,--rpath -Wl,/usr/lib/qt3-gcc2.96
> /lib -Wl,--rpath -Wl,/usr/X11R6/lib
>
> /usr/bin/ld: cannot find -lkfile
> 12345678901234567890123456789012345678901234567890123456789012345678901234567890
> If I explicitly specify -L/usr/lib/kde2-compat/lib, it builds but core 
> dumps
> when I run it. I tried using /usr/lib/kde3 in my project options but 
> got the
> same effect. I finally added a link in my /usr/lib directory.
>
> ln -s kde2-compat/lib/libkfile.so.3 libkfile.so
>
> This let the thing build without explicitly specifying the directory in 
> the link
> options. Finally, I ran my program in the debugger. Not surprisingly, 
> it is
> bombing in a method in libkfile:
>
> 0x400de27c in endl() from /usr/lib/libkfile.so
> 0x403ddfb4 in KLocale::doBindInit() from /usr/lib/libkdecore-
> gcc2.96.so.4
>
> The kfile stuff is being used by boilerplate generated for the original 
> project,
> not from my own code. Given that KDE is going well out of its way to 
> discourage
> me from using it, where do I go from here?
>
> Ralph
>
>
> -
> to unsubscribe from this list send an email to kdevelop-
> request at kdevelop.org with the following body:
> unsubscribe ªyour-email-address´


-
to unsubscribe from this list send an email to kdevelop-request at kdevelop.org with the following body:
unsubscribe »your-email-address«