Closed fweimer-rh closed 1 month ago
It seems that astrometry >= 0.82 has overcame the qsort_r usage? https://github.com/dstndstn/astrometry.net/blob/0.82/include/astrometry/os-features.h
Certainly possible. I only checked this repository here and didn't track the full upstream relationship.
It is certainly possible that they did fix this upstream, but the problem is that I had to make so many changes to astrometry to make it compile on Windows, to make it play nicer on macOS, and to make it function as an internal library that would not require lots of temporary files that I can't update to a higher astrometry.net version without doing a lot of work. I had to remove a lot of code and modify a lot of functions to support the use case of StellarSolver, but astrometry.net needs that code for other use cases that StellarSolver does not require. I would like to update the base of StellarSolver to the latest astrometry.net, but I will need a large chunk of time to do so.
Thanks to @timsurber for his contribution, and to @knro for letting me know about it. @fweimer-rh and @mattiaverga can you confirm that the fix rectified the issue for you?
I'm not expert, but I don't see the qsort_r warning in build logs anymore, so... I suppose this is fixed.
Thanks!
The
qsort_r
function comes with different prototypes on different systems. There are some tests aroundNEED_DECLARE_QSORT_R
andNEED_SWAP_QSORT_R
that try to work around that. However, they only work with compilers which accept implicit function declarations.Without support for implicit function declarations in the compiler, I get a build failure:
If I add
-D_GNU_SOURCE
to the build flags, the build fails because of a conflicting prototype:So there does not seem to be a good way to build this program with C99 compilers on glibc (or other non-BSD platforms).