[Guy Harris <guy@xxxxxxxxxxxx>]

(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.