[tcpdump-workers] [PATCH] small cross-compile fix
A problem with cross-compiling tcpdump is that it isn't possible to
override the finding the location of the SSLeay libraries/headers. The
small attached patch fixes this.
--
David Smith
[EMAIL PROTECTED]
Red Hat, Inc.
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)
--- tcpdump-2005.08.25/configure.in.cross 2005-09-13 15:24:18.0
-0500
+++ tcpdump-2005.08.25/configure.in 2005-09-14 09:08:55.0 -0500
@@ -908,7 +908,9 @@ AC_MSG_CHECKING(for SSLeay)
ac_cv_ssleay_path=no
incdir=no
-Xprefix=`eval echo $prefix`
+if test -z "$Xprefix"; then
+ Xprefix=`eval echo $prefix`
+fi
for dir in $Xprefix /usr/${host_alias} /usr /usr/local /usr/local/ssl
/usr/pkg; do
#
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [PATCH] small cross-compile fix
Thanks for the response. See stuff below. On Mon, 2005-09-19 at 23:42, Guy Harris wrote: > David Smith wrote: > > A problem with cross-compiling tcpdump is that it isn't possible to > > override the finding the location of the SSLeay libraries/headers. The > > small attached patch fixes this. > > So how do you override that? I don't see where Xprefix is getting set, > other than in that code. Sorry, I should have explained this better. (1) In the normal native build, 'Xprefix' won't be set in the environment. So, it will just be set to '$prefix' (as was done before the patch. (2) In the cross-compile case, the person cross-compiling will need to set Xprefix in his environment before calling configure: # export Xprefix=/path/to/SSLeay/libraries # configure or of course he can do the above in one step: # Xprefix=/path/to/SSLeay/libraries configure People doing cross-compiles are used to setting up defaults in their environment. It is the "standard" way to get around configure checks that can't be done during a cross-compilation. At first I tried to do this the "right" way of using a cached configure variable, but the ac_cv_ssleay_path code is a bit too complicated for that, since it actually sets two variables - ac_cv_ssleay_path and incdir. So, this Xprefix change is a bit of a hack, but not *too* gross. It might be possible to rewrite the ac_cv_ssleay_path configure section so that it is more cross-compile friendly, but that change will have more impact than the small change I included earlier. Let me know how you want to proceed. -- David Smith [EMAIL PROTECTED] Red Hat, Inc. http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [PATCH] small cross-compile fix
On Wed, 2005-09-21 at 11:47, Guy Harris wrote: > David Smith wrote: > > > At first I tried to do this the "right" way of using a cached configure > > variable, but the ac_cv_ssleay_path code is a bit too complicated for > > that, since it actually sets two variables - ac_cv_ssleay_path and > > incdir. > > > > So, this Xprefix change is a bit of a hack, but not *too* gross. It > > might be possible to rewrite the ac_cv_ssleay_path configure section so > > that it is more cross-compile friendly, but that change will have more > > impact than the small change I included earlier. > > One way to do that might be to have --with-crypto take an optional > argument and, if it's present, set Xprefix to the argument supplied. > Would that work? > > > Let me know how you want to proceed. > > I've checked in your change for now, as we'd like to put out a release > soon; a cleaner solution would be nice in the future. OK, here's a cleaner solution. It does this the "right" way using a cached config variable. I simplified the logic a bit, so that ac_cv_ssleay_path doesn't get set unless both the library and header file can be found. Then, once ac_cv_ssleay_path is set, the proper CFLAGS and LDFLAGS can be set up using the value of ac_cv_ssleay_path. Let me know what you think. -- David Smith [EMAIL PROTECTED] Red Hat, Inc. http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) --- tcpdump-2005.08.25/configure.in.cross 2005-09-13 15:24:18.0 -0500 +++ tcpdump-2005.08.25/configure.in 2005-09-21 16:07:31.0 -0500 @@ -904,9 +904,8 @@ AC_ARG_WITH(crypto, [ --without-cryptodisable crypto support], [], [ -AC_MSG_CHECKING(for SSLeay) +AC_CACHE_CHECK([for SSLeay], [ac_cv_ssleay_path], [ ac_cv_ssleay_path=no -incdir=no Xprefix=`eval echo $prefix` @@ -924,23 +923,17 @@ if test -d $dir/lib -a \( -f $dir/lib/libcrypto.a -o \ -f $dir/lib/libcrypto.so -o \ -f $dir/lib/libcrypto.sl -o \ - -f $dir/lib/libcrypto.dylib \); then + -f $dir/lib/libcrypto.dylib \) \ + -a -d $dir/include/openssl \ + -a -f $dir/include/openssl/des.h; then ac_cv_ssleay_path=$dir - fi - if test -d $dir/include/openssl -a -f $dir/include/openssl/des.h; then - incdir="-I$dir/include" - fi - if test "$ac_cv_ssleay_path" != "no" -a "$incdir" != "no"; then break; - else - ac_cv_ssleay_path=no - incdir=no fi done -AC_MSG_RESULT($ac_cv_ssleay_path) +]) if test "$ac_cv_ssleay_path" != no; then - V_INCLS="$V_INCLS $incdir" - LDFLAGS="-L$dir/lib $LDFLAGS" + V_INCLS="$V_INCLS -I$ac_cv_ssleay_path/include" + LDFLAGS="-L$ac_cv_ssleay_path/lib $LDFLAGS" if test -f $ac_cv_ssleay_path/lib/libRSAglue.a; then LIBS="$LIBS -lRSAglue" fi - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [PATCH] small cross-compile fix
On Wed, 2005-09-21 at 21:27, Guy Harris wrote: > On Sep 21, 2005, at 2:13 PM, David Smith wrote: > > > OK, here's a cleaner solution. It does this the "right" way using a > > cached config variable. > > So should that be applied to the configure.in *before* your previous > patch? > > If so, does it mean that there's no need to have the user say where > the library and headers are installed, even for cross-compiles? Sorry for the confusion. This patch completely replaces my last patch. Now, when a user wants to cross compile, he sets up ac_cv_ssleay_path in the environment. # export ac_cv_ssleay_path=/path/to/SSLeay/libraries # configure The solution is really the same as the last one, but this solution is done in the "proper" autoconf way, instead of setting up a mechanism outside of autoconf. The trick here is the use of AC_CACHE_CHECK. Here's the description of AC_CACHE_CHECK (which really just wraps up AC_CACHE_VAL) from the info file: == - Macro: AC_CACHE_VAL (CACHE-ID, COMMANDS-TO-SET-IT) Ensure that the results of the check identified by CACHE-ID are available. If the results of the check were in the cache file that was read, and `configure' was not given the `--quiet' or `--silent' option, print a message saying that the result was cached; otherwise, run the shell commands COMMANDS-TO-SET-IT. If the shell commands are run to determine the value, the value will be saved in the cache file just before `configure' creates its output files. *Note Cache Variable Names::, for how to choose the name of the CACHE-ID variable. The COMMANDS-TO-SET-IT _must have no side effects_ except for setting the variable CACHE-ID, see below. - Macro: AC_CACHE_CHECK (MESSAGE, CACHE-ID, COMMANDS-TO-SET-IT) A wrapper for `AC_CACHE_VAL' that takes care of printing the messages. This macro provides a convenient shorthand for the most common way to use these macros. It calls `AC_MSG_CHECKING' for MESSAGE, then `AC_CACHE_VAL' with the CACHE-ID and COMMANDS arguments, and `AC_MSG_RESULT' with CACHE-ID. The COMMANDS-TO-SET-IT _must have no side effects_ except for setting the variable CACHE-ID, see below. == Here's the associated example from the info file: == AC_DEFUN([AC_SHELL_TRUE], [AC_CACHE_CHECK([whether true(1) works], [ac_cv_shell_true_works], [ac_cv_shell_true_works=no true && ac_cv_shell_true_works=yes]) if test $ac_cv_shell_true_works = yes; then AC_DEFINE([TRUE_WORKS], 1 [Define if `true(1)' works properly.]) fi ]) == So, what goes on here is this. In the native build case, ac_cv_ssleay_path won't be set in the environment. So, the code to find the right directory will be run. In the cross build case, the user is responsible to setting up ac_cv_ssleay_path in the environment. When this section of configure is hit, configure realizes that ac_cv_ssleay_path is already set, and will skip the code to find the right directory. In both cases, the final code to set V_INCLS and LDFLAGS is set with the value of ac_cv_ssleay_path (assuming it isn't 'no'). -- David Smith [EMAIL PROTECTED] Red Hat, Inc. http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [PATCH] small cross-compile fix
Guy, have you had any chance to look at this again? On Thu, 2005-09-22 at 09:42 -0500, David Smith wrote: > On Wed, 2005-09-21 at 21:27, Guy Harris wrote: > > On Sep 21, 2005, at 2:13 PM, David Smith wrote: > > > > > OK, here's a cleaner solution. It does this the "right" way using a > > > cached config variable. > > > > So should that be applied to the configure.in *before* your previous > > patch? > > > > If so, does it mean that there's no need to have the user say where > > the library and headers are installed, even for cross-compiles? > > Sorry for the confusion. This patch completely replaces my last patch. > > Now, when a user wants to cross compile, he sets up ac_cv_ssleay_path in > the environment. > > # export ac_cv_ssleay_path=/path/to/SSLeay/libraries > # configure > > The solution is really the same as the last one, but this solution is > done in the "proper" autoconf way, instead of setting up a mechanism > outside of autoconf. > > The trick here is the use of AC_CACHE_CHECK. Here's the description of > AC_CACHE_CHECK (which really just wraps up AC_CACHE_VAL) from the info > file: > > == > - Macro: AC_CACHE_VAL (CACHE-ID, COMMANDS-TO-SET-IT) > Ensure that the results of the check identified by CACHE-ID are > available. If the results of the check were in the cache file > that was read, and `configure' was not given the `--quiet' or > `--silent' option, print a message saying that the result was > cached; otherwise, run the shell commands COMMANDS-TO-SET-IT. If > the shell commands are run to determine the value, the value will > be saved in the cache file just before `configure' creates its > output files. *Note Cache Variable Names::, for how to choose the > name of the CACHE-ID variable. > > The COMMANDS-TO-SET-IT _must have no side effects_ except for > setting the variable CACHE-ID, see below. > > - Macro: AC_CACHE_CHECK (MESSAGE, CACHE-ID, COMMANDS-TO-SET-IT) > A wrapper for `AC_CACHE_VAL' that takes care of printing the > messages. This macro provides a convenient shorthand for the most > common way to use these macros. It calls `AC_MSG_CHECKING' for > MESSAGE, then `AC_CACHE_VAL' with the CACHE-ID and COMMANDS > arguments, and `AC_MSG_RESULT' with CACHE-ID. > > The COMMANDS-TO-SET-IT _must have no side effects_ except for > setting the variable CACHE-ID, see below. > == > > Here's the associated example from the info file: > > == > AC_DEFUN([AC_SHELL_TRUE], > [AC_CACHE_CHECK([whether true(1) works], [ac_cv_shell_true_works], > [ac_cv_shell_true_works=no > true && ac_cv_shell_true_works=yes]) > if test $ac_cv_shell_true_works = yes; then > AC_DEFINE([TRUE_WORKS], 1 > [Define if `true(1)' works properly.]) > fi > ]) > == > > So, what goes on here is this. > > In the native build case, ac_cv_ssleay_path won't be set in the > environment. So, the code to find the right directory will be run. > > In the cross build case, the user is responsible to setting up > ac_cv_ssleay_path in the environment. When this section of configure is > hit, configure realizes that ac_cv_ssleay_path is already set, and will > skip the code to find the right directory. > > In both cases, the final code to set V_INCLS and LDFLAGS is set with the > value of ac_cv_ssleay_path (assuming it isn't 'no'). > -- David Smith [EMAIL PROTECTED] Red Hat, Inc. http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Arch dependent ar and ld
On Tue, 2005-11-08 at 18:49 -0800, Guy Harris wrote: > On Nov 4, 2005, at 3:11 AM, Karl-Johan Perntz wrote: > > > When I cross compiled libpcap and tcpdump for the CRIS architecture I > > had to make libpcap aware of architecture dependent ar and ld. The > > diff > > below adds the option to specify which ar and ld to use. I think that > > this could be useful for others and therefore I hope that you can > > include it in the next version. > > Unfortunately, it doesn't work, so we can't include it in the next > version; there's no autoconf macro, at least in 2.57 or 2.59, that > sets AR or LD, so they just expand to nothing. > > Perhaps it needs to be converted to use libtool. Before you visit the evils of libtool on libpcap, there is a simpler alternative. Here's Karl-Johan's patch for Makefile.in modified: 57a58,59 > AR = ar > LD = ld 104c106 < ar rc $@ $(OBJ) $(LIBS) --- > $(AR) rc $@ $(OBJ) $(LIBS) 115c117 < ld -shared -o [EMAIL PROTECTED] VERSION` $(OBJ) --- > $(LD) -shared -o [EMAIL PROTECTED] VERSION` $(OBJ) This way AR defaults to 'ar' and LD defaults to 'ld'. but from the make command line someone cross-compiling can override them. # make AR=archfoo-linux-gnu-ar LD=archfoo-linux-gnu-ld -- David Smith [EMAIL PROTECTED] Red Hat, Inc. http://www.redhat.com 256.217.0141 (direct) 256.837.0057 (fax) - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] tcpdump TEST folder
I have successfully compiled and installed tcpdump using libcap_1.2.2 (1.3.0 misbehaved in another application). My purpose is to understand interaction with the wireless device. I am curious about the folder of TESTS - how are they invoked? DMS -- David Smith Managing Partner AbidaNet LLC ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
