Re: [Valgrind-developers] size of the various tools and nr of supported architectures ....

[Philippe W. <phi...@sk...>]

On Mon, 2015-03-30 at 13:00 -0700, Yan wrote:
> Hey! Sorry about the laggy response; I was traveling yesterday :-(
> 
> 
> For UCSB's purposes, option 2 works ok! If I understand it correctly,
> it's basically exactly what happens currently, right? Option 2.5 is
> fine for us as well.
Option 1 and option 2 are effectively mostly similar (just need to tweak
configure to have option 2).
When VEXMULTIARCH is defined, then main_main.c is compiled similarly
to the current trunk. As you can see in the patch, the changes are
trivial.

Option 2.5 implies some changes to Makefile.am
(not completely trivial changes, at least for someone
like me that knows close to 0 about automake/conf magic)

An advantage of option 2.5 is that main_main.c will always be compiled
in both VEXMULTIARCH and single arch mode, to help catching an unlikely
compilation bug in VEXMULTIARCH not detected otherwise.

A user that needs multi arch can then have it just
by giving 2 libs to link (in the good order) :
   libvexmultiarch-x86-linux.a libvex-x86-linux.a
where the first lib only contains main_main.c compiled with VEXMULTIARCH
defined. The 2nd lib contains main_main.c compiled in single arch,
and all the other VEX object files, and is the one to use by default.

Philippe