djibb wrote:

1) why you did not use kstars-bleeding from jasem ppa ?
The C2 is an ARM 64bit V8 architecture, compiling with a compiler that knows how to optimise and build for it results in more efficient and faster performance. It's using all of the capabilities of each core rather than being generic. At the time there were no 64bit ARM v8 builds (may this year)..
Having 64 and 32 binaries of everything gets complicated and bloated.. so 64bit for everything.
djibb wrote:
2) how you compile cfitsio in 32 bit ? (I'm really not a multiarch guru) (I've still compil it in 64 bits ;)
You can tell the ./configure command to make for different architectures - including 32 and 64bit. EKos uses the 64bit build I've built into the system.. the indi_atik_ccd process then needs to runtime link against the 32bit version - hence FD_LIBRARY_PATH on linux gives a list of locations for the runtime linker to search.. you could add both 64bit and 32bit. The linker will reject the 64 bit, then continue to search for a 32bit and will then find it.
djibb wrote:
3) about using cfitsio 32, you call setenv, then start indiserver ? (or it is on the same line)
Yes.
I create a shell terminal session, then set FD_LIBRARY_PATH to add the new 32bit cfitsio location and then execute the indiserver on the command line - actually I do this with all my drivers.

When indiserver executes it runs as process and starts the other drivers as a process with just a socket connection between to communicate. This means that the indiserver and other drivers can be 64bit .. and other drivers can be 32bit without needing all to be one or the other.

Lastly - you may find that, on 64 bit, the astrometry.net solver python script incorrectly identifies the precision in the FITS image file - the is because it's attempting to dynamically identify the type at runtime and gets it wrong (it seems the type identification differs between 32 and 64bit python - bad programming!). The simple way to solve this is to save in a PNG and the problem is solved :D

Read More...