You are not logged in.

#1 2014-07-11 08:51:12

Firefishe
Member
Registered: 2012-10-01
Posts: 2

Kvirc from SVN {NON-Standard-Install-Method} and Overcoming 2 Problems

Hello, everyone.  Firefishe here.

There are certain programs I like to compile from source code, outside of the normal arch hierarchy of PKGBUILD's.  One such program is the Internet Relay Chat client, "KVIRC".

I've been using kvirc for years, and I like to keep it as up-to-date as possible, just like Arch!

This is why I like to use the svn version, so I can update it quickly and uniformly.  I like--as a user--to contribute back to the project.  (I had one of my bug reports translated into an instant commit by the main project author, himself, once.  That made me feel quite good, so it really does help to do a few things like this now and again.

Okay, on to the main topic.

I'm writing this to alleviate a nagging problem that had been plaguing me for months in 2013.  Qt5 just wasn't compiling kvirc very well back then.  The fact is, the echoing strains of "qt5 is broken in kvirc" from the #kvirc channel on Freenode, resounded soundly throughout that entire year.  Qt5 was still a bit buggy, and not all the libraries (32bit or 64bit) were quite finished.

Move forward to (now) July, 2014!  I have now compiled kvirc successfully on my 64bit (with 32bit multilib installation) laptop, and kvirc is purring away with a current svn build of kvirc.

However, I ran into some issues, which I would like to share with you, below:

I usually go about compiling kvirc from svn like this: (I usually start from my /home/userNameHere directory.)

{arch@homedir}$ svn co https://svn.kvirc.de/svn/trunk/kvirc
{arch@homedir}$ cd kvirc
{arch@homedir}$ mkdir release
{arch@homedir}$ cd release
{arch@homedir}$ ccmake ..

[At this point, the 'ccmake ..' command invokes cmake-gui, an ncurses-like graphical user interface, with a list of menu items pertaining to various libraries and flags that can be set.  cmake-gui makes selecting these flags and libraries quite easy, and also gives a clear indication of what directories may not have been found (which will be discussed a bit later.) ]

Press the 'C' Letter Key -- (This runs the Configure Routine.  I sometimes do this twice, just to be sure it configured properly. I've had it miss a few times for unknown reasons.)
Press the 'G' Letter Key -- This 'Generates' Cmake files.

After the 'G' command, the system takes you back to the command prompt.

{arch@homedir}$ make ***WAIT A WHILE, COULD TAKE A BIT LONGER ON SLOWER SYSTEMS!***
{arch@homedir}$ sudo make install  (Or 'su -' to root, then do 'make install'; your preference.  I prefer using sudo.)
{arch@homedir}$ sudo ldconfig  (Or 'ldconfig' if still at root prompt #)
{arch@homedir}$ kvirc (or 'kvirc &' if you don't want the terminal window to hold onto the process.)


Kvirc should run at this point, but I ran into a couple of problems.  Once during the ccmake configuration (which prevented ccmake from configuring), and at the end, which prevented kvirc from running.)

The first had to do with two (2) packages that were not installed.  The were, as follows:

qt5-webkit
qt5-multimedia

I installed those files, then did the  'ccmake ..' portion.   That ran fine, as well as the 'make' and 'sudo make install' and 'sudo ldconfig' parts.

What didn't work was when I tried to run kvirc.  I got the following error:

{arch@homedirc}$ kvirc
kvirc: error while loading shared libraries: libkvilib.so.4: cannot open shared object file: No such file or directory

I remember, back when kvirc was wanting Qt4, and not Qt5, that if I didn't do the first 'sudo ldconfig' command before trying to run kvirc, it would give something similar.  However, since this compile run was wanting Qt5, and not qt4, I was puzzled.

Well, it turned out to be something quite simple.  This is a non-standard process of software installation on a new(er) arch system.  The 'uname -r' command on my system yields the following:  3.15.4-1-ARCH .  It is no surprise, then, that at this late date, Qt5 is complete (or at least more complete) than back in 2013 when I had the original problems, and had to select the 'WANTS-QT4' section during the 'ccmake ..' command.

**** Building kvirc this way places the kvirc binary in /usr/local/bin, and a certain 'libkvilib.so.4' library in /usr/local/lib ****.

This is to be expected from a standard source compile on most gnu/linux systems; and this *is* a standard compile, even though we're using the 'ccmake ..' command to do the preliminary configuration and cmakefile generation.)

The problem is, is that Arch is looking for libkvilib.so.4 in /usr/lib, and not /usr/local/lib.  So the following was, for me, the solution that got everything squared away:

I made a symlink in /usr/lib to /usr/local/lib/libkvilib.so.4, like this:

{arch@homedir}$ cd /usr/lib
{arch@homedir}$ sudo ln -s /usr/local/lib/libkvilib.so.4 libkvilib.so.4

After doing this, I did:

{arch@homedir}$ kvirc (or kvirc &)

And It Ran Beautifully! :-)

--

I hope you've enjoyed this HOWTO.  I know most people may just want to use the 4.2.x version of kvirc, currently residing safely in the standard repositories.  However, if you're like me, and want a bit of bleeding edge, Qt5 goodness with kvirc, I might suggest doing the above!

I can be reached at firefishe At gmail DOT com if anyone has any questions.

Last edited by Firefishe (2014-07-11 09:23:20)

Offline

Board footer

Powered by FluxBB