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 -- Linux-audit mailing list Linux-audit(a)redhat.com https://www.redhat.com/mailman/listinfo/linux-audit

----- Original Message ----- > > 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. Is that really an issue with the current code? The gentab.c code was designed to avoid text relocations.

At least on x86_64 (which, true, is especially well-designed for this), there are no text relocations in libaudit nor libauparse, whether --with-alpha or --with-armeb are used or not. In fact the number of relocations of any kind is exactly the same in both cases. Any one care to retest this on a different architecture, e.t. 32-bit x86? FWIW, at least the attached patch was necessary to build with --with-alpha --with-armeb.

FWIW, at least the attached patch was necessary to build with --with-alpha --with-armeb. Mirek

On Friday, November 30, 2012 02:42:27 PM Laurent Bigonville wrote: > Le Mon, 26 Nov 2012 12:21:55 -0500 (EST), > > Miloslav Trmac <mitr(a)redhat.com&gt; a écrit : > > FWIW, at least the attached patch was necessary to build with > > --with-alpha --with-armeb. Mirek > > I unfortunately still have a failure in the checks with both svn > HEAD and 2.2.1 when passing --with-armeb > > Unexpected match `a1' > FAIL: lookup_test > > An idea? Thanks for reporting this. Its fixed in trunk now.

----- Original Message ----- > Le Fri, 30 Nov 2012 09:05:19 -0500, > Steve Grubb <sgrubb(a)redhat.com&gt; a écrit : > > > On Friday, November 30, 2012 02:42:27 PM Laurent Bigonville wrote: > > > Le Mon, 26 Nov 2012 12:21:55 -0500 (EST), > > > > > > Miloslav Trmac <mitr(a)redhat.com&gt; a écrit : > > > > FWIW, at least the attached patch was necessary to build with > > > > --with-alpha --with-armeb. Mirek > > > > > > I unfortunately still have a failure in the checks with both svn > > > HEAD and 2.2.1 when passing --with-armeb > > > > > > Unexpected match `a1' > > > FAIL: lookup_test > > > > > > An idea? > > > > Thanks for reporting this. Its fixed in trunk now. > > Thanks, arm support is now compiling. > > But it still failing with the same error if both --with-alpha and > --with-armeb are enabled. Locally I "fixed" it by adding a srand(2) to the beginning of main() in lib/test/lookup_test.c.