[Hamlib-developer] Re: compile

[Stephane F. <f4...@fr...>]

[ this mail is Cc: to hamlib-developer ]

On Thu, Oct 25, 2001, Robert Steinhäußer wrote:
> Still some drivers segfault when a close() is done without a preceding
> open()... here RPC rig:

Be careful, rpcrig is rather shallow right now. There's only rig_set_freq
and reading caps is not implemented yet (you would get anything but 
expected values).

> #3  <signal handler called>
> #4  0x413ab2f1 in rpcrig_close (rig=0x8110810) at rpcrig_backend.c:170
> #5  0x4002b06c in rig_close (rig=0x8110810) at rig.c:497
> #6  0x4001b4b3 in Rig::close (this=0x812e308) at rigclass.cc:70
 
Maybe related to the double close issue? Or is it peculiar to some backends?
Could you try again with the new fix?

> Then I am trying to figure out which radio modes (AM, ...) are currently
> available. I suppose I will have to parse the freq_range_list array. But
> still one thing shouldn't happen: Select FT847, Kontakt finds out
> "everything except WFM is ok". Then select RTTY -> RigException. Every

   very simple, RIG_MODE_WFM is not declared in caps :*)
   Are you sure the FT847 supports WFM ? If so, it's just one commit away!
   However, rig_set_mode does not seems to implemented it. 
   Or maybe MODE_MAIN_FM is actually WFM, and MODE_MAIN_NFM FM ?
   Anyone has protocol specs handy? Frank?
   The filter section is missing too (bandpass at -6dB). Anyone has it?

> other mode works fine. OK, the RTTY button is hard-coded to "16" (not
> RIG_MODE_RTTY, as I would prefer it, I'm working on it).

RTTY is not supported (yet) by ft847_set_mode. BTW, is this mode 
available on the rig?

> rig:rig_close called
> ft847:ft847_close called
> TX 5 bytes
> 0000	 00 00 00 00 80	.....
> rig:rig_cleanup called
> rig:rig_close called
> ft847:ft847_close called
> write_block() failed - Ungültiger Dateideskriptor
> ft847:ft847_cleanup called
> 
>                        ^^^^^^^^^^^^^^^^^^^^^^^^^^ invalid file descriptor
> 
> Now rig_close (+ft847_close) is called twice, it seems.

good point! rig_close was missing a rig->state.comm_state update...
I've commited a fix, it should now be safe to call rig_close() twice.

73 Stephane