Joop Stakenborg wrote:
> aba@pc3:~$ rigctl -vvvvv -m 210
> rig:rig_init called
> rig: loading backend kenwood
> rig: dlsym(initrigs_kenwood) failed (/usr/local/lib/libhamlib-1.1.3-pre2-pa4tu.so.0: undefined symbol: initrigs_kenwood)
> Unknown rig num 210, or initialization error.
> Please check with --list option.
>
> initrigs_kenwood is in libhamlib-kenwood.so and not in libhamlib-1.1.3-pre2-pa4tu.so.0:
yep, the traces are not that explicit maybe.
Actualy, rigctl tries to open libhamlib-kenwood.so, which fails because
it only search for in /lib and /usr/lib. At least, this is what told me
"strace rigctl -vvvv -m210 2> syscall_trace" on my system.
So, rigctl falls back to static backend symbols in libhamlib, and fails
because there aren't.
> aba@pc3:~$ nm /usr/local/lib/libhamlib-kenwood.so|grep init
> 000012e4 ? _init
> 00001538 t init_dummy
> 00003154 t init_dummy
> 00002c20 T initrigs_kenwood
>
> but rigctl is only linked with libhamlib-1.1.3-pre2-pa4tu.so.0:
>
> aba@pc3:~$ ldd /usr/local/bin/rigctl
> libhamlib-1.1.3-pre2-pa4tu.so.0 => /usr/local/lib/libhamlib-1.1.3-pre2-pa4tu.so.0 (0x40016000)
> libdl.so.2 => /lib/libdl.so.2 (0x40032000)
> libm.so.6 => /lib/libm.so.6 (0x40036000)
> libc.so.6 => /lib/libc.so.6 (0x40059000)
> /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
>
> Should you not link rigctl with all the libhamlib-<rig>.so files?
No, it would be too painful, and the existence of new backend plugin
should be hidden to rigctl.
Thanks for the traces!
Solution cont'd in next mail.
Stephane
|
