Rig control issue with 64 bit Ubuntu Lucid install

9 posts / 0 new
Last post
AE3E
Rig control issue with 64 bit Ubuntu Lucid install

I've just upgraded my computer and OS from Ubuntu 9.10 32 bit (where CQRLOG installed and ran fine) to Ubuntu 10.04 64 bit. After reading the forum here, I managed to get libhamlib2 32 bit version installed alongside the 64 bit version, and CQRLOG 0.9.4 now runs. But I still have a problem with it controlling my rig, an Elecraft K2. This worked great on the old machine, and I'd like to have the same capability. I see hints that I must now de-install the 64 bit version of hamlib to make it all work, but I'm reluctant to do that since FLDIGI on the same system works fine with the 64 bit versions and I'm fairly sure de-installing them will break that program's ability to control the rig. Has anyone come up with a clever work around, or, better yet, does someone have an already-compiled full 64 bit version available so I can dispense with the 32 bit library nonsense? Thanks,

Dan AE3E

ok2zar
ok2zar's picture
CQRLOG reads FRQ and MODE but doesn't control RIG

I've similar (or the same) problem. On Ubuntu 9.04 it worked very well. And now on Ubuntu 10.04 it works partially. CQRLOG can read FRQ and MODE, but can't control RIG (FT-857). I think, that problem is in actual version of HAMLIB in Ubuntu 10.04. I'll install CQRLOG on Debian Squeeze (or older Lenny) and try to control RIG by CQRLOG.

AE3E
Confirmed bug in picking up the 32-bit version of libhamlib2

I've confirmed that if I remove libhamlib2 (64-bit version) from the machine, then CQRLOG works just fine with the rig. Unfortunately, Fldigi depends on libhamlib2 (64-bit version), so I can have one (CQRLOG) or the other (FLDIGI) but not both work properly. Pretty clearly this is a bug in how CQRLOG references the libhamlib2 library - it mistakenly picks up the 64-bit version and not the 32 bit version when both are installed, but only at runtime, not during program initialization, when it requires the 32 bit version to be present. Does anyone have a workaround for this in the meantime (I'm thinking perhaps a means of invoking CQRLOG as a different user, perhaps, and make sure that user doesn't have permissions for the folders containing the 64-bit libhamlib2 - or something crazy like that! I'm not even sure if this would work...)

Thanks,

Dan AE3E

n3meq
n3meq's picture
CQRLOG and FLDIGI

Dan I have both installed here but only use 32bit hamlib I did compile FLDIGI source on this machine with 32bit hamlib headers. I hope this will help

Dave, N3MEQ

AE3E
Thanks for the tip. I

Thanks for the tip. I haven't compiled anything on a UNIX/LINUX machine in 20 years, but maybe I'll give it a try.

KB3TZK
ugly workaround

This is my first post here so first I'd like to thank the developers of cqrlog for their work. I've selected it as my logging software of choice. Now, on to business...

The proper solution to the problem reported here is to distribute cqrlog as a 64bit executable for 64bit systems.

The problem is that the 32bit hamlib in /usr/lib32/ is trying to load 64bit .so files from /usr/lib/. Here is an ugly workaround.

READ the documentation in the file FIRST.

Save the file on your system, set it to be executable (proper location and mode) and execute this script whenever you want to run cqrlog.

Some of you will certainly guess that in theory it would not be necessary to run this script over and over again. Once the modification is done, it is done, right? Yes but with some caveats. If you upgrade to the next Ubuntu from scratch (which I sometimes do), the modifications made by the script will be lost. If you run cqrlog on multiple machines (like I do), you might forget to apply the modifications everywhere, etc. Since I'm likely to forget such details, I've decided that the safest way for me to operate is to have this script in my ~/scripts directory and name it cqrlog so that whenever I run cqrlog, the script is run, checks whether the modifications are made and then launches cqrlog.

AE3E
Thanks so much...

Well, your ugly workaround works fine on my machine. It will serve until the real solution (as you pointed out, a 64 bit executable) is made available. I'm pretty sure I don't want to go through the pain of compiling CQRLOG myself (or FLDIGI), given that I haven't done such a thing in a LONG time.

Also thanks to the CQRLOG programmers, we are all in your debt.

do4nw
Nice little script, thank

Nice little script, thank you.

A year ago or so i also stumbled upon this issue and started a thread here.

I wrote a solution down in the german ubuntu wiki.

In Ubuntu 10.04, 9.10 and 9.04, this should work:

  1. Uninstall libhamlib2 if installed by opening a terminal and enter:
    sudo apt-get remove libhamlib2
  2. Install getlibs and download 32bit libraries for RIG control:
    wget -O /tmp/getlibs-all.deb http://frozenfox.freehostia.com/cappy/getlibs-all.deb
    sudo dpkg -i /tmp/getlibs-all.deb
    sudo getlibs -p libhamlib2

If you use other ham radio applications with rig control you need to compile libhamlib2 yourself:

  1. Install dependencies:
    sudo apt-get build-dep libhamlib2
  2. Download and install ham library
    mkdir ~/.libhamlib2-src && cd ~/.libhamlib2-src
    apt-get source libhamlib2
    cd hamlib*
    ./configure --prefix=/usr
    make
    sudo make install
G8FXM
G8FXM's picture
Rig control issue with Linux Mint 18.1 KDE 64 bit

I have just moved to Linux Mint 18.1 KDE 64 bit from Linux Mint 17 Cinnamon 32 bit and I'm having problems getting my FT2000D to talk to CQRLog using HAMLIB. I was wondering is the above 32 bit CQRLog issue still current, should I go ahead and replace my 64 bit libhamlib2 with the 32 bit version?

73'd De Dave, G8FXM O/S Linux Mint 18.1 KDE Plasma 64 bit  g8fxm@uksmg.org