Wireshark-dev: Re: [Wireshark-dev] T-Shark Cross Compilation issue
From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Fri, 16 Oct 2009 13:23:23 -0700
(Moving to wireshark-dev - this isn't a normal "developer" issue, as you're just compiling from source rather than actually *modifying* Wireshark, but it's not a normal "user" issue, either, as you're trying to build Wireshark. wireshark-dev is probably closer, as it requires a bit more attention from the developers than a user issue would.)

On Oct 16, 2009, at 10:39 AM, Clint Thomas wrote:

Salutations,

I’ve been making an attempt to cross compile TShark (and dumpcap) for my PPC 8541 platform, overcoming the slight hurdles that keep presenting themselves (missing libraries, etc.) My first tries were using the old stable version (1.0.9), whereupon I ran into a problem regarding the rdps binary (cross compiled binary wants to execute on my x86 host machine). This was detailed here

http://www.wireshark.org/lists/wireshark-dev/200905/msg00346.html

In another post, somebody mentioned that this problem had been resolved in the latest version (1.2.2), so I decided to try that. In doing so, I was able to get most of the way through the compilation process. Here is the configure options I used in my build.

./configure --prefix=/opt/powerpc-85xx-linux/ --host=powerpc-linux -- disable-wireshark --disable-editcap --disable-capinfos --disable- mergecap --disable-text2pcap --disable-idl2wrs --disable-dftest -- disable-randpkt --disable-rawshark

After allowing the compilation process some time to churn, a similar problem occurred, this time with the lemon executable. Here is the error I get.

Making all in dfilter
make[3]: Entering directory `/home/cthomas/Desktop/project/ wireshark-1.2.2/epan/dfilter' ../../tools/lemon/lemon t=./../../tools/lemon/lempar.c ./ grammar.lemon || \
        (rm -f grammar.c grammar.h ; false)
/bin/sh: ../../tools/lemon/lemon: cannot execute binary file
make[3]: *** [grammar.c] Error 1

What I’m wondering is, can I disable lemon’s execution during the build process and be safe? Do I need lemon to be on my target platform for TShark to operate correctly?

You need lemon in order to build Wireshark - but lemon needs to be built to run on the build machine rather than the host machine.

(The terminology is a bit confusing here; I think it was devised in order to allow "Canadian Cross" builds - where you build, on platform A, a tool or tools that run on platform B and produces code for platform C - e.g., cross-building a cross-compiler - to be talked about. As per

	http://sourceware.org/autobook/autobook/autobook_17.html

the machine on which you're doing the build is the "build" machine, the machine on which the result is to run is the "host" machine, and, if the resulting software generates or otherwise processes code, the machine that code is for is the "target" machine. You used "--host=", so you already understand this, so I'm putting this in for the benefit of people unfamiliar with this - it certainly hurt *my* brain when trying to understand some patches people submitted for libpcap and tcpdump, for example, as I'd always thought of the "host" as the machine on which you were doing the build and the "target" as the machine for which you were building.)

Or is this just an artifact of the build process, and I need to change the CC used to build the tool?

Yes.

The confusing part is that

	http://sourceware.org/autobook/autobook/autobook_270.html

seems to imply that stuff built for the build machine should be built with $(CC_FOR_BUILD) - but

	1) that's what we're doing now, and it's apparently *not* working

and

	2) Jeff Morriss' followup to the mail you cite:

		http://www.wireshark.org/lists/wireshark-dev/200905/msg00351.html

	   says the rdps fix was described in

		http://www.wireshark.org/lists/wireshark-users/200702/msg00059.html

	   and the fix for that was to change $(CC_FOR_BUILD) to $(CC)!

Now

	http://sourceware.org/autobook/autobook/autobook_270.html

also says

A `configure' script should normally permit the user to define `CC_FOR_BUILD' explicitly in the environment. Your configure script should help by selecting a reasonable default value. If the `configure' script is not being run with a cross compiler (i.e., the `cross_compiling' shell variable is `no' after calling `AC_PROG_CC'), then the proper default for `CC_FOR_BUILD' is simply `$(CC)'. Otherwise, a reasonable default is simply `cc'.

so the problem might simply be that CC_FOR_BUILD is being set to the wrong compiler. However, unless I'm missing something, in your case CC_FOR_BUILD would be set to CC by the configure script, so I'm not sure why changing CC_FOR_BUILD to CC would fix things; therefore, it seems pretty likely that I'm missing something....

There's a thread at

	http://sources.redhat.com/ml/automake/2004-01/msg00086.html

which doesn't seem to reach a definitive conclusion as to how to do this right.

If there are any experts on cross-building with automake/autoconf- using tools in the audience, they should feel free to contribute their expertise; my experience with cross-building is limited to cross- building projects that don't use automake or autoconf....

For a short-term workaround, trying replacing, in the

lemon$(EXEEXT): lemon.c
$(CC_FOR_BUILD) -D_U_="" $(CFLAGS_FOR_BUILD) $ (LDFLAGS_FOR_BUILD) -o $@ $?

in tools/lemon/Makefile.in, CC_FOR_BUILD with CC, CFLAGS_FOR_BUILD with CFLAGS, and LDFLAGS_FOR_BUILD with LDFLAGS. (Don't replace them in Makefile.am, as you'll then need to have automake installed and re- generate Makefile.in. You probably don't want to go down that path....) Let us know whether that works.