[Winpcap-users] [PATCH] mingw build

Tue Oct 19 09:51:55 PDT 2010

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