To get the cloud makers ATIK drivers working, the LD_LIBRARY_PATH environment variable needs to be setup to point to a 32bit version of the libcfitsio3.so library.
indi_eqmod_telescope has an issue:
2016-05-15T06:51:55: Driver indi_eqmod_telescope: indi_eqmod_telescope: symbol lookup error: indi_eqmod_telescope: undefined symbol: _ZN4INDI9Telescope22SetTelescopeCapabilityEjh
2016-05-15T06:51:55: Driver indi_eqmod_telescope: stderr EOF
2016-05-15T06:51:55: Driver indi_eqmod_telescope: restart #10
2016-05-15T06:51:55: Driver indi_eqmod_telescope: pid=10450 rfd=0 wfd=9 efd=10
2016-05-15T06:51:55: Driver indi_eqmod_telescope: sending msg copy 1 nq 1:
<getProperties version='1.7'/>
I'll have look into that
edit:
inditelescope.cpp:void INDI::Telescope::SetTelescopeCapability(uint32_t cap, uint8_t slewRateCount)
inditelescope.h: * @brief SetTelescopeCapability sets the Telescope capabilities. All capabilities must be initialized.
inditelescope.h: void SetTelescopeCapability(uint32_t cap, uint8_t slewRateCount=0);
Hmm .. seems the name mangling isn't working for this - not sure if there's a reflective design element in the INDI system but..
I've attached the CMakeOutput.log for the build:
Name mangling differs between 32 and 64bit compilers. However the indilib was compiled on the same compiler.. so unless the indilb build disables name mangling or the cake script does some thing odd..
It has to be some shared library as the linker completed successfully. if I run ./indi_eqmod_telescope I get the same error so it's the startup linking.
LDD gives:
~/Projects/3rdparty/indi-eqmod$ ldd indi_eqmod_telescope
linux-vdso.so.1 => (0x0000007f809ab000)
libindi.so.1 => /usr/lib/libindi.so.1 (0x0000007f80960000)
libindidriver.so.1 => /usr/lib/aarch64-linux-gnu/libindidriver.so.1 (0x0000007f8087e000)
libnova-0.14.so.0 => /usr/lib/aarch64-linux-gnu/libnova-0.14.so.0 (0x0000007f804e4000)
libindiAlignmentDriver.so.1 => /usr/lib/aarch64-linux-gnu/libindiAlignmentDriver.so.1 (0x0000007f804ba000)
libstdc++.so.6 => /usr/lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000007f80328000)
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007f8027c000)
libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000007f8025b000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f80115000)
/lib/ld-linux-aarch64.so.1 (0x000000558019d000)
libusb-1.0.so.0 => /lib/aarch64-linux-gnu/libusb-1.0.so.0 (0x0000007f800ee000)
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007f800c2000)
libcfitsio.so.2 => /usr/lib/aarch64-linux-gnu/libcfitsio.so.2 (0x0000007f7ff28000)
libz.so.1 => /lib/aarch64-linux-gnu/libz.so.1 (0x0000007f7ff00000)
libjpeg.so.8 => /usr/lib/aarch64-linux-gnu/libjpeg.so.8 (0x0000007f7feb9000)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000007f7fea6000)
libgsl.so.19 => /usr/lib/aarch64-linux-gnu/libgsl.so.19 (0x0000007f7fc96000)
libgslcblas.so.0 => /usr/lib/aarch64-linux-gnu/libgslcblas.so.0 (0x0000007f7fc55000)
libudev.so.1 => /lib/aarch64-linux-gnu/libudev.so.1 (0x0000007f7fc23000)
And file gives: ~/Projects/3rdparty/indi-eqmod$ file indi_eqmod_telescope
indi_eqmod_telescope: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=817682517d97a47ae7526651eb989107cb4d9ce9, not stripped
So that's all good so far.. then LDD on the referenced library:
~/Projects/3rdparty/indi-eqmod$ ldd /usr/lib/libindi.so.1
linux-vdso.so.1 => (0x0000007f82c31000)
libnova-0.14.so.0 => /usr/lib/aarch64-linux-gnu/libnova-0.14.so.0 (0x0000007f8284d000)
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007f827a2000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f8265b000)
/lib/ld-linux-aarch64.so.1 (0x0000005564de0000)
again with file: ~/Projects/3rdparty/indi-eqmod$ file /usr/lib/libindi.so.1
/usr/lib/libindi.so.1: symbolic link to libindi.so.1.2.0
~/Projects/3rdparty/indi-eqmod$ file /usr/lib/libindi.so.1.2.0
/usr/lib/libindi.so.1.2.0: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=c55138cc547301f1b48ebf0371db49fa8c79d414, not stripped
Hmm all 64 bit..
Just to check there's nothing on the runtime path: ~/Projects/3rdparty/indi-eqmod$ whereis libindi.so.1
libindi.so: /usr/lib/libindi.so.1 /usr/lib/libindi.so
So turning attention to the indi_eqmod_telescope binary..
~/Projects/3rdparty/indi-eqmod$ nm -an indi_eqmod_telescope | c++filt | grep SetTelescope
U INDI::Telescope::SetTelescopeCapability(unsigned int, unsigned char)
U means the symbol is undefined.
~/Projects/3rdparty/indi-eqmod$ nm -an /usr/lib/libindi.so.1 | c++filt | grep SetTelescope
~/Projects/3rdparty/indi-eqmod$ nm -an /usr/lib/libindidriver.so.1 | c++filt | grep SetTelescope
0000000000066b88 T INDI::Telescope::SetTelescopeCapability(unsigned int, unsigned char)
So the SetTelescope implementation is in libindidriver.so..
~/Projects/3rdparty/indi-eqmod$ ldd /usr/lib/libindidriver.so.1
linux-vdso.so.1 => (0x0000007f91699000)
libusb-1.0.so.0 => /lib/aarch64-linux-gnu/libusb-1.0.so.0 (0x0000007f9150a000)
libnova-0.14.so.0 => /usr/lib/aarch64-linux-gnu/libnova-0.14.so.0 (0x0000007f91171000)
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007f91144000)
libcfitsio.so.2 => /usr/lib/aarch64-linux-gnu/libcfitsio.so.2 (0x0000007f90faa000)
libz.so.1 => /lib/aarch64-linux-gnu/libz.so.1 (0x0000007f90f83000)
libjpeg.so.8 => /usr/lib/aarch64-linux-gnu/libjpeg.so.8 (0x0000007f90f3b000)
libstdc++.so.6 => /usr/lib/aarch64-linux-gnu/libstdc++.so.6 (0x0000007f90da9000)
libm.so.6 => /lib/aarch64-linux-gnu/libm.so.6 (0x0000007f90cfe000)
libgcc_s.so.1 => /lib/aarch64-linux-gnu/libgcc_s.so.1 (0x0000007f90cdc000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f90b96000)
/lib/ld-linux-aarch64.so.1 (0x000000556bf5f000)
libudev.so.1 => /lib/aarch64-linux-gnu/libudev.so.1 (0x0000007f90b65000)
~/Projects/3rdparty/indi-eqmod$ file /usr/lib/libindidriver.so.1
/usr/lib/libindidriver.so.1: symbolic link to libindidriver.so.1.2.0
~/Projects/3rdparty/indi-eqmod$ file /usr/lib/libindidriver.so.1.2.0
/usr/lib/libindidriver.so.1.2.0: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=f9c77347b39bc95de7268639518f353bca538cd0, not stripped
That's 64bit too..
Next to check the mangled versions..
nm -an ./indi_eqmod_telescope | grep SetTele
U _ZN4INDI9Telescope22SetTelescopeCapabilityEjh
nm -an /usr/lib/libindidriver.so.1 | grep SetTele
0000000000066b88 T _ZN4INDI9Telescope22SetTelescopeCapabilityEjh
Seems to be a match there.. so why isn't it runtime linking?
Well I did the obvious.. export LD_LIBRARY_PATH=/usr/lib and it starts without a problem.
On OSX the runtime linker takes explicit fixed shared library paths in the binary and doesn't rely on LD_LIBRARY_PATH. The ELF linker has that (you can see the /usr/lib references above) but chooses not to follow but instead prefers to use LD_LIBRARY_PATH instead.. which is crazy..