×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Ekos & INDI Development Thread

Not Ekos per se, but now you can open FITS files from your file browser or the command line.
8 years 2 months ago #6586

Please Log in or Create an account to join the conversation.

  • Posts: 454
  • Thank you received: 51

Replied by Patrick on topic Ekos Development Thread

Hello Jasem,
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.

CS

Patrick
8 years 2 weeks ago #7233

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 10

Replied by NickK on topic Ekos Development Thread

Possible bleeding/indi package issue?
(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:
ODROID C2 Ubuntu
Last edit: 7 years 10 months ago by NickK.
7 years 10 months ago #8171

Please Log in or Create an account to join the conversation.

You already have libindi from Debian installed, so remove it first before installing bleeding edge INDI.
The following user(s) said Thank You: NickK
7 years 10 months ago #8172

Please Log in or Create an account to join the conversation.

You already have libindi from Debian installed, so remove it first before installing bleeding edge INDI.
7 years 10 months ago #8173

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 10

Replied by NickK on topic Ekos Development Thread

just to add - that was on an "sudo apt upgrade" rather than an install.
ODROID C2 Ubuntu
7 years 10 months ago #8174

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 10

Replied by NickK on topic Ekos Development Thread

Hi I'm attempting to build kstars on the ODroid C2 (aarch64) as the armhf seems to have issues.

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?
ODROID C2 Ubuntu
7 years 10 months ago #8184

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 10

Replied by NickK on topic Ekos Development Thread

Ok almost there - I have all the dependences sorted. It was annoying me that to run 32bit means you start needing more and more 32 bit dependencies installed.. to the point that I decided to go down the 64bit route..

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).

EDIT
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.
ODROID C2 Ubuntu
The following user(s) said Thank You: Jasem Mutlaq
Last edit: 7 years 10 months ago by NickK.
7 years 10 months ago #8190
Attachments:

Please Log in or Create an account to join the conversation.

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.
7 years 10 months ago #8192

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 10

Replied by NickK on topic Ekos Development Thread


No problem.

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.
ODROID C2 Ubuntu
Last edit: 7 years 10 months ago by NickK.
7 years 10 months ago #8193

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 10

Replied by NickK on topic Ekos Development Thread

Runtime gets more interesting.. I have a regrettable crash.

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')
ODROID C2 Ubuntu
Last edit: 7 years 10 months ago by NickK.
7 years 10 months ago #8195

Please Log in or Create an account to join the conversation.

  • Posts: 77
  • Thank you received: 10

Replied by NickK on topic Ekos Development Thread

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:

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.

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..
ODROID C2 Ubuntu
Last edit: 7 years 10 months ago by NickK.
7 years 10 months ago #8220
Attachments:

Please Log in or Create an account to join the conversation.

Time to create page: 1.173 seconds