Lack of sufficent Pi documentation about hamlib HOT 62 CLOSED

from hamlib.

It is no problem to compile hamlib on a pi, I have done so.

I believe one of the images I was using had hamlib on it and it compiles just fine. What I'm after is GPIO support which (if i read the issues right) was 'solved' by adding in a flag that specifically adds the gpio support on the pi (it won't work on a desktop or laptop), however I can find no mention of how to use those flags to configure hamlib specifically for the pi or to really use the gpio pins to control ptt (I think one thread that I chimed in on said use rigctld with some options.

I have very little experience with hamlib as 90% of my radios do not support the functions or its not needed (ptt is handled through the mic connector), I would love to get this working so I can go to the rest of the hams in my community and show them 'hey this is possible without buying more stuff!' and to use the setup they already have to run wspr modes.

from hamlib.

from hamlib.

from hamlib.

Ok, so here is the command I use:
sudo rigctld -P GPIO -p 12
it doesn't return to the command prompt (I'm assuming it doesn't fork off into its own process)

I go into WSJT-X and configure the radio tab with hamlib NET rigctl as the rig, network server is: localhost:4532
set ptt method to CAT
transmit audio source as front/mic, mode and split are set to none.

I hit test cat, test ptt becomes enabled, hit test ptt and my indicator light does not light up that its keyed.

I go into fldigi -> configure -> rig control -> GPIO and double check what I have:

I have BCM 12 selected (GPIO pin 26, pin 32). Now I've tried all 3 of these, and I double checked and the version that I have on here is 3.3 (which i believe is current)

So, any ideas? I'm pretty close to getting this working with WSJT-X and if I can a LOT of people would be super happy!

73
Art

from hamlib.

also, i just ran it in verbose and it shows that its taking the commands from WSJT-X, what should I be looking for in terms of ptt-key/ptt-unkey? right now it shows rig_get_ptt called and dummy_get_ptt called

from hamlib.

from hamlib.

You didn't pick a radio model or device to connect to with the -m and -r switches so you got the dummy devicee.g. to find the model# for a 7300:rigctl -l | grep 7300 373 Icom IC-7300 0.24.5 Stable You can run rigctl first to ensure you are talking to the rigUsing the model# you getrigctl -m 373 -P GPIO -p 12 -r /dev/ttyUSB0You should be able to run f to get frequency, m to get mode/bandwidth, and "T 1" "T 0" to toggle PTT. I'm not sure of the mapping on the pin# though. From a bit of prior experience I think if you have PTT on pin 12 that would be GPIO pin 1rigctl -m 373 -P GPIO -p 1 -r /dev/ttyUSB0

but i'm not really interested in controlling a rig, I don't care about getting the frequency either. All I'm after is getting the GPIO to trigger.

from hamlib.

from hamlib.

from hamlib.

Ok, to re-iterate my reasons in doing ptt with GPIO:

• not everyone has a rig that can talk to a computer
• not everyone wants to use the same rig day after day, or in the same location
• ptt with the GPIO means that your rig interface is now UNIVERSAL among all of your radios!

So, 99% of my radios cannot be controlled by a computer period, this makes a majority of hamlib useless to me, however I can still connect them to my pi with the proper cables for audio and ptt (nw digital radio's DRAWS/UDRC boards and the Nexus board from WB7FHC for example). With a cable swap I can use ANY of my rigs for digital. I do not have to change the settings in fldigi either! This is what I'm trying to accomplish with hamlib and WSJT-X. Getting this to work will mean a lot of hams with similar setups will be able to use WSJT-X software (or any software that can use hamlib) on any radios (including really old ones!).

from hamlib.

from hamlib.

from hamlib.

So did you get the GPIO to work? Mike

yes and no.... the program didn't error out on me when I went to test the ptt, and the rigctrld program didn't exit with an error so its trying to do something.... however it didn't actually key anything that I can tell.

I am testing this on a NEXUS hat (http://wb7fhc.com/nexus-dr-x.html) which has indicator lights for which rig is keying (left rig or right rig). neither light actually lights when I test it in the WSJT-X program. However when testing with FLDIGI (see pic above for settings) it lights up no problem. I've tried all 3 pin designations (actual pin number, the BCM number, and the GPIO number) and none of them trigger.

I'm hoping someone who actually worked on that particular portion of the code can tell me how they designed it, or if there's a way to test it (i'll do some digging on my own but i'm getting ready for Winter Field Day) without using WSJT-X. Or if I have to pass a rig to the program to get the key to work (maybe a bug?).

from hamlib.

here is a log that i created with -vvvv:

rigctld, Hamlib 3.3
Report bugs to <[email protected]>
rig_init called
dummy: _init called
rig_register called
rig_register: rig_register (1)
rig_register called
rig_register: rig_register (2)
rig_register called
rig_register: rig_register (4)
rig_register called
rig_register: rig_register (5)
dummy_init called
rig_strvfo called
rig_passband_normal called
rig_strvfo called
rig_passband_normal called
rig_open called
port_open called
dummy_open called
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
rig_strstatus called
Backend version: 0.5, Status: Beta
rig_close called
dummy_close called
port_close called
Connection opened from localhost:46634
client lock engaged
rig_open called
port_open called
dummy_open called
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
client lock disengaged
client lock engaged
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_mode called
rig_strvfo called
dummy_get_mode called: currVFO
rig_strrmode called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_freq called
rig_strvfo called
dummy_get_freq called: currVFO
client lock disengaged
client lock engaged
rig_strvfo called
rig_set_freq called
sprintf_freq called
rig_strvfo called
dummy_set_freq called: currVFO 145 MHz
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_freq called
rig_strvfo called
dummy_get_freq called: currVFO
client lock disengaged
client lock engaged
rig_strvfo called
rig_set_freq called
sprintf_freq called
rig_strvfo called
dummy_set_freq called: currVFO 145 MHz
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_split_vfo called
dummy_get_split_vfo called
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_freq called
rig_strvfo called
dummy_get_freq called: currVFO
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_mode called
rig_strvfo called
dummy_get_mode called: currVFO
rig_strrmode called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_ptt called
dummy_get_ptt called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_split_vfo called
dummy_get_split_vfo called
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_freq called
rig_strvfo called
dummy_get_freq called: currVFO
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_mode called
rig_strvfo called
dummy_get_mode called: currVFO
rig_strrmode called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_ptt called
dummy_get_ptt called
client lock disengaged
client lock engaged
rig_strvfo called
rig_set_ptt called
dummy_set_ptt called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_split_vfo called
dummy_get_split_vfo called
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_freq called
rig_strvfo called
dummy_get_freq called: currVFO
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_mode called
rig_strvfo called
dummy_get_mode called: currVFO
rig_strrmode called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_ptt called
dummy_get_ptt called
client lock disengaged
client lock engaged
rig_strvfo called
rig_set_ptt called
dummy_set_ptt called
client lock disengaged
client lock engaged
rig_strvfo called
rig_set_freq called
sprintf_freq called
rig_strvfo called
dummy_set_freq called: currVFO 145 MHz
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_split_vfo called
dummy_get_split_vfo called
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_freq called
rig_strvfo called
dummy_get_freq called: currVFO
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_mode called
rig_strvfo called
dummy_get_mode called: currVFO
rig_strrmode called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_ptt called
dummy_get_ptt called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_split_vfo called
dummy_get_split_vfo called
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_freq called
rig_strvfo called
dummy_get_freq called: currVFO
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_mode called
rig_strvfo called
dummy_get_mode called: currVFO
rig_strrmode called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_ptt called
dummy_get_ptt called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_split_vfo called
dummy_get_split_vfo called
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_freq called
rig_strvfo called
dummy_get_freq called: currVFO
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_mode called
rig_strvfo called
dummy_get_mode called: currVFO
rig_strrmode called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_ptt called
dummy_get_ptt called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_split_vfo called
dummy_get_split_vfo called
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_freq called
rig_strvfo called
dummy_get_freq called: currVFO
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_mode called
rig_strvfo called
dummy_get_mode called: currVFO
rig_strrmode called
client lock disengaged
client lock engaged
rig_strvfo called
rig_get_ptt called
dummy_get_ptt called
client lock disengaged
select
client lock engaged
1 outstanding client(s)
rig_close called
dummy_close called
port_close called
client lock disengaged
rig_cleanup called
dummy_cleanup called
Opened rig model 1, 'Dummy'
Closed rig model 1, 'Dummy - will reopen for clients'
Opened rig model 1, 'Dummy'

I ran rigctrld as above, went over to WSJT-X, hit 'test cat' then 'test ptt' then exited rigctrld

from hamlib.

from hamlib.

here's with 5 -v:
rigctld, Hamlib 3.3
Report bugs to [email protected]

rig_init called
dummy: _init called
rig_register called
rig_register: rig_register (1)
rig_register called
rig_register: rig_register (2)
rig_register called
rig_register: rig_register (4)
rig_register called
rig_register: rig_register (5)
dummy_init called
rig_strvfo called
rig_passband_normal called
rig_strvfo called
rig_passband_normal called
rig_open called
port_open called
dummy_open called
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
rig_strstatus called
Backend version: 0.5, Status: Beta
rig_close called
dummy_close called
port_close called
Connection opened from localhost:46654
client lock engaged
rig_open called
port_open called
dummy_open called
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): ð 'currVFO' '' '' ''
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): � 'currVFO' '' '' ''
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): v 'currVFO' '' '' ''
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): v 'currVFO' '' '' ''
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): v 'currVFO' '' '' ''
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): m 'currVFO' '' '' ''
rig_get_mode called
rig_strvfo called
dummy_get_mode called: currVFO
rig_strrmode called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): f 'currVFO' '' '' ''
rig_get_freq called
rig_strvfo called
dummy_get_freq called: currVFO
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): F 'currVFO' '145000055.000000' '' ''
rig_set_freq called
sprintf_freq called
rig_strvfo called
dummy_set_freq called: currVFO 145 MHz
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): f 'currVFO' '' '' ''
rig_get_freq called
rig_strvfo called
dummy_get_freq called: currVFO
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): F 'currVFO' '145000000.000000' '' ''
rig_set_freq called
sprintf_freq called
rig_strvfo called
dummy_set_freq called: currVFO 145 MHz
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): v 'currVFO' '' '' ''
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): s 'currVFO' '' '' ''
rig_get_split_vfo called
dummy_get_split_vfo called
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): f 'currVFO' '' '' ''
rig_get_freq called
rig_strvfo called
dummy_get_freq called: currVFO
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): m 'currVFO' '' '' ''
rig_get_mode called
rig_strvfo called
dummy_get_mode called: currVFO
rig_strrmode called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): t 'currVFO' '' '' ''
rig_get_ptt called
dummy_get_ptt called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): v 'currVFO' '' '' ''
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): s 'currVFO' '' '' ''
rig_get_split_vfo called
dummy_get_split_vfo called
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): f 'currVFO' '' '' ''
rig_get_freq called
rig_strvfo called
dummy_get_freq called: currVFO
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): m 'currVFO' '' '' ''
rig_get_mode called
rig_strvfo called
dummy_get_mode called: currVFO
rig_strrmode called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): t 'currVFO' '' '' ''
rig_get_ptt called
dummy_get_ptt called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): T 'currVFO' '1' '' ''
rig_set_ptt called
dummy_set_ptt called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): v 'currVFO' '' '' ''
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): s 'currVFO' '' '' ''
rig_get_split_vfo called
dummy_get_split_vfo called
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): f 'currVFO' '' '' ''
rig_get_freq called
rig_strvfo called
dummy_get_freq called: currVFO
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): m 'currVFO' '' '' ''
rig_get_mode called
rig_strvfo called
dummy_get_mode called: currVFO
rig_strrmode called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): t 'currVFO' '' '' ''
rig_get_ptt called
dummy_get_ptt called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): T 'currVFO' '0' '' ''
rig_set_ptt called
dummy_set_ptt called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): F 'currVFO' '145000000.000000' '' ''
rig_set_freq called
sprintf_freq called
rig_strvfo called
dummy_set_freq called: currVFO 145 MHz
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): v 'currVFO' '' '' ''
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): s 'currVFO' '' '' ''
rig_get_split_vfo called
dummy_get_split_vfo called
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): f 'currVFO' '' '' ''
rig_get_freq called
rig_strvfo called
dummy_get_freq called: currVFO
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): m 'currVFO' '' '' ''
rig_get_mode called
rig_strvfo called
dummy_get_mode called: currVFO
rig_strrmode called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): t 'currVFO' '' '' ''
rig_get_ptt called
dummy_get_ptt called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): v 'currVFO' '' '' ''
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): s 'currVFO' '' '' ''
rig_get_split_vfo called
dummy_get_split_vfo called
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): f 'currVFO' '' '' ''
rig_get_freq called
rig_strvfo called
dummy_get_freq called: currVFO
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): m 'currVFO' '' '' ''
rig_get_mode called
rig_strvfo called
dummy_get_mode called: currVFO
rig_strrmode called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): t 'currVFO' '' '' ''
rig_get_ptt called
dummy_get_ptt called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): v 'currVFO' '' '' ''
rig_get_vfo called
rig_strvfo called
dummy_get_vfo called: VFOA
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): s 'currVFO' '' '' ''
rig_get_split_vfo called
dummy_get_split_vfo called
rig_strvfo called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): f 'currVFO' '' '' ''
rig_get_freq called
rig_strvfo called
dummy_get_freq called: currVFO
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): m 'currVFO' '' '' ''
rig_get_mode called
rig_strvfo called
dummy_get_mode called: currVFO
rig_strrmode called
client lock disengaged
client lock engaged
rig_strvfo called
rigctl(d): t 'currVFO' '' '' ''
rig_get_ptt called
dummy_get_ptt called
client lock disengaged
select
client lock engaged
1 outstanding client(s)
rig_close called
dummy_close called
port_close called
client lock disengaged
rig_cleanup called
dummy_cleanup called
Opened rig model 1, 'Dummy'
Closed rig model 1, 'Dummy - will reopen for clients'
Opened rig model 1, 'Dummy'

from hamlib.

from hamlib.

Now let's try this with rigctl as Bill recommended. And please show your command line every time...... Once you run rigctl to the "T 1" "T 0" and the GPIO pin should toggle if you have the right one selected. I've got a Pi in the closet I could probably yank out and test this myself. MIke

The bands went dead so I'm back to tinkering with this... the command i ran was:
sudo rigctld -P GPIO -p 12 -m 1 -vvvvv
for the first tests
This last time I tried rigctl with the following:
sudo rigctl -P GPIO -p 12 -m 1 -vvvvv
then it prompted for a command, typed 'T 1' and sure enough the light on my Nexus board lit up!

so setting it manually works, however rigctld either doesn't pass the correct argument or its WSJT-X's fault in not calling the right argument.

any ideas would be helpful... we are so close to getting a universal setting that will work with all radios and not just computer controlled ones!

from hamlib.

from hamlib.

Try my fork now...rigctld didn't know about GPIO https://github.com/mdblack98/Hamlib.git de Mike W9MDB

I finally have a bit of time, I tried to build the other library but i got this:

[bunch of other stuff up here]
checking for alloca... yes
./configure: line 7701: syntax error near unexpected token `2.2.6b'
./configure: line 7701: `LT_PREREQ(2.2.6b)'

now it did fail on the bootstrap config:

rotators/ts7400/Makefile.am:2: error: Libtool library used but 'LIBTOOL' is undefined
rotators/ts7400/Makefile.am:2:   The usual way to define 'LIBTOOL' is to add 'LT_INIT'
rotators/ts7400/Makefile.am:2:   to 'configure.ac' and run 'aclocal' and 'autoconf' again.
rotators/ts7400/Makefile.am:2:   If 'LT_INIT' is in 'configure.ac', make sure
rotators/ts7400/Makefile.am:2:   its definition is in aclocal's search path.
src/Makefile.am:10: error: Libtool library used but 'LIBTOOL' is undefined
src/Makefile.am:10:   The usual way to define 'LIBTOOL' is to add 'LT_INIT'
src/Makefile.am:10:   to 'configure.ac' and run 'aclocal' and 'autoconf' again.
src/Makefile.am:10:   If 'LT_INIT' is in 'configure.ac', make sure
src/Makefile.am:10:   its definition is in aclocal's search path.
autoreconf: automake failed with exit status: 1

according to apt I do have libtool... version 2.4.6-9 but I have no idea why it isn't picking it up.
btw, a little bit of background on me: I did go to school to be a developer, however now I'm a machine operator (training to be a machinest), I do code in my spare time however I was never really any good at the autoconfigure stuff to link multiple libraries across multiple platforms.

so, any chance someone can give me a step by step on how to fix this?
my release info:

Distributor ID:	Raspbian
Description:	Raspbian GNU/Linux 10 (buster)
Release:	10
Codename:	buster

and the kernal version:

Linux KC7SDA-hampi 4.19.75-v7+ #1270 SMP Tue Sep 24 18:45:11 BST 2019 armv7l GNU/Linux

please note this is an image from the local ham group I downloaded for one of their digital projects and I have no idea just how heavy they modified the kernel or everything they installed (I use very little as I just do fldigi right now)

link to their image if you want to see the project and what all they have done:
https://github.com/AG7GN/images

from hamlib.

from hamlib.

What does "which libtool" say? And presumably "/usr/bin/libtool --version" ? de Mike W9MDB

so funny thing i get nothing with the which command and the only reference for libtool i can find is in /usr/share/libtool which is a directory and it looks like its the gnu libltdl (system independent dlopen wraper for libtool).

so right now i have no idea where to go... talking with the guy that's come up with the image i'm using (hampi), he's using the stock raspbian buster with no kernel tweaks... he's just installed a bunch of stuff and setup menus and runs a script at startup... he also reports the same error on his end, but the official hamlib 3.3 builds fine.

have the edits from the fork made it into the official package yet? any idea when that might be?

from hamlib.

from hamlib.

What does 'apt policy libtool' report?

same as yours

new update: the guy that developed the hampi image for our club says that there are missing libtool related .m4 files from the fork. what else aside from 'build-essential' is needed?

from hamlib.

from hamlib.

from hamlib.

from hamlib.

hamlib only includes the macros it uses plus the macros that are referenced by those macros....not all m4 macros.

so if you pull the official repository it has a lot more .m4 files than your fork

Compile and install libtool yourself and see if that fixes the problem.

https://www.gnu.org/software/libtool/

de Mike W9MDB

to be honest I really shouldn't have to compile and install libtool... I really need a much simpler 'download this, do a few things, you can now get on wsjt-x with no additional interface!' type solution.

is there any chance of getting hamlib patched before the official release? or could I just copy and paste all the files from the fork into the hamlib repository directory and try compiling that?

from hamlib.

from hamlib.

from hamlib.

from hamlib.

well that really does suck... I'm bootstrapping libtool now and will see if it it works.

I really really hope the gpio issue gets fixed on the next release.

from hamlib.

ok... so i got libtool installed:

pi@KC7SDA-hampi:~/Hamlib $ which libtool
/usr/local/bin/libtool
pi@KC7SDA-hampi:~/Hamlib $ /usr/local/bin/libtool --version
libtool (GNU libtool) 2.4.6.44-b9b4
Written by Gordon Matzigkeit, 1996

Copyright (C) 2014 Free Software Foundation, Inc.

however its still giving me errors that it can't find libtool. I've changed line 268 to point to libtool... but still getting the same error as before.

line 268 now looks like this:

LT_INIT("/usr/local/bin/libtool")

should i be pointing it at the build directory instead? is there another directory it should look at?

and yes, i did run aclocal before bootstrapping it again.

Thanks for the help guys

from hamlib.

[snip]

I agree. Did you compare the files on your system to those in the Debian link I sent last night?

I'm compairing them now, i might be missing a few (not sure how important they are):
/usr/share/aclocal/lt~obsolete.m4 - missing
not checking the docs, but everything else seems to be there

As Mike stated, working from a Git tree can be troublesome as sometimes you need to use 'git clean -dxf' to remove any and all generated files in the working tree and completely delete everything under the build directory (if you're using a VPATH) build. The simplest method is to use the daily snapshots as they're already set up so that libtool or any of the other GNU Autotools are not required to be installed on your system. However, if you're testing from Mike's tree this won't help. Better then just to do a clean 'git clone' and working from there. 73, Nate

I cleaned the directory, i'll try a clone here in a minute. I might for S&G grab the offical one and see if i can get that one to compile. if i do a git clone on the main hamlib is that the daily snapshot?

Thanks 73
Art

from hamlib.

fyi i just pulled the hamlib main branch into a directory and tried to bootstrap it... got the same error with libtool...

I've just about hit the edge of my knowledge in development on this... I have no idea what autoconfig is looking for as far as the library goes, i can keep keyboard bashing and see if i get something at some point but i'd rather not waste time and just try to find something that works.

also, I noticed something with the main branch: it will configure ar-lib, compile, config.guess .... it however fails on the amplifiers make file, bindings make file, c++ and so on... I'll look into some of those and see if i can figure out what it's looking for. I'll see if i can point to a few other directories and see if i get any further...

73
Art

ps it looks like parallel-tests worked successfully (installed test-driver)

from hamlib.

from hamlib.

from hamlib.

Try my fork Not that it will fix things but if there's a change needed that's where we'll test it. I've got a bunch of patches that are almost ready to submit to the master right now. https://github.com/mdblack98/Hamlib.git de Mike W9MDB

So I've tried your fork mike and that got me the same thing as the main hamlib branch. I have found a few interesting things though:

• I ran aclocal --verbose and dumpped the output to a log file. I went through it and didn't like what I saw for the libtool lines that I found, I'm going to attempt to attach it to this post
• I dumped the output of the bootstrap to a log and I'm attaching that too.
  aclocal.log
  bootstrap.log

I'll go pull on that fork mike and i'll do the same thing with it as is and upload those logs as well

from hamlib.

Here are the 2 logs from Mike's fork (i did a pull about 5 minutes ago on it)
w9mdb-bootstrap.log
w9mdb-aclocal.log

from hamlib.

Also I went through the readme.release and developer files and double checked to see that I had everything installed and setup correctly on it.

from hamlib.

from hamlib.

i uninstalled it with
sudo apt-get remove libtool
and its still throwing off the errors like before.

also, silly question about git, but if i do
git pull
it should grab all the files its missing and 'update' correct? i tried deleting the config file to force it to pull a fresh one but it said 'up to date'.... am i missing a flag or something?

from hamlib.

from hamlib.

ok so now it fails with

pi@KC7SDA-hampi:~/Hamlib-mdblack98 $ ./bootstrap
Running 'autoreconf -i' to process configure.ac
and generate the configure script.
aclocal: error: couldn't open directory '/usr/share/aclocal': No such file or directory
autoreconf: aclocal failed with exit status: 1

when i try to run aclocal it says it can't find that directory.

also i'm not looking for new commits, i was looking more for 'hey a file is missing go grab it again'

thanks again guys for all your help so far, I think i'm making progress but its so frustrating when this isn't telling me where stuff is defined.

Art

from hamlib.

from hamlib.

well i looked into recompiling aclocal... and its a huge ass pain to do that....

i did a little investigation and found theres a aclocal-1.16 directory, so i created a symbolic link to that directory for aclocal... i got aclocal to work again, however libtool is still missing/not defined

from hamlib.

from hamlib.

so far i haven't deleted anything, i moved the orginal aclocal to aclocal.bkup =)

also, i'm guessing that in a few months or so I'll be redoing the image anyway with a new one they come out with thats clean(er). Also I'll have to try working up a solution to get to the rest of the club for those interested in doing wspr modes w/o the interface cable to the rig that doesn't require all the moving/compiling/etc. I hope to just compile a deb package that i can have the guy upload to the site and have a script download/install it (which would be the best option for my local group until the base hamlib gets updated to work with the gpio)
i'll go ahead and grab a fresh raspbian image and toss that on a card. hopefully that'll fix everything.
Art

from hamlib.

Art, sorry - I did not spot that this thread was on Github. I suggested that something must be broken on your Rasbian system. I did the following test:

From a clean install of the latest Raspbian Buster:

sudo apt install automake libtool
git clone https://github.com/Hamlib/Hamlib.git
cd Hamlib/
mkdir build
cd build/
../bootstrap
../configure
make

All ran successfully.

from hamlib.

Art, try installing the libtool-bin package. I was in a hurry the other day and did not notice the file list for the libtool package does not include the /usr/bin/libtool file. It is in the libtool-bin package instead. I'm not sure why I've never noticed this before. Sigh...

from hamlib.

Well, Art, I don't know what is going on with your system.

I set up a Raspbian Buster virtual machine and have installed autoconf, automake, and libtool, but not libtool-bin. I also installed git and cloned Mike's current master repository and built it in the usual way with no errors except for running out of space on the virtual disk image which I can't seem to enlarge. Oh well.

from hamlib.

Art, try installing the libtool-bin package. I was in a hurry the other day and did not notice the file list for the libtool package does not include the /usr/bin/libtool file. It is in the libtool-bin package instead. I'm not sure why I've never noticed this before. Sigh...

so I'm not sure how to get libtool-bin installed. I'm going to just see about doing this on another setup and exporting it somehow...

if I was able to compile everything and save the entire directory and gave it to someone with the same setup they should be able to run sudo make install on it without recompiling it correct? my thought is that if they already have hamlib installed then all supporting libraries are already installed.

thanks again for the help guys, i'm going to work on this more this coming weekend and see if i can figure it out... I might talk to the guy who made the hampi image and see if he has a 'setup script' that I can run on a blank raspbian image, and if i can get the image to compile hamlib then i'll do that and run his script and make a new main image for me.

from hamlib.

from hamlib.

so the main reason I haven't updated the packages is because the last rasbian update broke the audio driver we were using for the fe-pi, they apparently finally patched it and it should be loaded soon.

here's the link to the image we are using: https://github.com/AG7GN/images

i'll try running sudo ldconfig and see what that does, I'm sorry I haven't had a chance to work on this lately I got hit with a nasty bug that took me out of commission for 3 days and I'm finally getting caught up on everything.

73
Art

from hamlib.

What's the status of this?

from hamlib.

from hamlib.

What's the status of this?

well I'm going to try a few things hopefully this weekend:

• I'm going to try running that ldconfig and then try compiling the library again, if that doesn't work then....
• I'm going to download raspbian and try a 'fresh start' and see what happens
• I'll download the newest copy of the hampi image (update it) and try it if all else fails

If all of that fails then I am lost as to why this isn't working for me. At that point I'll give up and wait for the official release and wait for it to be incorporated into raspbian.

from hamlib.

so first test failed... sudo ldconfig apparently doesn't do anything (i did sudo ldconfig -v | grep libtool and it didn't show anything for libtool)

I have to shut down for now though, we just had 3 power flickers back to back (we have up to 60 mph gusts going on right now). I'll try again later when it calms down.

from hamlib.

I purchased a Pi 4 that arrived today. I downloaded AG7GN's hampi20191214 image, cloned Mike's current repository, and despite the Autotools being installed, at least libtool is broken. I did not update the system to mimic Art's environment as much as I could.

I've now tried it with stock Raspbian Buster and after installing autoconf, automake, and libtool, the bootstrap step runs as expected, the configure script is generated, configure runs as expected, and the build proceeds as expected. Do note that Raspbian updates the system as part of the initial setup so all packages are up-to-date, but I recall no issues with Debian Buster (upon which Raspbian is based) through the nine months that I ran it as "testing" before it became "stable" last summer. Since then the builds have just worked.

Somehow AG7GN's image is broken. Stock Raspbian is fine. Sorry, I'm of no further help.

from hamlib.

I purchased a Pi 4 that arrived today. I downloaded AG7GN's hampi20191214 image, cloned Mike's current repository, and despite the Autotools being installed, at least libtool is broken. I did not update the system to mimic Art's environment as much as I could.

I've now tried it with stock Raspbian Buster and after installing autoconf, automake, and libtool, the bootstrap step runs as expected, the configure script is generated, configure runs as expected, and the build proceeds as expected. Do note that Raspbian updates the system as part of the initial setup so all packages are up-to-date, but I recall no issues with Debian Buster (upon which Raspbian is based) through the nine months that I ran it as "testing" before it became "stable" last summer. Since then the builds have just worked.

Somehow AG7GN's image is broken. Stock Raspbian is fine. Sorry, I'm of no further help.

the reason we haven't updated is that the new kernal doesn't have the driver for the audio card we are using (ie its broken).

I might have a procedure but I haven't had time to test it yet. I'll keep everyone posted

from hamlib.

Ok, so update!

Raspbian released a new version that fixed the audio driver problem, I updated, grab a fresh version of hamlib, compiled, installed, ran ldconfig, ran rig control and bingo! wsjt-x keyed up!

so the problem is solved, here's the short solution:

• clone hamlib from github (this is as of version 4 from github)
• run through the bootstrap/config/make/install sequence
• RUN LDCONFIG!!!! I think this is because I had it installed from the repository before
• run sudo rigctld -P GPIO -p 12
• open wsjt-x and configure for hamlib!

Thanks everyone for trying to work through this with me! i'm glad this is finally done and is now working! maybe I'll try some ft8 this week and see how i do!
73
Art

from hamlib.