cross-compiling difficulty with on-the-fly gen/build/use paradigm

cross-compiling difficulty with on-the-fly gen/build/use paradigm

[John Baron]

I'm having a problem trying to cross-compile audit.  The problem is that 
gen_actiontabs_h is built using the cross-compiler (for ARM), and then it's 
asked to run on the host (x86_64).  [I've seen some discussion of cross-
compiling, but this issue hasn't been brought up, AFAICT]

make  all-recursive
make[1]: Entering directory `/src/blah-blah/external-3rdparty/audit'
Making all in lib
make[2]: Entering directory `/src/blah-blah/external-3rdparty/audit/lib'
arm_v5t_le-gcc -DHAVE_CONFIG_H -I. -I.. -I. -I.. -I../auparse  -I/include -
I/include -L/lib -fPIC -DPIC -D_GNU_SOURCE '-DTABLE_H="actiontab.h"' -g -O2 -MT 
gen_actiontabs_h-gen_tables.o -MD -MP -MF .deps/gen_actiontabs_h-gen_tables.Tpo 
-c -o gen_actiontabs_h-gen_tables.o `test -f 'gen_tables.c' || echo 
'./'`gen_tables.c
mv -f .deps/gen_actiontabs_h-gen_tables.Tpo .deps/gen_actiontabs_h-gen_tables.Po
/bin/sh ../libtool --tag=CC   --mode=link arm_v5t_le-gcc -fPIC -DPIC -
D_GNU_SOURCE '-DTABLE_H="actiontab.h"' -g -O2  -L/lib -L/lib -o gen_actiontabs_h 
gen_actiontabs_h-gen_tables.o  
libtool: link: arm_v5t_le-gcc -fPIC -DPIC -D_GNU_SOURCE -
DTABLE_H=\"actiontab.h\" -g -O2 -o gen_actiontabs_h gen_actiontabs_h-
gen_tables.o  -L/lib
./gen_actiontabs_h --lowercase --i2s --s2i action > actiontabs.h
/bin/sh: ./gen_actiontabs_h: cannot execute binary file
make[2]: *** [actiontabs.h] Error 126
make[2]: Leaving directory `/src/blah-blah/external-3rdparty/audit/lib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/src/blah-blah/external-3rdparty/audit'
make: *** [all] Error 2

Is there a simple way around this?  A complex way, perhaps?  Extra points for 
simple!

Thanks
- John

Re: cross-compiling difficulty with on-the-fly gen/build/use paradigm

[Steve Grubb]

On Friday, August 17, 2012 08:19:48 PM John Baron wrote:
> I'm having a problem trying to cross-compile audit.  The problem is that
> gen_actiontabs_h is built using the cross-compiler (for ARM), and then it's
> asked to run on the host (x86_64).  [I've seen some discussion of cross-
> compiling, but this issue hasn't been brought up, AFAICT]
> 
> Is there a simple way around this?  A complex way, perhaps?  Extra points
> for simple!

Unfortunately no. This code has been there for quite a while. The issue is 
basically that we were doing performance analysis of ausearch/report and 
libauparse. We found that the integer to string lookups were causing a 
performance hit. Mirek wrote some code to turn these from a serial search into 
a sorted list that I think are now searched using a b-tree algorithm. So, at 
compile time what happens is these tables are sorted so that later they are 
fast. This improved performance quite a bit.

-Steve

Re: cross-compiling difficulty with on-the-fly gen/build/use paradigm

[Miloslav Trmac]

----- Original Message -----
> I'm having a problem trying to cross-compile audit.  The problem is that
> gen_actiontabs_h is built using the cross-compiler (for ARM), and then it's
> asked to run on the host (x86_64).

> Is there a simple way around this?  A complex way, perhaps?  Extra points for
> simple!

The simplest way for users of released tarballs would be to include the generated files inside the tarball - from a quick look that should be really simple, but it also doesn't help users of svn checkouts.

Then there are two more complex ways:
* Add the necessary build machinery: find a local C compiler, and use custom Make rules to build these tools.  Unfortunately it seems that autotools don't provide a direct way to do this, some internet forums suggest creating a subdirectory with its own "./configure" script that is configured to build for the "build host" even when cross-compiling.
* Rewrite the gen_tables.c code in an interpreted language, e.g. Python or Perl - adds a build dependency on that language, but avoids this problem.

In all of the cases above I'm worried about ABI differences - e.g. the build and host architecture having a different integer assigned to SHMGET or any of the other macros.  I haven't checked whether that is really a problem, though.  That might ultimately require the rewrite into an interpreted language (so that headers from the build and host systems wouldn't be mixed).  


Of course it would also always work to build the tables at run-time, but I suspect that would be a bit frowned upon.
    Mirek