Re: [Hamlib-developer] Re: Hamlib and rotators

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

On Mon, Dec 31, 2001, Francois Retief wrote:
> The spec was invented by the author of WiSP. WiSP is a PacSat ground 
> station program (for Windows).   It includes rotator control, radio 
> dopler control and PacSat mailbox functions amongst others.  That is 
> why there is both radio and rotator stuff.

This is going to be troublesome for Hamlib, because the rotator frontend
has strictly no idea of operating frequency. Can we just pass null freq?

> > Some examples of the EASYCOMM II protocol would help also.
> > Maybe you are the right person to implement these backends, and test it
> > while you're at it.
> 
> I will check-out a fresh copy of the CVS and start hacking.  
> Should I create a new directory for rotor backends?

yep. The rule is to have the backend have the same name as the directory
it lives in. So if EASYCOMM I and EASYCOMM II are to be in the same
backend, maybe 'easycomm' could be a good candidate.
There's already a 'dummy' rotator backend, so rotctl has something to
chew.

> I have a problem with the current CVS code.  The test programs in the
> hamlib CVS works fine.  But when I try to link it to a test program 
> (external to hamlib), it complain about:
> /usr/local/lib/libhamlib.so: undefined reference to
> 'lt_preloaded_symbols'

I knew it would happen some day. This lt_preloaded_symbols is useful for
statically linked in hamlib backends. I try to find a seamless solution
that would work shared and static, with easy maintenance.
So let's disable it (comment out LTDL_SET_PRELOADED_SYMBOLS in
src/register.c). cvs rep updated.

> I get the same problem with the AC_LIB_HAMLIB macro.  The problem 
> started after the hamlib-1.1.2 release.

ahem, the AC_LIB_HAMLIB from hamlib.m4 has never been tested, and I'm
quite surprised you managed to run aclocal against it without troubles.
Anyway, lt_preloaded_symbols and AC_LIB_HAMLIB are to be fixed.

Cheers,
Stephane