Wireshark-dev: Re: [Wireshark-dev] how to cross-compile tshark and tools

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Wed, 13 Apr 2011 09:41:26 -0700
On Apr 13, 2011, at 9:27 AM, George Nychis wrote:

>> On Wed, Apr 13, 2011 at 12:05 PM, Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> wrote:
>> George Nychis wrote:
>> BTW, it appears that this has come up before in the past (2009):
>> https://$1.wireshark.org/lists/wireshark-users/200910/msg00123.html <http://1.wireshark.org/lists/wireshark-users/200910/msg00123.html>
>> 
>> 
>> but it doesn't seem like a resolution was made.. but this post has a short-term workaround:
>> http://seclists.org/wireshark/2009/Oct/286
>> 
>> I am going to try this out, the original poster never got back with whether this worked or not.
>> 
>> What version are you trying to cross-compile?  I believe that the changes discussed in that thread were eventually checked in with rev 30586.
> 
> Hi Jeff,
> 
> I am on Revision: 36615
> 
> So it seems like I am past that revision.

What's in the configure.in file in the trunk is:

dnl Check for CPU / vendor / OS
dnl The user is encouraged to use either `AC_CANONICAL_BUILD', or
dnl `AC_CANONICAL_HOST', or `AC_CANONICAL_TARGET', depending on the
dnl needs.  Using `AC_CANONICAL_TARGET' is enough to run the two other
dnl macros.
dnl
dnl As nothing in the Wireshark is itself a build tool (we are not,
dnl for example, a compiler that generates machine code), we probably
dnl don't need AC_CANONICAL_TARGET, so, in theory, we should be able
dnl to use AC_CANONICAL_BUILD and AC_CANONICAL_HOST - or perhaps just
dnl AC_CANONICAL_HOST - instead.  Note that we do have tools, such as
dnl lemon, that need to be built for the build machine, not for the
dnl host machine, so we might need both.
dnl
dnl This has to be done *after* AC_INIT, otherwise autogen.sh fails.

dnl AC_CANONICAL_BUILD
dnl AC_CANONICAL_HOST
AC_CANONICAL_TARGET

So the question then is what *else* has to be done to arrange that lemon, and other tools such as rdps, be built for the machine on which the build is being done (the build-system, to use the term used in the Autoconf manual), and that *Shark itself be built for the machine we're cross-compiling for (the host-system) - we don't build anything for the target-system, as we don't have a target-system as we're not a build tool.  Presumably there would have to be multiple CC variables, so that you use one to build stuff that needs to run on the build-system and use another one to build stuff that needs to run on the host-system.

Of course, none of that addresses any configuration tests we might do that involve compiling *and* running code; if we do any of that, cross-compilation is even harder to make work.