[Winpcap-users] [PATCH] mingw build

Alon Bar-Lev alon.barlev at gmail.com
Thu Oct 21 05:10:30 PDT 2010 

I use the simple way...

Gentoo's crossdev

crossdev -t i686-w64-mingw32
crossdev -t x86_64-w64-mingw32

On Wed, Oct 20, 2010 at 2:39 AM, Gianluca Varenni <
gianluca.varenni at cacetech.com> wrote:

> That should work.
>
> Can you tell me the exact steps and environment that you use to target
> 32bit
> with MINGW64?
>
> Have a nice day
> GV
>
>
>
> --------------------------------------------------
> From: "Alon Bar-Lev" <alon.barlev at gmail.com>
> Sent: Tuesday, October 19, 2010 10:33 AM
> To: <winpcap-users at winpcap.org>
> Subject: Re: [Winpcap-users] [PATCH] mingw build
>
> > Hi,
> >
> > No I don't use -m32, you can build cross compile that targets 32bit
> > without multilib...
> > But it is not such important.
> >
> > What I am suggesting is a simple Makefile rule, or just use the
> > autoconf provided with libpcap anyway... but if not, please consider
> > the following, then #include config.h, and use its constants to
> > conditionally do whatever.
> >
> > target: config.h
> >
> > config.h:
> >        -rm config.h config.h.tmp
> >        touch config.h.tmp
> >        echo "#include <windows.h>" > conftest.c
> >        echo "#include <ntddndis.h>" >> conftest.c
> >        $(CC) -c conftest.c > /dev/null 2>&1 && echo "#define
> > HAVE_NTDDNDIS_H 1" >> config.h.tmp || true
> >        echo "#include <windows.h>" > conftest.c
> >        echo "#include <ddk/ntddndis.h>" >> conftest.c
> >        $(CC) -c conftest.c > /dev/null 2>&1 && echo "#define
> > HAVE_DDK_NTDDNDIS_H 1" >> config.h.tmp || true
> >        echo "int getaddrinfo();int main(void){getaddrinfo();}" >
> > conftest.c
> >        $(CC) conftest.c -lws2_32 > /dev/null 2>&1 && echo "#define
> > HAVE_GETADDRINFO 1" >> config.h.tmp || true
> >        mv config.h.tmp config.h
> >
> >
> >
> > On Tue, Oct 19, 2010 at 6:51 PM, Gianluca Varenni
> > <gianluca.varenni at cacetech.com> wrote:
> >>
> >>
> >> --------------------------------------------------
> >> From: "Alon Bar-Lev" <alon.barlev at gmail.com>
> >> Sent: Tuesday, October 19, 2010 12:16 AM
> >> To: <winpcap-users at winpcap.org>
> >> Subject: Re: [Winpcap-users] [PATCH] mingw build
> >>
> >>> Hi,
> >>>
> >>> This is incorrect:
> >>> ---
> >>> #ifdef __MINGW32__
> >>> +#ifdef __MINGW64__
> >>> +#include <ntddndis.h>
> >>> +#else /*__MINGW64__*/
> >>> #include <ddk/ntddndis.h>
> >>> +#endif /*__MINGW64__*/
> >>> #else
> >>> ---
> >>>
> >>> As mingw-w64 can be used as both 32bit and 64bit (i686-w64-mingw32,
> >>> x86_64-w64-mingw32).
> >>> So you fix this for 64bit but if you use 32bit you will get the same
> >>> error.
> >>
> >> I think I know what you mean now (after searching more on the internet).
> >> You
> >> are using MINGW64 *and* the option -m32 to generate 32bit binaries. I
> >> didn't
> >> know about the existence of -m32 ...
> >>
> >> Regarding the addition of the ddk include in the makefile, the reason
> why
> >> I
> >> didn't do that is because I couldn't find a definition of the default
> >> include folder for that specific toolchain (and that works on mingw,
> >> mingw64, mingw64 with -m32, linux, windows, cygwin). Ideally the
> addition
> >> should be something like
> >>
> >> CFLAGS = ........  -I ${default_include_dir}/ddk
> >>
> >> but I haven't  found what is the right env variable that I should put in
> >> place of "default_include_dir". I don't want to put an absolute path
> >> there.
> >>
> >> I'm definitely open to suggestions...
> >>
> >> Have a nice day
> >> GV
> >>
> >>
> >>>
> >>> What I recommend is to add ddk include file LAST in the CPP search
> >>> list in make file.
> >>>
> >>> Same goes to:
> >>> +/*
> >>> + * Mingw64 has its own implementation of getaddrinfo, mingw32 no
> >>> + */
> >>> +#ifndef __MINGW64__
> >>> +
> >>> +
> >>>
> >>> Best to have it done in Makefile, by trying to compile something with
> >>> getaddrinfo and create mini config.h file.
> >>>
> >>> If you want I can create such a patch. And if we do this, we can also
> >>> check if the ddk is needed or not using the same method.
> >>>
> >>> Regards,
> >>> Alon Bar-Lev.
> >>>
> >>> On Tue, Oct 19, 2010 at 12:19 AM, Gianluca Varenni
> >>> <gianluca.varenni at cacetech.com> wrote:
> >>>>
> >>>> I reworked the patch originally provided by Alon Bar-Lev (thanks!) a
> >>>> bit
> >>>> to
> >>>> have WinPcap 4.1.2 compile under MINGW32 and MINGW64, Windows and
> Linux
> >>>> cross compilation.
> >>>>
> >>>> You can find it at
> >>>>
> >>>> http://www.winpcap.org/install/bin/WinPcap_4_1_2_mingw_win.patch
> >>>> http://www.winpcap.org/install/bin/WinPcap_4_1_2_mingw_linux.patch
> >>>>
> >>>> MD5's are as follows:
> >>>>
> >>>> 6cecf64649cfd4f32553025d2b6daa96 *WinPcap_4_1_2_mingw_linux.patch
> >>>> 8b341ba39bb0b621c81f5c8df7e7536a *WinPcap_4_1_2_mingw_win.patch
> >>>>
> >>>> Due to a big mess with line endings in the source code of WinPcap
> 4.1.2
> >>>> (some files have the CR/LF line ending, some have the LF one), the
> >>>> patch
> >>>> that was working on Windows  (with patch.exe coming from cygwin or
> >>>> MSYS)
> >>>> was
> >>>> not working on linux, and viceversa. So I created two patch files for
> >>>> WinPcap 4.1.2.
> >>>>
> >>>> The resulting patched WinPcap 4.1.2 was tested on
> >>>> - Cygwin 1.7
> >>>> - MSYS+MINGW64 (I used the TDM-GCC one at http://tdm-gcc.tdragon.net/
> )
> >>>> - MSYS+MINGW32 (I used the TDM-GCC one at http://tdm-gcc.tdragon.net/
> )
> >>>> - MINGW32 on a debian "squeeze" machine
> >>>> - MINGW64 on a debian "squeeze" machine
> >>>>
> >>>> Also, the same patches were committed on the WinPcap repository +
> >>>> libpcap
> >>>> repository (HEAD and libpcap_1.1 branch).
> >>>>
> >>>> Have a nice day
> >>>> GV
> >>>>
> >>>>
> >>>>
> >>>> --------------------------------------------------
> >>>> From: "Gianluca Varenni" <gianluca.varenni at cacetech.com>
> >>>> Sent: Tuesday, October 12, 2010 9:43 AM
> >>>> To: <winpcap-users at winpcap.org>
> >>>> Subject: Re: [Winpcap-users] [PATCH] mingw build
> >>>>
> >>>> >
> >>>> >
> >>>> > --------------------------------------------------
> >>>> > From: "Guy Harris" <guy at alum.mit.edu>
> >>>> > Sent: Wednesday, October 06, 2010 5:02 PM
> >>>> > To: <winpcap-users at winpcap.org>
> >>>> > Subject: Re: [Winpcap-users] [PATCH] mingw build
> >>>> >
> >>>> >>
> >>>> >> On Sep 14, 2010, at 9:17 AM, Alon Bar-Lev wrote:
> >>>> >>
> >>>> >>> 4. grammar.y - any idea why we need pcap_parse if yacc defines it
> >>>> >>> anyway instead of yyparse?
> >>>> >>
> >>>> >> Because
> >>>> >>
> >>>> >> 1) WinPcap is based on libpcap;
> >>>> >>
> >>>> >> 2) libpcap was originally written back when many UN*Xes had only
> the
> >>>> >> old
> >>>> >> AT&T YACC, which only defined yyparse().
> >>>> >>
> >>>> >> The current top-of-trunk version of grammar.y, at least, defines
> >>>> >> pcap_parse() only if YYBISON is not defined, which presumably means
> >>>> >> "not
> >>>> >> Bison".
> >>>> >>
> >>>> >>> 5. yacc does not accept -y argument.
> >>>> >>
> >>>> >> Earlier versions of GNUmakefile mirrored the UN*X Makefile.in, and
> >>>> >> had
> >>>> >> a
> >>>> >> YACC variable that ran Bison, rather than YACC, with the "-y" flag
> >>>> >> (which,
> >>>> >> for Bison, means "act like YACC and produce y.tab.c and y.tab.h
> >>>> >> files").
> >>>> >>
> >>>> >> The 4.1.2 version runs whatever make sets YACC to refer to, with
> the
> >>>> >> YFLAGS flag.  Is there some reason why that was done?
> >>>> >
> >>>> > No idea. The original GNUMakefile was contributed by someone and
> >>>> > included
> >>>> > into the WinPcap sources.
> >>>> > I modified GNUMakefile to
> >>>> > 1. define "BISON = bison" and "FLEX = flex"
> >>>> > 2. use ${BISON} to compile grammar.y
> >>>> >
> >>>> >
> >>>> >> Was this to support parser-generators *other* than Bison?  Unless
> >>>> >> there's
> >>>> >> a compelling reason not to run Bison, it should probably go back to
> >>>> >> the
> >>>> >> way it was, using Bison - that'll fix that problem *and* the
> >>>> >> previous
> >>>> >> problem, with no changes required to grammar.y.
> >>>> >>
> >>>> >> If there *is* a compelling reason not to run Bison, then
> >>>> >>
> >>>> >> 1) it should not include "-y"
> >>>> >>
> >>>> >> and
> >>>> >>
> >>>> >> 2) either it should not do "-p pcap_", if whatever version of YACC
> >>>> >> is
> >>>> >> being used doesn't support "-p", or:
> >>>> >>
> >>>> >> 2a) grammar.y should check for YYBISON *and* some other #define
> >>>> >> named
> >>>> >> appropriately for whatever parser-generator is being used
> >>>> >>
> >>>> >> and
> >>>> >>
> >>>> >> 2b) it should do "-D{that #define name}".
> >>>> >>
> >>>> >>> 7. Minor modification of (char*)A += code.
> >>>> >>
> >>>> >> (I.e., "casting lvalues considered harmful - and possibly rejected
> >>>> >> by
> >>>> >> some
> >>>> >> compilers.")
> >>>> >
> >>>> > I will commit it on the libpcap git repository as soon as possible.
> >>>> >
> >>>> > Have a nice day
> >>>> > GV
> >>>> >
> >>>> >> _______________________________________________
> >>>> >> Winpcap-users mailing list
> >>>> >> Winpcap-users at winpcap.org
> >>>> >> https://www.winpcap.org/mailman/listinfo/winpcap-users
> >>>> >
> >>>> > _______________________________________________
> >>>> > Winpcap-users mailing list
> >>>> > Winpcap-users at winpcap.org
> >>>> > https://www.winpcap.org/mailman/listinfo/winpcap-users
> >>>>
> >>>> _______________________________________________
> >>>> Winpcap-users mailing list
> >>>> Winpcap-users at winpcap.org
> >>>> https://www.winpcap.org/mailman/listinfo/winpcap-users
> >>> _______________________________________________
> >>> Winpcap-users mailing list
> >>> Winpcap-users at winpcap.org
> >>> https://www.winpcap.org/mailman/listinfo/winpcap-users
> >>>
> >> _______________________________________________
> >> Winpcap-users mailing list
> >> Winpcap-users at winpcap.org
> >> https://www.winpcap.org/mailman/listinfo/winpcap-users
> >>
> > _______________________________________________
> > Winpcap-users mailing list
> > Winpcap-users at winpcap.org
> > https://www.winpcap.org/mailman/listinfo/winpcap-users
> >
> _______________________________________________
> Winpcap-users mailing list
> Winpcap-users at winpcap.org
> https://www.winpcap.org/mailman/listinfo/winpcap-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.winpcap.org/pipermail/winpcap-users/attachments/20101021/46850b3b/attachment.htm

More information about the Winpcap-users mailing list