Ekos & INDI Development Thread
I wondered if it is possible to have more compacts user interface for Ekos ?
With a 1366x768 screen sometimes the lower buttons are sometimes unreachable. Maybe just have smallest icons on tabs and choose more tiny character police can help. Maybe a resource file with some options could be useful to adapt the gui to the user screen.
(Reading database ... 263456 files and directories currently installed.) Preparing to unpack .../libindi1_1.2.0+r1031.253~ubuntu16.04.1_amd64.deb ... Unpacking libindi1:amd64 (1.2.0+r1031.253~ubuntu16.04.1) over (1.1.0-1ubuntu1) ... dpkg: error processing archive /var/cache/apt/archives/libindi1_1.2.0+r1031.253~ubuntu16.04.1_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/indi/MathPlugins/libindi_SVD_MathPlugin.so', which is also in package libindi-plugins:amd64 1.1.0-1ubuntu1 Processing triggers for libc-bin (2.23-0ubuntu3) ... /sbin/ldconfig.real: /usr/lib/x86_64-linux-gnu/libcfitsio.so.4 is not a symbolic link /sbin/ldconfig.real: /usr/lib/libatikccd.so.1 is not a symbolic link /sbin/ldconfig.real: /usr/lib/libatikccd.so.0 is not a symbolic link Errors were encountered while processing: /var/cache/apt/archives/libindi1_1.2.0+r1031.253~ubuntu16.04.1_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1)
Don't worry bout the symbolic link issues - it's this bit:
dpkg: error processing archive /var/cache/apt/archives/libindi1_1.2.0+r1031.253~ubuntu16.04.1_amd64.deb (--unpack):
trying to overwrite '/usr/lib/x86_64-linux-gnu/indi/MathPlugins/libindi_SVD_MathPlugin.so', which is also in package libindi-plugins:amd64 1.1.0-1ubuntu1
I can get all the dependant packages except "libkf5init-dev" as the KDE toolkit has moved on and created kinit-dev instead (along with all the other packages names being renamed).
Is there a way/place I can get this and build for arm64?
The development is on KDE framework 5. Installing this (and the massive amount of disk space) for arm64 (i.e. arm v8 on the C2) along with the other dependences satisfies the cmake build script.
I tried a quick make -j4 last night but it failed with a C++ internal compiler error which I take may be that it's running out of memory so I've just started a non-parallel make to see if it will get through..
I have already build the indi system on arm64 for the C2. That worked flawlessly - although I will need to look at how I will be able to run the 32bit ATIK drivers (perhaps a 32bit indi server for those drivers remote .. or port my own ATIK drivers over for my own use).
Build complete - seems that make -j4 (i.e. doing 4 parallel compiles runs out of memory).
I present native 64bit ODroid C2 indi/kstars/ekos with all the trimmings (astrometry etc). The C2 has an ARM v8 so it will be using a few additional instructions over the C1/RPi.
knro wrote: Thanks a lot for your work on getting this compiled on aarch64. There are currently no autobuilds for this architecture hence you faced some difficulties in getting things sorted. I'm sure once aarch64 is more mainstream, Ubuntu's launchpad shall support it.
The only issue I have found is in the 3rd party drivers for the ASICAM. It doesn't find references to functions but they do supply the bin file for arm v7 however I assume that will be a binary for 32bit (assuming again that it's not a downloaded firmware bin).
The only other thing will be ATIK 64bit support - although it may be possible to hybrid with a 32bit indiserver on the existing atik_ccd drivers.
I've attached the console output (text file)
There's a double free - what I've seen in the past is rather than do free(pointer); use a macro that checks if pointer is null if not frees then sets the point to null. thus preventing any double calls causing a crash.
There also seems to be missing method (or call that needs taking out):
QObject::connect: No such slot EkosManager::checkFITSViewerState() in /home/odroid/Projects/kstars/kstars/ekos/ekosmanager.cpp:131
QObject::connect: (sender name: 'show_fits_viewer')
QObject::connect: (receiver name: 'EkosManager')
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:
I'll have look into that
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:
File Attachment:File Name: CMakeOutput.log.txt
File Size:43 KB
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.
~/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)
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)
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)
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
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..