Create little-endian hints files on all architectures

[se]

Summary

Commit 7b77d37a561b47d (with fix in da2d6e2815d769) has added byte-order independent hints file parsing to rtld-elf, with MFC to stable/13 and stable/14 on 2024-03-29.
Equivalent code has been added to the 2 commands that operate on hints files: ldconfig in all maintained branches and the pkg-1.21.0 package.
This makes it possible to use a little-endian hints file on all architectures, with the goal to eventually remove the compatibility code that allows for either byte-order on all architectures.
While here, a small optimization has been added to take advantage of constant expression evaluation in the is_be evaluation.

Since the eventual removal of compatibility code from rtld-elf (where it slightly increases the run-time) depends on all supported releases using little-endian hints files by default, I'd want to MFC this change to stable/14 in time for FreeBSD-14.1.

Test Plan

Apply the patch and verify that the default byte-order hints file (created during rc file processing when going multi-user) has changed to little-endian.
The -B option can be added to the ldconfig command in line 45 of /etc/rc.d/ldconfig to force creation of a big-endian hints file.
There should not be any change in functionality with either byte-order.

The removed comparison always evaluated to false on little-endian systems and should have been removed by constant expression evaluation on them.
Therefore, testing is only required on big-endian systems.

[tuexen]

I'll test the patch on a BE system and report back.

[tuexen]

I tested this patch on a BE system, the hints file is written in LE and can be used without problems.
I personally would commit the optimization (where there is not functional change intended) separately
from the change of the byte ordering of the hints file.

[kib]

sbin/ldconfig/elfhints.c

223

Why this chunk is needed?

[se]

sbin/ldconfig/elfhints.c

223

This chunk is not needed, just a minor optimization since it allows constant expression evaluation to remove the macro invocation. (That's what "While here ..." in the SUMMARY refers to ...)

Since htobe32() returns either the unmodified operand or the swapped operand (depending on the byte-order of the CPU) it does not matter whether the left or right operand of the comparison is subjected to this potential byte swapping.

I can commit this change in a separate commit, if you think it should not be merged into this one.

[kib]

sbin/ldconfig/elfhints.c

223

Yes, please commit separately with the explicit explanation.