I am running Linux Mint 19.3 and the current version of libhamlib-utils 3.1.7build1 does not hold the radios that I wish to use so I installed version 3.3 from the Hamlib github. In order to do this I was required to uninstall CQRLOG when I uninstalled the old Hamlib.
The install of libhamlib-utils 3.3-10build1 went smoothly and all tested out OK so I went to install CQRLOG again and ran into the issue that it wants to install the old version of rigctld and does not seem to be aware of the new version. Does anyone have any advice on how I should proceed here.
73, Graeme ZL2APV
Hi Graeme!
This is again one problem that installing from packages can cause.
I think you should find hamlib version 4. At least Fedora 30 and up offers that for install. Hamlib 4 has lot of new radios and bug fixes and new properties for previously supported radios.
Install Hamlib first, then install latest cqrlog.
I do not know how apt-get, or the GUI Synaptic, must be commanded but there should be a option to ignore dependencies.
That is what should prevent HamLib change.
Consult Google search, I'm sure there is lot of information how to prevent unwanted changes when installing programs.
Once you have got new hamlib with cqrlog installed you should concider to update cqrlog as the official package version is rather old and many fixes have been done after that release.
Check this message from halfway down (the upgrade part) https://cqrlog.com/node/2464
Of course you can also always download and compile official source from https://github.com/ok2cqr/cqrlog
--
Saku
OH1KH
Thank you Saku,
I did have the latest version of CQRLOG installed and removed it when experimenting to get the version of Hamlib that I wanted installed. I thought that I would just use the package install to put it back as there will be a version upgrade for Linux Mint next month and I was going to do a tidy install then. I will take your advice and install the latest version and see if I can prevent it from installing the rigctld dependency using apt.
mni tnx 73 Graeme zl2apv
Hi,
Is there a simple way of updating the hamlib?
I am completely newbie when it comes to compiling from source.
Tried to do so now, but I have no idea what I am doing.
The INSTALL instructions are just black magic to me. Only managed to follow instructions in README file.
Thnx
Thomas SP9TL (ex. SQ9LBE)
https://www.qrz.com/db/SP9TL
Hi!
If linux distribution does not offer up to date package of Hamlib updating must be done by source compile. If this have never done before it is like black magic, I admit that: How ever let me explain how it happens.
The first to do is to get the source. In this case it can be cloned from GitHub using program called "git". Quite many linux versions have this installed, but in case it is not the first thing is to install it. Either with packet manager like synaptic or using command console (I prefer that).
To test existence type:
git
To install from package:
apt-get install git (Ubuntu derivatives)
dnf install git (RedHat derivatives)
Then clone the source code from GitHub:
git clone https://github.com/Hamlib/Hamlib.git
This will create new subdirectory called "hamlib". change to that directory with:
cd hamlib
There is a text file called INSTALL. Open that for reading the instructions and follow them. I go through the main parts of the job, more precise procedure is found from INSTALL file.
By default configure prepares hamlib to be in /usr/local/bin You can change this with --prefix parameter when running ./configure. If you use
./configre --prefix=/usr
files (rigctld, rotctld etc) will install in /usr/bin.
If you have old hamlib installed from package you can clear out the path with command:
whereis -b rigctld
Then you can decide if you use same path for compiled hamlib (roll over the package) or different path (have two different hamlibs).
Following INSTALL the first thing is to give command (with needed --prefix parameter if you decided so):
./configure
If that fails in very beginning, I.E it says something about missing Makefile or configuration then issue command:
./bootstrap
It will prepare the configuration (this is one time job). Then issue again command:
./configure
and it should go on checking various things. If configure fails the error message tells what is missing. Using that information as package name the missing package should be installed. Either with packet manager or console command. After package has been found and installed run again:
./configure
So many times it runs to the end and stops without errors. This is the hardest part of compile job, but it happens only one time when your linux does not yet have all needed programs for compile job.
When configure has passed the rest is just waiting... Next command is:
make
This will do the compile and lot of text appears to console while compile progress. If you have multi core CPU you can speed up this process by giving the number of cores for make. With 4 core CPU you can use command:
make -j 4
When make finishes it is time to install new hamlib with command:
sudo make install
If you decided to use different path than old hamlib you should now change that path to new hamlib to your cqrlog prefreneces/trxcontrol/path to rigctld
If you want ro remove your new hamlib the command is:
sudo make uninstall
When ever you notice there is something new in hamlib you just change to that cloned hamlib directory again get latest updates to source compile and install again:
cd hamlib
git pull
make
sudo make install
One workaround that may help:
If you have installed WSJT-X you may have another rigctld that is newer version than your existing one. Try these console commands:
rigctld --version
and then:
rigctld-wsjtx --version
if rigctld-wsjtx gives higher version number you can use it with cqrlog. Just give command
whereis -b rigctld-wsjtx
to get the full path and place it to cqrlog prefreneces/trxcontrol/path to rigctld
You can also check the latest version of wsjt-x from https://physics.princeton.edu/pulsar/k1jt/wsjtx.html There are installation packages for linux that you can download and try to install. It always brings the latest hamlib with it.
--
Saku
OH1KH
thank you. I will have a look at those commands again.
as for the cqrlog I have v.2.5.2 and wsjtx the latest too 2.4.0. So it seems that the hamlib has not been automatically updated even with wsjtx.
when running the rigctld commands, it gives me errors:
"rigctld: error while loading shared libraries: libhamlib.so.4: cannot open shared object file: No such file or directory"
I also have flrig, which works good with FT891. Just installed it, and it had FT891 in the rig list.
Thomas SP9TL (ex. SQ9LBE)
https://www.qrz.com/db/SP9TL
straight from the beginning I had errors with ./configure, it won't work. Managed to solve that issue.
but after running "make" I get:
testlibusb.c:30:10: fatal error: libusb-1.0/libusb.h: No such file or directory
#include
^~~~~~~~~~~~~~~~~~~~~
compilation terminated.
Makefile:1488: recipe for target 'testlibusb-testlibusb.o' failed
make[1]: *** [testlibusb-testlibusb.o] Error 1
One thing I've noticed, I have two rigctld files, one is in:
usr/local/bin (created yesterday, I guess after installing wsjtx, with a size of 818kb)
and another one in:
usr/bin (created in 2017, probably when first installed cqrlog, 97kb in size - this is the one cqrlog uses by default)
Changed the path to usr/local/bin, but no rig list appears.
Thomas SP9TL (ex. SQ9LBE)
https://www.qrz.com/db/SP9TL
partially solved it by installing
sudo apt-get install libusb-1.0-0-dev
but then again yet another error...
testlibusb.c: In function ‘print_device’:
testlibusb.c:185:7: error: ‘LIBUSB_SPEED_SUPER_PLUS’ undeclared (first use in this function); did you mean ‘LIBUSB_SPEED_SUPER’?
case LIBUSB_SPEED_SUPER_PLUS: speed = "10G"; break;
^~~~~~~~~~~~~~~~~~~~~~~
LIBUSB_SPEED_SUPER
testlibusb.c:185:7: note: each undeclared identifier is reported only once for each function it appears in
testlibusb.c: At top level:
testlibusb.c:272:2: warning: #warning LIBUSB-1.0.23 will be required in Hamlib > 4.3 [-Wcpp]
#warning LIBUSB-1.0.23 will be required in Hamlib > 4.3
^~~~~~~
Makefile:1488: recipe for target 'testlibusb-testlibusb.o' failed
make[1]: *** [testlibusb-testlibusb.o] Error 1
make[1]: *** Waiting for unfinished jobs....
I think I will just leave this case...this is too much for me :)
why can't they make a deb file for simple installation?
Thomas SP9TL (ex. SQ9LBE)
https://www.qrz.com/db/SP9TL
HI!
Sorry.!
Forgot to mention that if configure requires something to install they must be "dev" (or "devel") packages as the source code of those are usually needed.
As the compile warning says "#warning LIBUSB-1.0.23 will be required in Hamlib " and you have installed " libusb-1.0-0-dev". It should be 1.0.23 at least.
That raises a question: How old (and what) linux version you have? Have you installed all updates and perhaps done all upgrades that are available for your linux?
"rigctld: error while loading shared libraries: libhamlib.so.4:" this means that you have two different versions of hamlib in your system. Did you managed to compile and install it somehow? Then look what INSTALL file says about "ldconfig" (chapter 5).
If you have not managed to compile and install then this conflict may have started when you installed wsjt-x 2.4.0 and had older hamlib already.
Did you find "rigctld-wsjtx" and tried to use it instead of "rigctld" in cqrlog prefrences/trxcontrol/path to rigctld ?
"why can't they make a deb file for simple installation?"
Unfortunately package managers are too lazy or busy to make new packages and that causes lot of troubles.
If you have rig number #4 "Flrig Flrig" in cqrlog's rig list you can select it and check "run rigctld at program start" and keep all other settings as defaults.
Then start Flrig before cqrlog and cqrlog should use flrig as "rig". See: https://youtu.be/iDlwPYs53Dw
But if your hamlib (rigctld) is too old it may not have rig #4 "Flrig flrig"
--
Saku
OH1KH
I use Mint 19.3.
The libusb I tried to install like mentioned here, where it says 1.0.23 build too ... and the latest I have, or I can install is 1.0.21-2
https://ubuntu.pkgs.org/20.04/ubuntu-main-arm64/libusb-1.0-0-dev_1.0.23-...
"Did you find "rigctld-wsjtx" and tried to use it instead of "rigctld" in cqrlog prefrences/trxcontrol/path to rigctld ?" - I think it may be the one in usr/local/bin , but it is not working, no rig list displays after I change path in cqrlog.
but when I do whereis -b rigctld-wsjtx, no result comes out.
I do not have #4 "Flrig flrig" in the rig list, so this is why I am trying to update the hamlib but without any luck.
Thomas SP9TL (ex. SQ9LBE)
https://www.qrz.com/db/SP9TL
OK!
Mint 19.3 is a bit old.
I have Mint 20 installed on virtual machine and just checked rigtcld --version and it says "Hamlib 3.3". That version says it has rig: "4 FLRig" so your Hamlib must be really old version!
I recommend to upgrade your Mint to version 20. I know that it usually means troubles as there is always something that stops working after upgrade. But if you keep old Mint you will have more and more troubles later if you try to run latest versions of programs with old OS.
--
Saku
OH1KH
Thnx for the help so far.
Last night I've decided to upgrade to Mint 20, then to 20.2, but it all messed up some app, like MySQL wont work/install ... to many errors and so on.
So I've made a fresh install of 20.2 from a scratch.
Spent all day today messing around with my partitions to get them right (did some modifications to them) and installed most of my apps, including CQRLOG with its latest version and with the right hamlib :)
CQRLog has FT891, so no need to run flrig anymore :)
All that hassle with new installation of OS was worth it :)
Mind you, I do prefer making a fresh install of Linux than Windows :)
Thomas SP9TL (ex. SQ9LBE)
https://www.qrz.com/db/SP9TL
Nice to hear that you have now running new Mint!
As I said upgrading usually means some troubles but the work is worth of it for future. I had to say that I am quite happy with Fedora upgrade process. I have run several upgrades now and all are succeeded with minimal work.
Only bad thing with Fedora is that there is no LTS version and developing is fast. One must upgrade Fedora version every year to keep it supported.
I worked 15 years as IT local support with Windows workstation versions 3.1 to 7 and servers NT to 2000 and I was happy to leave them all behind when retired :-) Now only Linuxes to play with.
--
Saku
OH1KH