about Ethereal/Wireshark

Richard Sharpe realrichardsharpe at gmail.com
Sun Apr 11 16:27:25 EDT 2010

On Sun, Apr 11, 2010 at 10:13 AM, HongPeng Tian <hongpeng.tian at gmail.com> wrote:
> Richard Sharpe 写道:
> On Sun, Apr 11, 2010 at 7:55 AM, HongPeng Tian <hongpeng.tian at gmail.com>
> wrote:
> Great, thank you Mirko for your rapid response.
> I tried before, but failed when cross-compiling gtk2. I don't know how to
> deal with.
> May I get helps from you later?
> Yes, cross-compiling many of these packages takes effort. I have
> produced some notes at work on some of the things you will need to
> watch out for. I can send them to you.
> Thank you for reply!
> My board has 64MB SDRAM and 256MB NAND Flash, a mini2440-like board.

I don't think I have ever run Ethereal/Wireshark on a machine with
such a small amount of memory, even when I was doing active Ethereal
development back in 2000 through 2002. You will need swap enabled but
even then it is going to be as slow as a dog.

> I have the native development environment, but the env is quite old, has
> only a little of packages and tools compared to Openwrt. So I uses Openwrt
> now.
> As you have seen the mail by Mirko, S3C24xx is well supported in Openwrt,
> but it is especially for OpenMoko(S3C2442-based) and the dir has many
> things for OpenMoko. You can create new a dir in target/linux/ and add a
> config-2.6.xx, a Makefile and image dir.
> Of course, your experiences in wireshark are welcome, I need it :)
> I think first of all to port wireshark to openwrt is to make it run with
> as few dissectors as possible.

Here are some of my cross-compiling notes:

1. Sources of problems

There tends to be several different types of problems associated with
cross-compiling open source packages that do not exist if you are
building in a native environment:

    * Configure tests fail because configure cannot run test programs
or because it cannot find libraries needed during the build process.
This leads to the package being un-buildable or to run-time problems.
In general, do not hack configure scripts or code to work around this.
There are ways to help configure figure things out, which are
described below.
    * The Makefile generates does not know where the libraries are
that are needed to link, or the libraries cannot be found at runtime.
There are ways to work around this.
    * Sometimes configure.in has not been properly developed for
cross-compiling environments. Here you might need to hack the
configure.in script and regenerate configure.
    * In complex situations where shared-libraries that depend on
other shared libraries are needed, libtool fails, and certain
intermediate files need to be modified. These modifications should be
encoded into build scripts so that they can be carried forward and the
steps are not forgotten.
    * Libraries and include files that might be needed by other
packages must be put in a place where they can be used by the build
process, but the libraries must also be installed into the target
    * Problems caused by the tool chain. Eg, the version of gcc in the
tool chain generates bad shared library code if you enable the
generation of stack protection code. It causes all accesses to shared
libraries to crash.

2. Configure problems

Most open-source software runs a program called configure that figures
out what flavor of UNIX you have and creates Makefiles and a file
called config.h that sets a bunch of defines that control the code
that gets build. An example of why this is needed is the following.

The setpgrp system call takes different arguments on different
systems. On BSD systems, you call setpgrp(0, 0) while on POSIX systems
you use setpgrp(). The configure script has to figure this out, which
it typically does by creating a small program, compiling it and
running it to determine which version should be used in the code. In
the code itself, you will see things like:

    #ifdef SETPGRP_VOID
            res = setpgrp();
            res = setpgrp(0, 0);

To ensure that the build uses the correct code on your system
configure generates an include file, usually called config.h that
defines the the symbol SETPGRP_VOID if it is needed.

In some cases, the open source package does not even need to use
setpgrp but the writer of the configure.in file that configure is
generated from used boilerplate code from other projects or used a
configure.ac that checks every possible system call that can be used.

When configure is being run in a cross compiling environment it cannot
perform some of the tests it needs to run (because you are not
building on the target), and thus cannot determine what is needed in
cases like setpgrp. To work around this problem you can specify the
value that configure should assume. You do this by setting values in a
file called config.site and specifying the config.site file to
configure. To specify that your system uses the void version of
setpgrp, use the following:

    $ cat << END_OF_CONFIG.SITE > config.site
    $ CONFIG_SITE=config.site ./configure <other arguments to configure>

The way to find what values you need is to locate the code in
configure that is doing the test and see if there is an override. Here
is an example from the configure script for libdaemon-0.14:

    { $as_echo "$as_me:$LINENO: checking whether setpgrp takes no argument" >&5
    $as_echo_n "checking whether setpgrp takes no argument... " >&6; }
    if test "${ac_cv_func_setpgrp_void+set}" = set; then
      $as_echo_n "(cached) " >&6

The variable that you need to override is shown in the line that
starts with if test.

In most cases, the configure code will do the right thing in
cross-compiling situations if the configure.in or configure.ac is
correct, however, this problem is not one where configure can decide
what to do in a cross-compiling situation.

3. Helping configure and make find libraries

Sometimes you need to help configure with libraries and CFLAGS. Here
is an example showing one way to do it:

    # Configure this thing
    export LDFLAGS="-Wl,-rpath -Wl,lib -Wl,-rpath -Wl,../install/lib
-Wl,-rpath-link -Wl,../install/lib -L`pwd`/../install/lib"
    CONFIG_SITE=config.site ./configure --host=arm-none-linux-gnueabi
--disable-stack-protector --prefix=/

The LDFLAGS line is telling configure what to use when linking the
package so it can find the libraries at link time and run time.

Further things to watch out for here are that you really need to
distinguish between:

  a. Build directories
  b. Staging directories (called `pwd`/../install... above)
  c. Install directories on the target (argument of --prefix, and you
can use '--prefix=' if you want)

To install the needed files into the staging area, you would use something like:

  make install DESTDIR=`pwd`/../install

4. Hacking configure so it properly handles cross compiling

In some cases configure scripts have not been properly set up to
handle cross compiling. This will manifest itself when you run
configure and it says that it cannot run a test when cross compiling.
This tends to be due to segments in configure.in like the following:

    case "$host_os" in
        *linux* | gnu* | k*bsd*-gnu | kopensolaris*-gnu)
           # glibc <= 2.3.2 has a broken getgrouplist
    #include <unistd.h>
    #include <sys/utsname.h>
    main() {
           /* glibc up to 2.3 has a broken getgrouplist */
    #if defined(__GLIBC__) && defined(__GLIBC_MINOR__)
           int libc_major = __GLIBC__;
           int libc_minor = __GLIBC_MINOR__;

           if (libc_major < 2)
           if ((libc_major == 2) && (libc_minor <= 3))
    ], [linux_getgrouplist_ok=yes],
       [linux_getgrouplist_ok=no])     dnl THE ERROR IS HERE
           if test x"$linux_getgrouplist_ok" = x"yes"; then
              AC_DEFINE(HAVE_GETGROUPLIST, 1, [Have good getgrouplist])

A configure script is created from configure.in using autoconf or
autoreconf. Normally, you do not need to do this, because the source
tarball is delivered with a working configure script.

The problem with this fragment from configure.in is that in the
AC_TRY_RUN statement there is a missing section. An AC_TRY_RUN
statement specifies:

   1. A program to compile and run
   2. A statement to be executed if it compiles and runs.
   3. A statement to be executed if it fails to compile or run.
   4. An optional statement to be used if in a cross-compiling situation.

Each of the statements is enclosed in square brackets ([...]). The
cross compiling statement is missing in the fragment above.

The correct fragment in the above case should be:

    case "$host_os" in
        *linux* | gnu* | k*bsd*-gnu | kopensolaris*-gnu)
           # glibc <= 2.3.2 has a broken getgrouplist
    #include <unistd.h>
    #include <sys/utsname.h>
    main() {
           /* glibc up to 2.3 has a broken getgrouplist */
    #if defined(__GLIBC__) && defined(__GLIBC_MINOR__)
           int libc_major = __GLIBC__;
           int libc_minor = __GLIBC_MINOR__;

           if (libc_major < 2)
           if ((libc_major == 2) && (libc_minor <= 3))
    ], [linux_getgrouplist_ok=yes],
           if test x"$linux_getgrouplist_ok" = x"yes"; then
              AC_DEFINE(HAVE_GETGROUPLIST, 1, [Have good getgrouplist])

which will generate the correct configure code for handling cross
compilations as well.

After fixing problems with configure.in, you can regenerate configure
by running autoreconf.

5. Fixing shared libraries for correct cross-compiling use with libtool

If you are installing shared libs into a different area than they are
built in (or the build script for one library is installing the
library in a different place than it was built in) you can end up with
build errors where libtool complains no such file or directory during
the link stage.

To fix this problem, you have to modify the <library>.la file so that
it contains the correct path for your library. The following code
shows an example of how to do this:

    # Now, munge the paths on the shared libraries so they are correct
    INSTALL_PATH=$(dirname $PWD)/install
    echo Munging libtool path in .la file to: $INSTALL_PATH/lib
    sed -i -e "/^libdir=/s:=':='$INSTALL_PATH:" ../install/lib/libgpg-error.la

6. Problems with the tool chain

The version of gcc we are running gcc version 4.2.0 20070413
(prerelease) has problems in a couple of areas:

   1. It generates bad shared library prelude code if you enable
stack-protection capabilities. This manifests as crashes on entering
routines in a shared library. If this happens, switch off the stack
protection by specifying --disable-stack-protector on the configure
invocation line.
   2. In some cases it has problems with higher levels of optimization
and the compiler crashes. Just reduce the optimization level.

Richard Sharpe

More information about the discussion mailing list