Steve is correct AFAIK regarding #2. I am unaware of the original meaning for ARMEB, but functionality it must match the machine name returned by the Linux Kernel. If --with-armeb is not used on ARM platforms, many audit tools will return "Machine Type Not Found" or something similar. This has been a little frustrating with ARM, because unlike X86/X86_64 machine types, there are a slew of ARM types out there based on my experience. The SVN currently has support for Qemu, most Android devices, and the Raspberry Pi. Other ARM processors are trivial to add if you have the machine name. This'll probably be needed upon the release of the armv8 64-bit processors.

Cheers,
Nathaniel Husted


On Fri, Nov 16, 2012 at 1:21 PM, Steve Grubb <sgrubb@redhat.com> wrote:
On Friday, November 16, 2012 06:00:56 PM Laurent Bigonville wrote:
> I've several questions about the --with-alpha and --with-armeb
> build-time flags.
>
> 1) are --with-alpha and --with-armeb intended to be enabled only on
> these architectures on could they also be enabled on any other one?

If you have an aggregating server and you want to make sense of the syscalls
on these arches, then you might want them enabled. To my knowledge, Fedora
never made an Alpha process distribution so it would be waste to enable that.
I suppose there is a remote possibility that some other distribution did and
it might get aggregated to a Fedora machine, but no one has ever complained.

> If I understand correctly it's only adding arch detection and syscall
> tables to ausyscall. Why are these syscall table conditional?

To reduce the number of text relocations in libaudit. Libaudit links against a
number of applications and text relocations eats memory and increases startup
time.


> 2) Is --with-armeb meant for ARMEB (aka ARM big-endian) or is it meant
> for ARM with embedded ABI? The help message of the configure says the
> later but it seems to be badly named.

I think its related to what comes out of uname -m.

-Steve