Add support for elf_aux_info() on OpenBSD

[brad0]

No description provided.

[jmarshall]

It appears that elf_aux_info() has existed on OpenBSD for about two months and is not yet present in any OpenBSD release. Under the circumstances, it would be premature to add this without a configure test or other version check.

[brad0]

Something like this is what I use most elsewhere.

[jkbonfield]

Using AC_CHECK_FUNCS seems like a good approach, although I question why we still need the __linux__ ifdef if we're detecting it via autoconf. Ie why remove defined __FreeBSD__ but not defined __linux__?

I guess this is to support non-configure build environments (but personally I think having two build configurations just leads to more problems than it solves and weird code like this where we have a mixture of ways of detecting things). If that is the logic, then we should be keeping all the existing system ifdefs and adding the HAVE_ELF_AUX_INFO bit and not replacing FreeBSD with it.

Edit: I am aware we'd get some push-back if we forcibly went configure only from the people who just copy the entire code into their own source tree and build it themselves as part of their own project, but frankly I have minimal time for this behaviour. It leads to out-dated copies of code as it's not possible to upgrade trivially and is a disservice to their users. It's also an extra burden (assuming anyone notices) on distro builders.

[brad0]

Using AC_CHECK_FUNCS seems like a good approach, although I question why we still need the __linux__ ifdef if we're detecting it via autoconf. Ie why remove defined __FreeBSD__ but not defined __linux__?

I guess this is to support non-configure build environments (but personally I think having two build configurations just leads to more problems than it solves and weird code like this where we have a mixture of ways of detecting things). If that is the logic, then we should be keeping all the existing system ifdefs and adding the HAVE_ELF_AUX_INFO bit and not replacing FreeBSD with it.

Well it would be better to have autoconf detect getauxval as well. I can do so.

[jmarshall]

We previously discussed this in samtools/htscodecs#63 but punted on detecting during configure instead. It's easier here in htslib because the htscodecs build system vs htslib build system issue (mentioned in samtools/htscodecs#63 (comment)) does not arise. But it would be unfortunate for people doing non-configure builds if SIMD were now deactivated for them.

Personally from reading the tea leaves of the maintainers' activity, I would have guessed that now is not the time for this sort of change… 😄

[brad0]

I made another PR.

#1835

[jmarshall]

If it was considered sufficiently important (for the benefit of bioinformatics tools users on future OpenBSD) to activate this Neon code on OpenBSD using a system call that does not exist on current OpenBSD deployments, the following would suffice:

 #if defined __linux__ || defined __FreeBSD__
 #include <sys/auxv.h>
+#elif defined __OpenBSD__
+#include <sys/param.h>
+#if OpenBSD >= 202409
+#include <sys/auxv.h>
+#endif
 #elif defined __APPLE__
…
-#elif defined __FreeBSD__ && defined __arm__ && defined HWCAP_NEON
+#elif (defined __FreeBSD__ || (defined __OpenBSD__ && OpenBSD >= 202409)) && defined __arm__ && defined HWCAP_NEON
… etc …

while being a smaller change for HTSlib — one that, in particular, would not affect other platforms.

If activating SIMD code on future OpenBSD installations is your goal, you should really focus on htscodecs, where activating SIMD implementations would make a larger difference to overall run time.